Multiple WSO2 products fail to enforce authentication on protected REST API endpoints due to two flaws in how requests are matched against access control rules.
The first flaw is a case-sensitive comparison when matching HTTP methods against protected resource definitions. A resource configured to require authentication on POST only matches the literal uppercase string. Because the HTTP method is normalised to uppercase further down the processing pipeline, a mixed-case method like Post bypasses the check entirely. Any endpoint protected by method-specific rules is vulnerable. For example, the OAuth 2.0 Dynamic Client Registration endpoint can be reached this way, allowing an attacker to escalate to administrative privileges via the same technique described in CVE-2025-9152.
The second flaw is a path normalisation issue involving matrix URIs. By appending a matrix URI parameter containing an encoded path to a public resource, an attacker can cause the authentication layer to match the request against the wrong resource. For example, a request to /scim2/Users/;%2F.well-known%2Fopenid-configuration passes authentication because the framework matches it against the public /.well-known/openid-configuration resource, but after decoding and normalisation, the request is routed to /scim2/Users. The same technique applies to any protected endpoint across all affected products.
When combined with authenticated RCE vulnerabilities (CVE-2025-10907, CVE-2025-11093), either flaw enables full pre-auth remote code execution across affected versions.
This vulnerability was responsibly disclosed and has been patched by the vendor.