Unrestricted file upload in WSO2 API Manager can enable remote code execution

The System REST API accepts user-supplied file uploads without enforcing sufficient validation on the file type or destination, allowing files to be written to arbitrary server-accessible locations. Exploitation requires authenticated administrative access with publisher privileges. Successful exploitation permits an authenticated publisher to upload files to server-accessible locations. Depending on the deployment environment and how uploaded files are handled, this could lead to the execution of uploaded content, potentially resulting in remote code execution.

• WSO2 API Manager: affected on the 4.4.0 branch below 4.4.0.67, the 4.5.0 branch below 4.5.0.52, and the 4.6.0 branch below 4.6.0.16. The default status is recorded as unaffected.
• WSO2 Traffic Manager: affected on the 4.5.0 branch below 4.5.0.51 and the 4.6.0 branch below 4.6.0.16. The default status is recorded as unaffected.
• WSO2 API Control Plane: affected on the 4.5.0 branch below 4.5.0.53 and the 4.6.0 branch below 4.6.0.17. The default status is recorded as unaffected.
• WSO2 Universal Gateway: affected on the 4.5.0 branch below 4.5.0.52 and the 4.6.0 branch below 4.6.0.16. The default status is recorded as unaffected.
• Package org.wso2.carbon.apimgt:org.wso2.carbon.apimgt.impl: affected on 9.30.67 below 9.30.67.156, 9.31.86 below 9.31.86.141, and 9.32.147 below 9.32.147.44. The default status is unknown; the returned CNA data also records 9.33.104 as unaffected with an open upper bound.
• Package org.wso2.carbon.apimgt:org.wso2.carbon.apimgt.rest.api.publisher.v1.common: affected on the same branches and boundaries; the default status is unknown, and 9.33.104 is recorded as unaffected with an open upper bound.
• Package org.wso2.carbon.apimgt:org.wso2.carbon.apimgt.api: affected on 9.30.67 below 9.30.67.156; the default status is unknown, and 9.33.104 is recorded as unaffected with an open upper bound.

The flaw is in the System REST API, which accepts user-supplied file uploads without sufficient validation of the file type or destination. The uploaded content and write location are user-controlled enough to permit files to be written to arbitrary locations accessible to the server within the deployment. Exploitation requires an authenticated account with administrative access and publisher privileges. This is CWE-434, Unrestricted Upload of File with Dangerous Type. Depending on how the deployment stores and handles the uploaded file, the content may be executed and could lead to remote code execution. The available evidence does not specify the exact validation logic, filesystem mapping, or execution mechanism.

• The vulnerability is reachable over the network through the System REST API.
• Exploitation requires an authenticated account with administrative access and publisher privileges; no additional user interaction is required after that condition is met.
• The supplied record marks public_exploit as false and provides no public exploit, campaign, or exploit steps.
• The CISA enrichment returned during research records exploitation as none and automatable as no; this is an assessment at the time of recording and does not prove that future exploitation is impossible.

Successful exploitation allows an authenticated publisher to write arbitrary files to locations accessible to the server. If the deployment processes or executes content at that location, the technical impact could extend to remote code execution, with possible effects on data, application integrity, and service availability. The vulnerability does not itself provide the initial account because authenticated administrative and publisher privileges are prerequisites. The actual scope depends on the process permissions, reachable write locations, and deployment-specific file handling. The record does not confirm execution in every configuration.

The vulnerability may allow an authenticated publisher to place arbitrary files in locations accessible to the server. If the deployment treats content at that location as executable code or an executable resource, the consequence could extend to remote code execution. This could affect server or service integrity, disrupt availability, and expose data depending on the process permissions and deployment architecture. Publisher and administrative privileges are prerequisites, so protecting privileged accounts remains an important control. The record does not establish a specific breach or victim organization.

1. For supported WSO2 distributions, update to the update level specified by WSO2 or higher: API Control Plane 4.6.0 update 17 or 4.5.0 update 53; API Manager 4.6.0 update 16, 4.5.0 update 52, or 4.4.0 update 67; Traffic Manager 4.6.0 update 16 or 4.5.0 update 51; Universal Gateway 4.6.0 update 16 or 4.5.0 update 52.
2. For Community or Open Source distributions, apply the corresponding carbon-apimgt fix provided by WSO2 and verify that it covers the deployed product branch and package.
3. If applying the fix is not feasible, migrate to a WSO2 version confirmed as unaffected for the specific product and branch. Do not assume that every parallel release branch or every later version is safe without reconciling it with the affected data.
4. For the packages listed in affected_summary, verify the installed versions and move each package out of its affected range; in particular, confirm the mapping between package versions and product update levels.
5. While updates are pending, use defense in depth by restricting publisher privileges and limiting network access to the System REST API to required sources. This is temporary risk reduction and does not replace the fix.

1. Inventory deployments running WSO2 API Manager, WSO2 Traffic Manager, WSO2 API Control Plane, WSO2 Universal Gateway, and the related Carbon API Management packages. Compare each branch with the boundaries listed in affected_summary.
2. Check whether the System REST API is exposed to unnecessary networks, and review accounts that have publisher and administrative privileges.
3. Review audit and application records for authenticated publisher requests to System REST API upload functions, including file names or destinations if those fields are logged. This is precautionary monitoring, not a vendor-published IOC.
4. Inspect server-accessible locations for unexpected or newly created files and correlate them with publisher activity. The absence of matching logs or files does not prove that the deployment is safe.
5. Confirm the installed product update level and package versions after remediation.