CVE-2026-2053
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedThe WSO2 API Manager's message flow component, when processing WS-Addressing headers, does not sufficiently validate or restrict user-controlled input within these headers. This omission allows an attacker to manipulate WS-Addressing headers to specify arbitrary destinations for server-initiated requests. Successful exploitation allows an unauthenticated attacker to control the destination of server-initiated requests originating from the WSO2 API Manager. This direct control can enable unauthorized access to internal network resources or services that would typically be inaccessible from external networks.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · moderate confidenceThis is an SSRF (Server-Side Request Forgery) vulnerability in WSO2 API Manager's message flow component. The application fails to validate WS-Addressing headers, allowing unauthenticated attackers to specify arbitrary destinations for server-initiated requests, enabling access to internal network resources that should be inaccessible.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data>= 3.1.0, < 3.1.0.360>= 3.2.0, < 3.2.0.465>= 3.2.1, < 3.2.1.84>= 4.0.0, < 4.0.0.385>= 4.2.0, < 4.2.0.189CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify WSO2 API Manager installationLocate the WSO2 API Manager installation directory. Common paths include /opt/wso2am, /usr/local/wso2am, or C:\Program Files\wso2\am. Check for the presence of the wso2am binary or the api-manager.xml configuration file.Affected if WSO2 API Manager is not installed on the system.
-
Determine installed WSO2 API Manager versionCheck the version file in the installation directory. The version is typically found in the product.xml file or the README file in the root installation directory. You can also check the carbon console or the registry for the exact version number.Affected if The installed version cannot be determined or is not WSO2 API Manager.
-
Compare version against affected rangesMatch the installed version number against the vulnerable ranges: >= 3.1.0 and < 3.1.0.360; >= 3.2.0 and < 3.2.0.465; >= 3.2.1 and < 3.2.1.84; >= 4.0.0 and < 4.0.0.385; >= 4.2.0 and < 4.2.0.189Affected if The installed version falls within any of the listed vulnerable version ranges.
-
Verify WS-Addressing header processing is enabledCheck the api-manager.xml or axis2.xml configuration file for WS-Addressing configuration. Look for settings related to WS-Addressing (wsa:To, wsa:ReplyTo headers) in the synapse configuration. These are typically found in the <sequence> definitions or the <inboundEndpoint> configurations.Affected if WS-Addressing header processing is enabled in the message flow configuration and the version is vulnerable.
-
Review network exposure and outbound request logsExamine access logs and outbound request logs for suspicious requests to internal network addresses (localhost, 127.0.0.1, 10.x.x.x, 192.168.x.x) that may indicate exploitation. Check the http_access.log and wso2carbon.log files for unusual outbound connection patterns.Affected if Unusual outbound requests to internal network resources are observed in the logs.
The environment is affected if WSO2 API Manager is installed with a version that falls within the vulnerable ranges and WS-Addressing header processing is enabled in the message flow configuration.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped3.1.0.3603.2.0.4653.2.1.84
Validate and restrict WS-Addressing headers to an allowlist of permitted destinations, implement strict input validation on the message flow component, and apply network segmentation to limit internal service exposure. Monitor for unusual outbound requests.
WSO2 API Manager 3.1.0.360, 3.2.0.465, 3.2.1.84, or 4.0.0.385 (depending on your major version branch)
- 1. Identify the currently installed WSO2 API Manager version by checking the product version in the product.xml or carbon.xml configuration file
- 2. For WSO2 API Manager 3.1.0 through 3.1.0.359: Upgrade to version 3.1.0.360 or later
- 3. For WSO2 API Manager 3.2.0 through 3.2.0.464: Upgrade to version 3.2.0.465 or later
- 4. For WSO2 API Manager 3.2.1 through 3.2.1.83: Upgrade to version 3.2.1.84 or later
- 5. For WSO2 API Manager 4.0.0 through 4.0.0.384: Upgrade to version 4.0.0.385 or later
- 6. After upgrading, test the WS-Addressing functionality to ensure legitimate operations still work correctly
- 7. Verify that the patch was applied by checking the product distribution for the fixed version number
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation4.0 h
- Implementation12.0 h
- Testing6.0 h
- Review / QA3.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $7,040.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-2053 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-2053 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data