CVE-2026-41851

WSO2 Products impacted: no

Customer actions required: no

REPORTED VULNERABILITY

Spring Framework applications that accept and evaluate user-supplied Spring Expression Language (SpEL) expressions may be vulnerable to a Denial of Service (DoS) attack through unbounded cache growth 1. The SpEL matches operator tests a string against a Java regular expression and caches the compiled Pattern objects to avoid recompiling the same regex on every evaluation. The backing cache (OperatorMatches.patternCache) is an unbounded ConcurrentHashMap keyed by the regex string. When an attacker can supply SpEL expressions containing distinct regular expressions, and the application repeatedly parses and evaluates them, the cache grows without limit and can eventually exhaust memory, leading to a Denial of Service.

Per the vendor advisory 1, an application is vulnerable only when all of the following conditions are met:

  • The application accepts and evaluates untrusted or user-controlled SpEL expressions.
  • The application caches parsed SpEL expressions.

The maintainer (VMware/Spring, the CNA) assigns an availability-only impact of Medium (CVSS base score 5.3, vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) 1; note that NVD records a higher base score of 7.5 (High) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H 2. Affected Spring Framework versions are 7.0.0–7.0.7, 6.2.0–6.2.18, 6.1.0–6.1.27 and 5.3.0–5.3.48 (fixed in 5.3.49, 6.1.28, 6.2.19 and 7.0.8; the 5.3.x and 6.1.x fixes are commercial-only).

REPORTED PRODUCTS

  • WSO2 Identity Server : 5.10.0, 5.11.0, 6.0.0, 6.1.0, 7.0.0

The vulnerable component reported by the scanner is org.springframework:spring-core / org.springframework:spring-expression, bundled as a WSO2 rebuild of Spring Framework 5.3.39 (5.3.39-wso2v2) under the embedded Apache CXF (cxf3) JAX-RS runtime.

WSO2 JUSTIFICATION

In WSO2 Identity Server, Spring Framework is used solely as the internal dependency-injection container of the bundled Apache CXF (cxf3) JAX-RS runtime. It is not used to expose Spring MVC controllers, and the product does not evaluate user-supplied Spring Expression Language. A review of the product confirmed that the two preconditions required to exploit CVE-2026-41851 cannot be met:

  • The product does not accept or evaluate untrusted SpEL expressions. A bytecode-level review of the entire distribution found that the only libraries referencing a Spring ExpressionParser are spring-expression (the library), spring-context (whose bean-definition resolver evaluates #{...} configuration expressions at context startup), and the OSGi spring.framework aggregate that bundles both. No WSO2 Identity Server code, and no other third-party library, invokes a Spring ExpressionParser on request-derived input. The only SpEL expression present in any deployed application is a single static type literal — #{ T(org.apache.cxf.jaxrs.ext.search.SearchBean) } — a fixed, developer-authored expression evaluated once at context startup by spring-context's bean-definition resolver. It contains no matches operator and no regular expression, is not derived from any request input, and is not re-parsed per request.

  • No user-SpEL surface is exposed. The frameworks that commonly evaluate user-influenced SpEL — spring-security, spring-webmvc, spring-data, spring-integration and thymeleaf — are not shipped with the product. The user-facing search/filter functionality of the CXF JAX-RS endpoints (the ?filter= query parameter, live on the configuration-management, identity-provider and application-management APIs) is parsed by CXF's OData parser (org.apache.cxf.jaxrs.ext.search.odata.ODataParser, backed by Apache Olingo), not by Spring SpEL — cxf-rt-rs-extension-search contains no reference to a Spring ExpressionParser. No request input ever reaches an ExpressionParser.

Triggering the DoS requires both that the application evaluate untrusted SpEL and that it cache the parsed expressions, so that distinct attacker-controlled regexes accumulate in patternCache. Since WSO2 Identity Server never evaluates untrusted SpEL at all, the first — and therefore neither — of the two required conditions can be satisfied, and the vulnerable code path is unreachable.

Regarding remediation of the dependency itself: the open-source Spring Framework 5.3.x line reached end-of-life at 5.3.39, and the release that contains the fix for this CVE (5.3.49) is published under commercial support only and is not available on Maven Central. Migrating the cxf3 runtime to Spring Framework 6.x is not viable either, as Spring 6.x requires Java 17+ and the Jakarta EE (jakarta.*) namespace, which is a major, breaking architectural change for the affected product versions. Because the vulnerability is not exploitable in the product, this dependency upgrade is not warranted on the basis of CVE-2026-41851 alone.

CONCLUSION

  • The vulnerable code (OperatorMatches.patternCache) is present in the bundled Spring Framework, but the exploit preconditions do not exist in WSO2 Identity Server.
  • WSO2 Identity Server does not accept or evaluate any user-controlled SpEL expression; no product or third-party code invokes a Spring ExpressionParser on request input (the sole invocation is spring-context resolving the static startup config expression).
  • The only SpEL expression in the product is a static type literal evaluated once at startup, which cannot drive unbounded cache growth.

Based on this evidence, we conclude that this vulnerability does not pose a security risk to the impacted versions of WSO2 products listed above.

REFERENCES

  1. https://spring.io/security/cve-2026-41851/ ↩↩↩

  2. https://nvd.nist.gov/vuln/detail/CVE-2026-41851 ↩