WSO2 says low privilege users could run admin actions on its System REST APIs; its advisory is 280 days old

A critical CVE for a fix WSO2 announced in January

WSO2 published the CVE record for CVE-2025-11969 at 05:53 UTC on 2 November 2026, as its own CVE Numbering Authority. The record scores it CVSS 3.1 9.4, Critical, and says the System REST APIs in WSO2 products "do not correctly enforce access control mechanisms, allowing users with lower privilege roles to execute administrative actions that should be restricted." Its only reference is WSO2 advisory WSO2-2025-4733. That advisory, in the source file WSO2 keeps in its public docs-security repository, carries the line "Published: January 26, 2026". From 26 January to 2 November is 280 days (derived). The update levels that fix it were listed in the advisory from the day it was published.

The fix itself is older still. The advisory points community users to one public change, carbon-apimgt pull request 13521, titled "Improve code", which GitHub shows merged into the master branch at 07:10 UTC on 27 October 2025. That is 371 days before the CVE record (derived), and seven days after the record says the CVE identifier was reserved, on 20 October 2025. This briefing was read between 10:09 and 10:20 GMT on Monday 2 November 2026. WSO2's live advisory page answered our requests with a browser check, which we did not try to get past; the advisory text quoted here is WSO2's own published source file and its history on GitHub.

So the question for a defender is not only whether the flaw is serious. It is whether a vulnerability scanner or patch process that keys on CVE identifiers could have told you about it at any point in those 280 days, and whether your WSO2 servers already sit at the update level WSO2 named in January.

What the record does not establish

The record and the advisory make no statement about exploitation, victims or attacks. CVE-2025-11969 was not in the CISA Known Exploited Vulnerabilities catalogue, version 2026.10.30, when read at 10:10 GMT on 2 November 2026. Absence from that list is not evidence that nobody has used the flaw; it means no listing as of that catalogue version.

Neither primary gives a count of exposed or affected servers, and this briefing does not estimate one. Neither names a reporter: the record's source block says the discovery was INTERNAL, and it carries no credit. Neither defines which REST APIs WSO2 means by "System REST APIs". And the dates show only when files were written and published; they do not explain why the CVE record followed the advisory by 280 days.

Lower privilege user, or no privilege at all?

The two WSO2 documents describe the attacker in words as an account holder. The record says "users with lower privilege roles". The advisory says "a user with low privileges can perform unauthorized actions, including executing administrative actions." But the CVSS vector WSO2 assigned in both places says PR:N, no privileges required, which in CVSS terms means an attacker who is not signed in at all.

The difference moves the score across a severity line. With every other metric unchanged, the same vector with PR:L, low privileges, scores 8.3, High, not 9.4, Critical (derived with the CVSS 3.1 formula; arithmetic in the fact check). So either the prose undersells the exposure, or the vector oversells it. The primaries do not say which, and this briefing treats the question as unresolved.

WSO2's own documentation gives one clue to how the role check is meant to work. Its page on scope to role mappings says certain REST API resources are protected by OAuth 2.0 scopes, and that a token for a scope is issued "only if that user has been assigned one or more of the roles specified in the RESTAPIScopes configuration for that scope." In other words, the role check lives in the scope check.

The public fix changes exactly that. In the shared REST API code, the scope validation routine used to log "Skipping scope validation" and return true when it found no resource template matching the request path; after the fix it logs "Hence, failing the scope validation" and returns false. The same change removes an OAuth authentication interceptor from the Gateway REST API's configuration. Our reading, which is inference and not WSO2's wording: a check that passed whenever it could not match a path would let a token holding few or no admin scopes through to an admin resource, which fits the "lower privilege user" prose better than a fully unauthenticated caller. The fix diff alone does not settle PR:N.

The path, drawn

Zoom

Steps one and two are what the record states. The purple card is this site's reading of the public change WSO2 names, and is labelled as such. The green card is WSO2's own exclusion, which the next section examines.

Stated, and not stated

"Not affected through the Gateway" is not "not reachable"

Both WSO2 documents carry a reassuring sentence. The advisory: "Any APIs created and exposed through the WSO2 API Manager's API Gateway remain unaffected." Read quickly, it sounds like the gateway shields you. It does not say that.

An API Manager deployment carries two kinds of API. There are the business APIs an organisation creates and publishes through the gateway for its consumers, and there are the product's own management APIs. WSO2's REST API overview lists the latter as the APIs exposed from the Publisher, Developer Portal, Admin Portal, Gateway, Service Catalog, Devops and Governance components, used "to create and manage APIs". The sentence about the Gateway covers the first kind. The flaw is in the second. The public fix even edits the configuration of the Gateway component's own REST API, which suggests (our reading of the file paths) that the management side of the gateway was in scope, even though the APIs it serves were not.A label that tells you your published APIs are safe says nothing about the management interface where the access check failed, and that interface is what needs fencing and patching.

Open banking deployments are the obvious high stakes case, because WSO2 lists Open Banking AM 2.0.0 and Open Banking IAM 2.0.0 among the affected products. WSO2 says nothing specific to open banking beyond those two rows and their update levels, 396 and 416, and this briefing adds nothing it does not state.

Products, versions and the fix

Zoom

This advisory splits the fix by customer type.Support subscription holders are told to update to the listed update level or higher through WSO2 Updates. Community users, running the open source distributions, are told: "Apply the relevant fixes to your product using the public fix(es) provided below." The one public fix listed is pull request 13521. Failing that: "If applying the fix or update is not feasible, migrate to the latest unaffected version of the respective WSO2 product(s)." The advisory does not name a community release number for each product line.

The record lists versions of API Manager before 3.1.0, and of the other products before their first listed version, as unknown, not unaffected. It also lists two library components that do not appear in WSO2's table: the Carbon API Manager Rest API Utility and Rest API Common Functions packages, with affected ranges and 9.32.147 marked unaffected. The exact ranges are in the technical details below.

GitHub's advisory database mirrored the record as GHSA-p4rq-q6fh-965p at 06:31 UTC on 2 November, marked unreviewed and with no affected package listed, so dependency scanners that rely on it will not match a Maven artifact yet. WSO2 products have been in the exploited catalogue before; this site covered an earlier WSO2 catalogue entry whose name did not match its own record.

Fixed in October 2025, advised in January, recorded in November

Three gaps follow, all derived: 7 days from reservation to the merged fix, 91 days from the merged fix to the advisory, and 280 days from the advisory to the CVE record. The fix commit's title says nothing about security, which is common practice for embargoed fixes but means a reader of the open source history would not have known what it closed.

What to do, in order

Technical details

Each block below is copied exactly from the primary it names, read on 2 November 2026. Where this site has reformatted structured data for reading, the caption says so. No request that performs an administrative action is given.

The record's description. This is the statement the CVE list and its mirrors now carry.

The System REST APIs do not correctly enforce access control mechanisms, allowing users with lower privilege roles to execute administrative actions that should be restricted. This weakness permits unauthorized operations on the affected product.

Successful exploitation could enable a malicious actor to perform unauthorized administrative operations, including executing administrative functions. APIs exposed through the WSO2 API Manager's API Gateway are not affected by this vulnerability.

The score and vector WSO2 assigned. Note PR:N against the prose above; the derived score with PR:L would be 8.3.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L
baseScore 9.4, baseSeverity CRITICAL
CWE-285: Improper Authorization

WSO2's affected product list, as printed in the advisory. Use it for inventory.

* WSO2 API Control Plane: 4.5.0
* WSO2 API Manager: 4.5.0, 4.4.0, 4.3.0, 4.2.0, 4.1.0, 4.0.0, 3.2.1, 3.2.0, 3.1.0
* WSO2 Identity Server as Key Manager: 5.10.0
* WSO2 Open Banking AM: 2.0.0
* WSO2 Open Banking IAM: 2.0.0
* WSO2 Traffic Manager: 4.5.0
* WSO2 Universal Gateway: 4.5.0

WSO2's update level table. A server at the listed level or higher carries the fix.

| Product Name                          | Product Version   | Update Level   |
| ------------------------------------- | ----------------- | -------------- |
| WSO2 API Control Plane                | 4.5.0             | 33             |
| WSO2 API Manager                      | 4.5.0             | 32             |
| WSO2 API Manager                      | 4.4.0             | 49             |
| WSO2 API Manager                      | 4.3.0             | 85             |
| WSO2 API Manager                      | 4.2.0             | 173            |
| WSO2 API Manager                      | 4.1.0             | 233            |
| WSO2 API Manager                      | 4.0.0             | 370            |
| WSO2 API Manager                      | 3.2.1             | 70             |
| WSO2 API Manager                      | 3.2.0             | 450            |
| WSO2 API Manager                      | 3.1.0             | 347            |
| WSO2 Identity Server as Key Manager   | 5.10.0            | 367            |
| WSO2 Open Banking AM                  | 2.0.0             | 396            |
| WSO2 Open Banking IAM                 | 2.0.0             | 416            |
| WSO2 Traffic Manager                  | 4.5.0             | 31             |
| WSO2 Universal Gateway                | 4.5.0             | 31             |

The two library components that appear only in the record, rendered one range per line by this site from the record's JSON fields; the values are copied exactly. The repeated base versions with two different upper bounds are as the record prints them.

WSO2 Carbon API Manager Rest API Utility  (org.wso2.carbon.apimgt:org.wso2.carbon.apimgt.rest.api.util)  defaultStatus: unknown
  affected: version 6.6.163, lessThan 6.6.163.159
  affected: version 6.6.163, lessThan 6.6.163.160
  affected: version 6.7.206, lessThan 6.7.206.574
  affected: version 6.7.206, lessThan 6.7.206.576
  affected: version 6.7.210, lessThan 6.7.210.69
  affected: version 6.7.210, lessThan 6.7.210.71
  affected: version 9.0.174, lessThan 9.0.174.536
  affected: version 9.20.74, lessThan 9.20.74.384
  affected: version 9.20.74, lessThan 9.20.74.385
  affected: version 9.28.116, lessThan 9.28.116.380
  affected: version 9.29.120, lessThan 9.29.120.202
  affected: version 9.30.67, lessThan 9.30.67.125
  affected: version 9.31.86, lessThan 9.31.86.90
  unaffected: version 9.32.147, lessThanOrEqual *
WSO2 Carbon API Manager Rest API Common Functions  (org.wso2.carbon.apimgt:org.wso2.carbon.apimgt.rest.api.common)  defaultStatus: unknown
  affected: version 9.0.174, lessThan 9.0.174.538
  affected: version 9.20.74, lessThan 9.20.74.385
  affected: version 9.28.116, lessThan 9.28.116.382
  affected: version 9.29.120, lessThan 9.29.120.204
  affected: version 9.30.67, lessThan 9.30.67.126
  affected: version 9.31.86, lessThan 9.31.86.91
  unaffected: version 9.32.147, lessThanOrEqual *

The files the public fix changed. The first is the shared REST API scope check; the next two are the Gateway REST API's configuration; the last sets a default API version on requests.

modified  +20 -4  components/apimgt/org.wso2.carbon.apimgt.rest.api.common/src/main/java/org/wso2/carbon/apimgt/rest/api/common/RestApiCommonUtil.java
modified  +0 -5  components/apimgt/org.wso2.carbon.apimgt.rest.api.gateway/src/main/webapp/WEB-INF/beans.xml
modified  +0 -1  components/apimgt/org.wso2.carbon.apimgt.rest.api.gateway/src/main/webapp/WEB-INF/web.xml
modified  +1 -0  components/apimgt/org.wso2.carbon.apimgt.rest.api.util/src/main/java/org/wso2/carbon/apimgt/rest/api/util/interceptors/URLValidationInterceptor.java

The lines in the scope check that changed, copied from the public diff. The old debug message is what a defender with retained debug logs would search for.

-                log.debug("No matching scopes found for request with path: " + basePath
-                        + ". Skipping scope validation.");
+                log.debug("No matching scopes found for request with path: " + derivedBasePath
+                        + ". Hence, failing the scope validation.");
-            return true;
+            return false;

The exploited catalogue check, summarised by this site from the feed's own fields.

catalogVersion: 2026.10.30
dateReleased: 2026-10-30T17:02:45.3665Z
count: 1766
entries with cveID CVE-2025-11969: 0

The question that exposes the gap

WSO2 graded this flaw Critical, named the update levels and published a public fix by 26 January 2026. Its customers with subscriptions had a route to the fix all year. Anyone whose process starts from a CVE identifier, a scanner, a feed, a dependency check, had nothing to match until 2 November.

So the question for every WSO2 operator, and for any vendor that is its own CNA: if a critical fix exists for 280 days before its CVE does, whose patch process was it written for, and who was left to find it by reading the vendor's advisory index?

Key facts