CVE-2026-47892 and CVE-2026-59283: Two Spring "Critical" Ratings

Your scanner is showing a 9.8 and a 9.1. Spring's advisories for the same two CVEs say 4.8 and 6.5. Both pairs of numbers are real. One sits on the CVE record, the other sits in Spring's advisory, and nothing in the CVE pipeline arbitrates between them.

The CVEs are CVE-2026-47892, a header predicate bypass in Spring WebFlux functional endpoints, and CVE-2026-59283, a SpEL safety guard bypass in spring-expression. Both were disclosed by Spring on August 20, 2026, as part of a batch of 91 Spring CVEs published in a single day. CISA's ADP rates CVE-2026-47892 at 9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and CVE-2026-59283 at 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H). Spring's own advisories score them 4.8 Medium (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N) and 6.5 Medium (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:H). Both affect Spring Framework 5.2.x through 7.0.8, and the only OSS fix for either is Spring Framework 7.0.9.

‍

The question that actually matters is not which scorer is right in the abstract. It is whether either bug is reachable in your deployment, and for both CVEs that comes down to a configuration check you can run in under five minutes.

‍

Affected and unsupported? See NES for Spring.

‍

Why one record carries two scores

In April 2026, NIST stopped enriching every CVE. The NVD now analyzes only three categories: CVEs in the CISA KEV catalog, CVEs in federal software, and CVEs in software defined as critical under EO 14028. Spring qualifies under none of them, so Spring CVE records receive no NIST-added severity score, CWE, or product mapping. They are published and labeled "Not Scheduled." The math forced the change: per NIST's own announcement, CVE submissions grew 263% between 2020 and 2025, NIST enriched nearly 42,000 records in 2025 and still lost ground, and Q1 2026 submissions ran nearly one-third higher than the same period a year earlier. Under the new policy, roughly 29,000 backlogged CVEs were reclassified as "Not Scheduled" in one move.

Into that vacuum steps CISA's ADP, the Vulnrichment program, designed to add a score where the CNA supplied none. Spring published complete CVSS 3.1 vectors in its own advisories but did not carry them into the CVE records, so the records looked empty and the ADP filled them. The score rendering on the NVD page for these two CVEs is the CISA-ADP container, not an NVD analyst assessment.

And nothing arbitrates the disagreement. Vulnrichment's own documentation treats a record carrying both a CNA score and an ADP score as an error in the ADP container, with the CNA's data taking precedence, but nothing in the pipeline enforces that. Two scores, one record, no referee.

The comparative analysis of the full Critical-rated set was published by JFrog Security Research (Aviv Engelberg and Niv Lanyado, September 3, 2026) in "When Critical Loses Context: The Reality of Spring CVEs". Their code-level review is the basis for the deployment-precondition findings below, and it is worth reading in full. Here is where the two records stand:

Neither CVE is in the CISA KEV catalog, and no public exploitation has been reported for either as of this writing.

‍

CVE-2026-47892: header predicate bypass in WebFlux functional endpoints

The bug (CWE-863): a crafted CORS preflight request passes header predicates unconditionally and executes the handler function without the required headers present. If that handler returns sensitive data or triggers side effects, those fire on a crafted OPTIONS request.

The precondition is the whole story. Per JFrog's review of the fix commit, the bypass only affects applications that deploy WebFlux functional endpoints standalone, via RouterFunctions.toHttpHandler() or RouterFunctions.toWebHandler(). That is a rare, non-default deployment pattern.

One note before you click through to the Spring advisory: its one-line description mentions deployment with DispatcherServlet, which reads as if the standard setup were the affected one. The fix commit tells the real story. The patch lands in the standalone RouterFunctionWebHandler path, the code that only runs when WebFlux.fn routes are served without DispatcherHandler, because a DispatcherHandler setup already handles preflight predicate evaluation before any handler function is reached.

You are not affected through this path if you run the standard Spring Boot deployment. In a standard Boot WebFlux application, DispatcherHandler intercepts preflight requests before any handler function is invoked.

Even where the precondition holds, the impact ceiling is bounded by what the specific handler behind the bypassed predicate does. That is not nothing: a handler that gates sensitive data behind a header check loses that gate. But it is not system-wide compromise. Spring's 4.8 encodes the niche deployment prerequisite as high attack complexity and the handler-dependent impact as low confidentiality and integrity. CISA's 9.8 assumes universal exploitability and full server compromise, and neither is supported by the code.

‍

CVE-2026-59283: SpEL SimpleEvaluationContext safety guard bypass

The bug (CWE-913): when the SpEL expression compiler is active, compiled bytecode skips the runtime policy checks that SimpleEvaluationContext enforces in interpreted mode. The Spring advisory also notes an unbounded class-loading angle, since each distinct compilable expression generates and loads a new class.

The dangerous scenario is an expression compiled under a permissive context and later evaluated under a restricted one. The compiled bytecode retains full power. When only SimpleEvaluationContext is in play, dangerous operations fail before compilation triggers, which limits the impact to confidentiality leaks and memory pressure.

Reaching the bug requires two non-default configurations, both true at once:

1. The application explicitly evaluates SpEL expressions using SimpleEvaluationContext.
2. The SpEL compiler is enabled in IMMEDIATE or MIXED mode, via the spring.expression.compiler.mode property or a SpelParserConfiguration. It is off by default.

Spring's 6.5 vector reads confidentiality low, availability high, integrity none, because assignment expressions are not compilable. CISA's 9.1 treats both prerequisites as a given. The fix makes SimpleEvaluationContext refuse compilation by default, with an explicit withCompilationSupported() opt-in for teams that compile trusted expressions for performance.

‍

Check whether this applies to you

This is the part your escalation decision should rest on. Neither of these preconditions hides: both are grep-able.

For CVE-2026-47892, search for the standalone deployment pattern:

grep - rn 
"RouterFunctions.toHttpHandler\|RouterFunctions.toWebHandler" src /

No hits, and your application boots through the standard Spring Boot WebFlux path with DispatcherHandler? The bypassed code path is not reachable in your deployment.

For CVE-2026-59283, both conditions must hold, so check both:

# Condition 1: explicit SimpleEvaluationContext usage
  grep -rn "SimpleEvaluationContext" src/‍
    
# Condition 2: SpEL compiler enabled (off by default)
  grep -rn "spring.expression.compiler.mode" src/ config/ 
  *.properties *.yml
  grep -rn "SpelCompilerMode\|SpelParserConfiguration" src/

Also check deployment-time configuration: startup scripts, container env vars, and JAVA_OPTS can set spring.expression.compiler.mode as a system property outside the repo. If the compiler mode is nowhere set to IMMEDIATE or MIXED, condition 2 fails and the guard bypass is not reachable, whatever your SimpleEvaluationContext usage looks like.

A negative result does not make the finding disappear from your scan report. It lets you close it as not applicable, with evidence. For the auditor who sees a 9.8 next quarter, keep: the exact commands run, the commit hash and date of the codebase scanned, the deployment configuration reviewed, and both scores with their sources attributed (CISA-ADP enrichment versus the Spring CNA advisory vector). That is a documented risk determination, not a suppressed finding.

We have made the mirror-image argument before: low-severity CVEs can become high risk when context raises their reachability. This is the same argument run in the other direction. The number on the record is a starting point; context, in both directions, is the actual severity.

‍

The EOL wrinkle: for most affected lines, the score dispute is secondary

Both CVEs affect every Spring Framework line from 5.2 through 7.0.8, and the only OSS fix for either is Spring Framework 7.0.9. Every other affected line is past its open source support window, per the Spring Framework support timeline:

This changes what the scoring dispute means in practice. On 7.0.x, the argument over 9.8 versus 4.8 mostly determines how fast you schedule an upgrade you were going to do anyway. On 5.3.x or 6.1.x, there is no version within your line to upgrade to. The finding cannot be closed by patching in place, so whichever score you record, it becomes a persistent open item that resurfaces in every scan, audit, and customer security questionnaire.

That persistence, not the score, is the real cost. We covered why a post-EOL CVE is a different object from a normal vulnerability: it has no upstream resolution path, and it accumulates siblings with every new disclosure. Teams in that position have two real moves: migrate to Spring Framework 7.0.x on their own roadmap, or close the finding with remediated builds through NES for Spring, which delivers drop-in replacements for EOL Spring lines. For the general shape of the problem, see what to do about a CVE with no patch.

‍

Frequently asked questions

Which score should I put in my risk register?

Record both, with attribution: 9.8/9.1 from CISA-ADP enrichment, 4.8/6.5 from the Spring CNA advisory vectors. Then record your configuration-check result, which is the input that actually determines your exposure. Vulnrichment's documentation gives CNA data precedence when both exist, but the config check is stronger evidence than either number.

Will NVD ever rescore these?

Under the post-April-2026 scope, no. Spring CVEs fall outside all three categories NVD still analyzes, so these records stay "Not Scheduled" unless something pulls them in, such as a KEV listing. Do not plan around a future NVD analyst score settling the disagreement.

Is either CVE being exploited in the wild?

Neither appears in the CISA KEV catalog as of this writing, and no active exploitation has been reported.

Does this affect Spring Boot applications?

Spring Boot pulls in Spring Framework as a dependency, so check the resolved spring-core version, not the Boot version: mvn dependency:tree | grep spring-core or the Gradle equivalent. For CVE-2026-47892 specifically, the standard Boot deployment path is not affected regardless of version, per the precondition above.

What about the other Critical-rated CVEs from the same batch?

‍ Four more CVEs from the August 20 batch carry CISA Critical ratings, including CVE-2026-47890 and CVE-2026-59313. Those have their own scoring stories; we cover the batch in our August 2026 Spring roundup.

‍

Taking action

Run the config checks first. They take five minutes, they answer the question the scores cannot, and they turn a 9.8 alert into either a genuine escalation or a documented, evidence-backed determination of non-applicability.

Then look at your version line. On Spring Framework 7.0.x, upgrade to 7.0.9 and close both findings outright. On 6.2.x, 6.1.x, 6.0.x, 5.3.x, or 5.2.x, no OSS fix exists for either CVE, and these two findings join every other post-EOL Spring finding in your backlog until the line itself is dealt with. NES for Spring resolves vulnerabilities on EOL Spring Framework lines with drop-in replacement builds, so you can close the findings now and migrate on your own schedule. Talk to us about coverage for your Spring estate.