Skip to content

CVE-2026-47886

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 exponentiation 1. The SpEL power operator (^, implemented by OperatorPower) delegates to BigDecimal.pow() / BigInteger.pow() when the left operand (the base) is a BigDecimal or BigInteger, without limiting the size of the exponent. An attacker who can supply a SpEL expression that raises such a value to a very large exponent can monopolize CPU threads for an extended period and exhaust JVM 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.
  • A BigDecimal or BigInteger value is accessible within the evaluation context.

The maintainer (VMware/Spring, the CNA) rates the issue Medium (CVSS base score 5.9, vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) 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.8, 6.2.0–6.2.19, 6.1.0–6.1.28, 6.0.0–6.0.30, 5.3.0–5.3.49 and 5.2.25.RELEASE and earlier (fixed in 7.0.9; the 7.0.8.1, 6.2.20, 6.1.29, 6.0.31, 5.3.50 and 5.2.26 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 components reported by the scanner are org.springframework:spring-web and org.springframework:spring-core, bundled as a WSO2 rebuild of Spring Framework 5.3.39 (5.3.39-wso2v2) under the embedded Apache CXF (cxf3) JAX-RS runtime. These artifacts are flagged because the CVE is recorded against Spring Framework as a whole; the vulnerable code (the SpEL power operator, OperatorPower) itself resides in the spring-expression module.

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 preconditions required to exploit CVE-2026-47886 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 power operator (^) and no BigDecimal or BigInteger operand, and is not derived from any request input.

  • 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 that an attacker be able to submit a SpEL expression that applies the ^ operator to a BigDecimal or BigInteger base (left operand) with a large exponent. Since WSO2 Identity Server never evaluates untrusted SpEL at all, an attacker has no means of injecting such an expression, and the vulnerable code path (OperatorPower) 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.50) is published under commercial support only and is not available on Maven Central. Migrating the cxf3 runtime to Spring Framework 7.x (the only line with an open-source fix) is not viable either, as it 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-47886 alone.

CONCLUSION

  • The vulnerable code (the SpEL power operator, OperatorPower) 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 uses no power operator and no BigDecimal or BigInteger operand.

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