CVE-2026-19651

Overview

Quarkus is a Kubernetes-native Java framework optimized for cloud-native applications, containers, and serverless workloads. It builds on standard libraries (Jakarta EE, Eclipse Vert.x, Hibernate, Netty) and compiles to both JVM and GraalVM native images for fast startup and low memory use. The quarkus-spring-web extension provides a Spring Web compatibility layer, translating Spring MVC controller annotations such as @RestController, @RequestMapping, @RequestParam and @RequestHeader into their Jakarta REST equivalents so that Spring-style controllers can run on the Quarkus REST (RESTEasy Reactive) stack.

An Authorization Bypass vulnerability (CVE-2026-19651) has been identified in the Spring Web compatibility layer for Quarkus REST, which allows attackers to supply values for HTTP request headers through the URL query string, defeating header values that an application expects a reverse proxy or gateway to set, overwrite or strip.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects the Spring Web compatibility layer of Quarkus.

Details

Module Info

• Product: NES for Quarkus
• Affected packages: io.quarkus:quarkus-spring-web
• Affected versions: <3.39.2
• GitHub repository: https://github.com/quarkusio/quarkus
• Published packages: https://central.sonatype.com/artifact/io.quarkus/quarkus-spring-web
• Package manager: Maven
• Fixed in:
  • NES for Quarkus 2.16.15 and 3.20.8
  • OSS Quarkus 3.27.5.2, 3.33.3.2, and 3.39.2

Vulnerability Info

This High-severity vulnerability is found in the io.quarkus:quarkus-spring-web package in the Spring Web compatibility layer for the Quarkus REST (RESTEasy Reactive) stack of Quarkus.

When the extension processes a Spring MVC controller, it walks each handler method parameter and rewrites the Spring annotation into the equivalent Jakarta REST parameter annotation. Every annotation is mapped to its matching parameter source except one: @RequestHeader is translated to the query-parameter binding that @RequestParam uses, so the value is read from the query string instead of from the HTTP request header.

DotName jaxRsAnnotation;
if (annotationName.equals(REQUEST_PARAM)) {
    jaxRsAnnotation = REST_QUERY_PARAM;
} else if (annotationName.equals(REQUEST_HEADER)) {
    jaxRsAnnotation = REST_QUERY_PARAM;
} else if (annotationName.equals(COOKIE_VALUE)) {
    jaxRsAnnotation = REST_COOKIE_PARAM;
} else {
    jaxRsAnnotation = REST_MATRIX_PARAM;
}

The consequence is that the value a controller reads from a @RequestHeader-annotated parameter never comes from the request headers at all. A remote caller can populate it simply by appending a query parameter of the same name to the request URL, and the real header of that name is ignored entirely.

This breaks a common deployment assumption. Applications frequently rely on infrastructure in front of the service to authenticate the caller and inject trusted headers, such as an identity or tenant header written by a gateway, or to strip client-supplied spoofing headers at the edge. Because the edge only inspects and rewrites headers, it has no reason to filter the query string, so an attacker-supplied query parameter passes straight through and is delivered to the controller as though it were the sanitized header. Any authorization, tenancy or trust decision the controller makes from that parameter is therefore made on fully attacker-controlled input. The same mapping also means genuinely header-driven behavior silently fails to see real headers.

The mis-mapping is limited to the Quarkus REST (RESTEasy Reactive) stack, which is the default REST stack in current Quarkus releases. Controllers running on the classic RESTEasy stack resolve @RequestHeader through a different code path and honor header semantics correctly.

Mitigation

Only recent versions of Quarkus are community-supported. The 2.16.x and 3.20.x lines were already End-of-Life when this CVE was published and will not receive public updates to address this issue. Quarkus LTS releases are maintained for 12 months from release; see the project's LTS release policy.

Users of the affected components should apply one of the following mitigations:

• Upgrade Quarkus to a currently supported release that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Michael-JRead (finder)