Stored cross-site scripting in WSO2 API Control Plane and WSO2 API Manager portals

Insufficient HTML sanitization in the Publisher Portal and Developer Portal allows untrusted user input to be rendered without proper encoding or neutralization. This enables the injection and execution of malicious JavaScript when affected API documents are viewed. Successful exploitation may result in the execution of malicious scripts within the user's browser context when viewing API documentation. Users with permissions to access the API documentation through these portals may be impacted, potentially allowing attackers to perform actions on behalf of the user, depending on their session privileges.

The explicitly affected ranges are:

• WSO2 API Control Plane: 4.5.0, <4.5.0.55; and 4.6.0, <4.6.0.19.
• WSO2 API Manager: 3.2.0, <3.2.0.470; 3.2.1, <3.2.1.89; 4.1.0, <4.1.0.254; 4.2.0, <4.2.0.194; 4.3.0, <4.3.0.105; 4.4.0, <4.4.0.69; 4.5.0, <4.5.0.54; and 4.6.0, <4.6.0.18.

Only the branches above are explicitly confirmed as affected. The record does not establish the status of other branches outside these ranges.

WSO2 API Control Plane and WSO2 API Manager do not sufficiently sanitize HTML in the Publisher Portal and Developer Portal. Untrusted input in API documents can reach the rendered documentation without adequate encoding or neutralization, allowing JavaScript to execute in the viewer's browser context.

The supported high-level sequence is:

1. Untrusted data is introduced into or stored in an API document.
2. The Publisher Portal or Developer Portal renders that data without sufficient HTML sanitization.
3. When the affected document is viewed, malicious script can execute in the user's browser context.

The record characterizes the vulnerability as network reachable, requiring low privileges and having low complexity. A user must have permission to access the API documentation to become the affected browser context, but the specific input field and exact sanitization code path are not disclosed.

The vulnerability is remotely reachable over the network and is characterized in the record as requiring low privileges and low complexity. The record marks user interaction as not required at the exploitation level, while the malicious code executes when an affected API document is viewed in a portal.

The supplied record sets public_exploit to false, so no public exploit is confirmed in the provided data. known_exploited is not populated; that does not establish that exploitation is impossible or that exploitation has never occurred.

The technical outcome is execution of malicious JavaScript in the browser context of a user viewing an affected API document. The script may operate within the user's session privileges and may be able to perform actions on the user's behalf, depending on the permissions granted to that session.

The impact is on the browser side of users accessing documentation, with scope dependent on the affected session. The record does not establish server-side code execution, does not confirm arbitrary account takeover, and does not identify an availability impact. The actual effect on data and administrative actions depends on the privileges of the user viewing the document.

• Malicious JavaScript can execute in the browser context of a user viewing an affected API document. • Depending on the user's session privileges, an attacker may be able to perform actions on the user's behalf within the capabilities available to that session. • Users permitted to access API documentation through the Publisher Portal or Developer Portal are the group that should be prioritized for exposure review. • The record provides no evidence that data was accessed, accounts were taken over, or a breach occurred; actual consequences depend on the privileges of affected sessions.

1. Apply the corresponding update level for each affected branch:

• WSO2 API Control Plane 4.6.0: update level 19.
• WSO2 API Control Plane 4.5.0: update level 55.
• WSO2 API Manager 4.6.0: update level 18.
• WSO2 API Manager 4.5.0: update level 54.
• WSO2 API Manager 4.4.0: update level 69.
• WSO2 API Manager 4.3.0: update level 105.
• WSO2 API Manager 4.2.0: update level 194.
• WSO2 API Manager 4.1.0: update level 254.
• WSO2 API Manager 3.2.1: update level 89.
• WSO2 API Manager 3.2.0: update level 470.

1. If using a community build or if the update level cannot be applied, apply WSO2's public fix identified as PR #1287, or migrate to an unaffected version after confirming the applicable branch.

2. After applying the update or public fix, enable sanitizeHtmlDocs with enabled: true for both the Publisher Portal and Developer Portal. For WSO2 API Manager 4.2.0, 4.3.0, 4.4.0, 4.5.0 and 4.6.0, inspect the settings.json files in the publisher/site/public/conf and devportal/site/public/theme directories below <APIM_HOME>/repository/deployment/server/webapps.

3. For WSO2 API Manager 3.2.0, 3.2.1 and 4.1.0, update the settings.js files in the publisher/site/public/conf and devportal/site/public/theme directories below <APIM_HOME>/repository/deployment/server/jaggeryapps. After the change, confirm that both portals load the sanitization configuration.

1. Inventory every WSO2 API Control Plane and WSO2 API Manager deployment, then compare its product branch and update level with the affected ranges.
2. Identify the versions of the Publisher Portal and Developer Portal in each deployment, with priority given to the branches listed in the record.
3. After updating, inspect the applicable settings.json or settings.js files and confirm that sanitizeHtmlDocs is present with enabled set to true.
4. Review API documents created or modified by users who can introduce untrusted content into the portals, especially documents viewed while an affected version was in service.
5. Verify document rendering in both the Publisher Portal and Developer Portal through a safe test process in a non-production environment. No specific IOC or log event is established by the record; portal access monitoring should therefore be treated as a precaution rather than a known indicator.