Skip to main content
← Vulnerabilities

Stored Cross-Site Scripting in Multiple WSO2 Products

Affects WSO2 API Manager 3.2.0 to 4.2.0 and the Carbon API Manager Publisher REST API before 9.28.140, where an attacker holds the Publisher role. Fixed in 3.2.0.449, 3.2.1.68, 4.0.0.368, 4.1.0.60 and 4.2.0.7.

Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.

4.8MediumCNA
Exploited
No known exploitation
Fix
Fixed in 3.2.0.449, 3.2.1.68, 4.0.0.368, 4.1.0.60, 4.2.0.7, and 1 more
Who is exposed
Specific setups only

Do first: Check whether your setup matches what the bug needs. Attacker holds the Publisher role in the affected product Affects WSO2 API Manager versions 4.2.0, 4.1.0, 4.0.0, 3.2.1 and 3.2.0

Published
Last modified
Published
Not listed in CISA KEV
13/100 · provisional
Specific setups only
Fix
Fixed in 3.2.0.449, 3.2.1.68, 4.0.0.368, 4.1.0.60, 4.2.0.7, and 1 more
None on Exploit-DB, Metasploit or GitHub
  • Exploitation: none
  • Automatable: no
  • Technical impact: partial

Summary

Multiple WSO2 products with the Publisher portal are affected by a stored cross-site scripting flaw caused by inadequate validation of uploaded SVG files. An attacker with the Publisher role could use a crafted SVG to run malicious scripts in victims' browsers, enabling redirects, page tampering, or information theft, though session cookies marked httpOnly limit session hijacking.

Read the original description

The Publisher portal fails to enforce proper validation on uploaded SVG files, allowing users with the Publisher role to inject malicious scripts. This weakness can be exploited by uploading a crafted SVG file, which is then stored and rendered by the application. The security consequences include the ability for a malicious actor to redirect the victim's browser to an arbitrary website, modify the web page's UI, or retrieve information from the browser. However, the impact is mitigated as session-related sensitive cookies are protected with the httpOnly flag, preventing session hijacking.

What to do

  • Check whether your setup matches what the bug needs.

    Attacker holds the Publisher role in the affected product Affects WSO2 API Manager versions 4.2.0, 4.1.0, 4.0.0, 3.2.1 and 3.2.0
  • Upgrade to a fixed version: 3.2.0.449, 3.2.1.68, 4.0.0.368, 4.1.0.60, 4.2.0.7, or one of 1 more.

Timeline

  1. CVE published
  2. First seen by cve.now
  3. CISA SSVC assessment

    Exploitation: none · Automatable: no · Technical impact: partial

  4. Record last updated

Affected versions

  • WSO2 WSO2 API Manager

    From 3.2.0 · fixed in 3.2.0.449; From 3.2.1 · fixed in 3.2.1.68; From 4.0.0 · fixed in 4.0.0.368; From 4.1.0 · fixed in 4.1.0.60; From 4.2.0 · fixed in 4.2.0.7

  • org.wso2.carbon.apimgt:org.wso2.carbon.apimgt.rest.api.publisher.v1

    fixed in 9.28.140

Evidence 1

  1. Advisory

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

FAQ

Questions about CVE-2025-12544

What does this mean?

The bug is a stored Cross-Site Scripting flaw: a user with the Publisher role can store malicious script in the product, which runs in a victim's browser. The script can redirect the browser to an arbitrary website, change the page UI, or retrieve information from the browser. Session hijacking is not possible because session cookies use the httpOnly flag.Source: security.docs.wso2.com

Am I affected, and how do I check?

Affected versions are WSO2 API Manager 3.2.0, 3.2.1, 4.0.0, 4.1.0 and 4.2.0 before their listed fixed builds, and the Carbon API Manager Publisher REST API before 9.28.140. The attacker must hold the Publisher role in the affected product. Compare the installed build number with the fixed builds listed for each release line.Source: security.docs.wso2.com

What should I do about it?

Upgrade WSO2 API Manager to the fixed build for its release line: 3.2.0.449, 3.2.1.68, 4.0.0.368, 4.1.0.60 or 4.2.0.7. For the Publisher REST API, upgrade to 9.28.140 or later.Source: security.docs.wso2.com

Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data