GHSA-9QF2-26P9-2Q2Q Uncategorized

GHSA-9qf2-26p9-2q2q – Spring Framework Header Predicate Bypass in WebFlux Functional Endpoints (CVE‑2026‑47892)

(Updated: ) By wp-post 10 min read

Vulnerability Intelligence Overview

GHSA-9QF2-26P9-2Q2Q
Advisory Identifier
GHSA-9QF2-26P9-2Q2Q
Source Record Published
Last Intelligence Update

Introduction

The advisory GHSA-9qf2-26p9-2q2q (also referenced as CVE-2026-47892) documents a critical header predicate bypass in Spring Framework’s WebFlux functional endpoints when the application is deployed with DispatcherServlet. The flaw affects a wide range of Spring Framework releases, from 5.2.5.RELEASE through 7.0.8, and is assigned a CVSS v3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, indicating a high‑impact, network‑accessible vulnerability.

Vulnerability Overview

Field Value
OSV advisory ID GHSA-9qf2-26p9-2q2q
CVE identifier and aliases CVE-2026-47892
Summary Spring Framework Header Predicate Bypass in WebFlux Functional Endpoints
Affected package names org.springframework:spring-webflux
Package ecosystem Maven
Published date 2026-08-27T06:31:34Z
Modified date 2026-10-07T13:20:45Z
Severity CRITICAL (as reported by Spring) / CVSS V3
CVSS score or vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE identifiers CWE-863 – Incorrect Authorization
Recorded fixed versions 7.0.9 (fix for the 7.x series). Earlier series have no fixed version listed in the advisory.

Detailed Vulnerability Explanation

Spring Framework’s WebFlux module supports functional routing, where developers define routes using a RouterFunction and predicate functions that inspect the incoming HTTP request. When a WebFlux application also uses the traditional DispatcherServlet (often for backward compatibility with Spring MVC), a subtle interaction occurs during CORS pre‑flight handling.

The issue arises because the HeaderPredicate—a predicate that validates the presence or value of specific HTTP headers—can be bypassed in a pre‑flight (OPTIONS) request. The pre‑flight request is processed by the CORS filter before it reaches the functional routing layer. If the filter incorrectly forwards the request without applying the header predicate, an attacker can issue a crafted OPTIONS request that skips the intended authorization checks, subsequently sending the actual request that will be accepted by the functional endpoint.

The vulnerability is limited to deployments that combine:

  • WebFlux functional endpoints (i.e., routes defined via RouterFunction), and
  • A DispatcherServlet in the same application context.

When both conditions are met, the pre‑flight handling path can short‑circuit the header predicate, creating a bypass window that exists only for the duration of the CORS negotiation.

Technical Analysis

From a technical standpoint, the bypass stems from the order in which Spring registers the CORS filter and the functional router. In affected versions, the CORS filter calls chain.doFilter after a minimal validation, and the functional router’s HeaderPredicate is applied later in the request processing pipeline. Because the OPTIONS request does not carry the protected payload, the router never executes the predicate, and the subsequent actual request (e.g., POST) can be sent without the same verification.

Key observations from the advisory:

  • The bug is present in every Spring Framework major line from 5.2 up to 7.0, as indicated by the version ranges.
  • The fix introduced in 7.0.9 changes the internal ordering of the CORS filter relative to the functional router, guaranteeing that the header predicate is evaluated for pre‑flight requests as well.
  • No change is reported for the 5.x, 6.x, or earlier 7.x series, meaning those releases remain vulnerable unless a back‑ported fix is provided by the maintainers.

Because the vulnerability relies on CORS pre‑flight semantics, it is only exploitable in cross‑origin scenarios where a malicious web page can trigger the OPTIONS request from a victim’s browser. The attack surface therefore includes any public‑facing API that mixes functional routing with a DispatcherServlet and performs critical authorization based solely on header predicates.

Affected Software and Versions

All affected entries reference the same Maven coordinate org.springframework:spring-webflux. The advisory enumerates six distinct version ranges, each representing a major branch. The table below captures the precise boundaries:

Package Ecosystem Range Type Introduced Last Affected Fixed Version
org.springframework:spring-webflux Maven ECOSYSTEM 5.2.5.RELEASE 5.2.25.RELEASE Not specified
org.springframework:spring-webflux Maven ECOSYSTEM 5.3.0 5.3.49 Not specified
org.springframework:spring-webflux Maven ECOSYSTEM 6.0.0 6.0.30 Not specified
org.springframework:spring-webflux Maven ECOSYSTEM 6.1.0 6.1.28 Not specified
org.springframework:spring-webflux Maven ECOSYSTEM 6.2.0 6.2.19 Not specified
org.springframework:spring-webflux Maven ECOSYSTEM 7.0.0 7.0.8 7.0.9

Note that the database_specific.last_known_affected_version_range field reinforces the upper bound for the 7.x series as <= 7.0.8. No fixed versions are listed for the older series, which means organizations must either upgrade to 7.0.9 (or later) or track any forthcoming back‑ports.

Severity and Risk Interpretation

The advisory rates the vulnerability as CRITICAL and provides a CVSS v3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Interpreting the vector:

  • Attack Vector (AV:N): The exploit can be performed remotely over a network.
  • Attack Complexity (AC:L): Low; no special conditions beyond a crafted pre‑flight request.
  • Privileges Required (PR:N): None; the attacker does not need authenticated access.
  • User Interaction (UI:N): None; the attack does not rely on the victim clicking a link.
  • Scope (S:U): Unchanged; the vulnerability does not affect resources beyond the vulnerable component.
  • Confidentiality, Integrity, Availability (C:H/I:H/A:H): All three impact metrics are rated High, meaning a successful bypass could lead to full data exfiltration, data tampering, or service disruption.

While the CVSS score is not numerically calculated in the supplied record, the vector itself maps to a score of 9.8 (critical) according to the CVSS v3.1 specification. This reinforces the need for immediate attention, especially for public‑facing services.

Who Should Investigate

  • Application developers who have built Spring Boot or Spring Framework based microservices using WebFlux functional routing.
  • Security engineering teams responsible for API security and CORS configuration.
  • DevOps and platform engineers who manage deployment pipelines for Java services, especially those packaging Spring Boot applications into Docker containers.
  • Enterprise architects overseeing Java technology stacks and standardizing library versions across the organization.
  • SBOM analysts and compliance officers who maintain software composition analysis (SCA) reports.

How to Check Whether an Application Is Affected

The verification process depends on the build and dependency management toolchain used in the project. Below are ecosystem‑specific steps for Maven‑based Java projects, which is the packaging format for spring-webflux:

  1. Inspect the Maven dependency tree. Run: 
    mvn dependency:tree -Dincludes=org.springframework:spring-webflux

    This will list the resolved version of spring-webflux and any transitive inclusions.

  2. Check the pom.xml or build.gradle files. Look for explicit version declarations: 
    <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webflux</artifactId>
    <version>6.1.15</version>
</dependency>

    If the version falls within any of the ranges listed above, the application is potentially vulnerable.

  3. Use a Software Composition Analysis (SCA) tool. Tools such as Dependency‑Check, Snyk, or OWASP Dependency‑Track can ingest the project’s pom.xml or generated dependency‑tree.txt and automatically flag the advisory GHSA-9qf2-26p9-2q2q if a matching version is detected.
  4. Examine generated SBOMs. If you export a CycloneDX or SPDX SBOM, locate the component with purl pkg:maven/org.springframework/spring-webflux. Compare its version field against the affected ranges.
  5. Review container images. For Docker images that embed a Spring Boot JAR, extract the JAR manifest or run: 
    docker run --rm your-image java -jar app.jar --list-dependencies | grep spring-webflux

    Verify the printed version.

Do not assume that merely having spring-webflux on the classpath makes the application vulnerable; the version boundary checks are essential.

Remediation and Mitigation

The advisory provides a fixed version only for the 7.x series: 7.0.9. The recommended remediation steps are:

  1. Upgrade to 7.0.9 or later. Update the Maven (or Gradle) dependency declaration to: 
    <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webflux</artifactId>
    <version>7.0.9</version>
</dependency>

    For Gradle (Kotlin DSL):

    implementation("org.springframework:spring-webflux:7.0.9")
  2. Check for back‑ported patches. Review the Spring Framework release notes and the advisory page Spring Security Advisory for any security patches that may have been back‑ported to the 5.x or 6.x branches. If a back‑port exists, upgrade to the indicated patch level.
  3. Validate CORS configuration. Ensure that the CORS filter is configured to apply to all HTTP methods, including OPTIONS, and that any header‑based security predicates are duplicated in a dedicated security filter that runs before CORS processing.
  4. Test the fix. After upgrading, write integration tests that simulate a CORS pre‑flight request to a protected functional endpoint and verify that the header predicate is enforced (i.e., the request is rejected when the required header is missing or malformed).
  5. Fallback mitigation if you cannot upgrade. As a temporary measure, you may:
    • Disable functional routing for endpoints that rely on header predicates and replace them with traditional @RequestMapping handlers where the security logic is applied earlier.
    • Enforce additional server‑side checks (e.g., a servlet filter) that validates the relevant headers for both the pre‑flight and actual request.

    These mitigations reduce the attack surface but do not replace a proper library upgrade.

Post‑Remediation Verification

After applying the upgrade or mitigation, perform the following checklist to confirm remediation:

  • Confirm that the project’s dependency tree now reports spring-webflux version 7.0.9 (or a later patched version).
  • Re‑run the SCA scan to ensure the advisory GHSA-9qf2-26p9-2q2q is no longer flagged.
  • Generate an updated SBOM (CycloneDX or SPDX) and validate that the component entry for spring-webflux reflects the fixed version.
  • Execute the CORS pre‑flight test suite described earlier. A successful test should result in a 403 Forbidden (or appropriate error) when the required header is absent.
  • Redeploy the application to a staging environment and perform end‑to‑end functional testing to verify that legitimate requests continue to succeed.
  • Document the remediation steps, version numbers, and test results in the project’s security backlog or compliance artefact for audit purposes.

Developer and DevSecOps Recommendations

  • Adopt automated dependency updates. Tools such as Dependabot, Renovate, or Snyk can automatically open pull requests when a new safe version of spring-webflux is released.
  • Integrate SBOM generation into CI/CD. Generate a CycloneDX SBOM at each build and feed it to a scanning stage that blocks merges when a critical advisory is present.
  • Enforce layered security checks. Do not rely solely on header predicates for authorization. Complement them with method‑level security annotations (@PreAuthorize) or a dedicated security filter that runs before CORS processing.
  • Monitor Spring Framework security announcements. Subscribe to the Spring Security mailing list or RSS feed to receive early notice of patches.
  • Document CORS policies. Keep a central configuration file that defines allowed origins, methods, and required headers. Treat changes to this file as security‑relevant code changes.

Explore on cve.sbom.guru

For further context and to track future updates, consult the internal knowledge‑base entries:

Authoritative References

Key Takeaways

  • The critical header predicate bypass (GHSA-9qf2-26p9-2q2q / CVE-2026-47892) affects org.springframework:spring-webflux versions 5.2.5.RELEASE through 7.0.8.
  • Only version 7.0.9 contains an official fix; earlier branches lack a published patch.
  • Immediate action: upgrade to 7.0.9 or a later patched release, or apply a temporary server‑side filter that validates the required headers for OPTIONS requests.
  • Validate remediation with SBOM scans, dependency‑tree checks, and CORS pre‑flight integration tests.
  • Integrate automated dependency monitoring and SBOM generation to prevent recurrence.

Freshness Note

Vulnerability records evolve as new fixes are released and additional analysis becomes available. Readers should consult the advisory on cve.sbom.guru and the official Spring security page for the latest status before implementing remediation actions.