CVE-2026-39852: Quarkus authorization bypass via semicolon path normalization inconsistency
Quarkus is a Java framework for building cloud-native applications. In versions prior to 3.20.6.1, 3.27.3.1, 3.33.1.1, 3.35.1.1, 3.34.7, and 3.35.2, a path normalization inconsistency between the security layer and the routing layer allows unauthenticated or lower-privileged users to bypass HTTP path-based authorization policies. Quarkus's security layer performs authorization checks on the raw URL path which preserves matrix parameters (semicolons), while RESTEasy Reactive's routing layer strips matrix parameters before matching endpoints. An attacker can append a semicolon and arbitrary text to a request URL (e.g., /api/admin;anything) to bypass policies protecting /api/admin while still routing to the protected endpoint. This issue has been fixed in versions 3.20.6.1, 3.27.3.1, 3.33.1.1, 3.35.1.1, 3.34.7, and 3.35.2.
Security readout for executives and security teams
Plain-English summary
Affected Quarkus applications may let an unauthenticated or lower-privileged user reach protected HTTP endpoints by altering the requested path. The security check and application router interpret semicolon-containing paths differently, potentially exposing sensitive data or permitting unauthorized changes without credentials or user interaction.
Executive priority
Treat as a high-priority patching issue for reachable applications because exploitation needs no account and can bypass central access controls. Expedite remediation for administrative or sensitive-data routes. Emergency incident response is not justified solely by the supplied evidence because active exploitation is not established.
Technical view
Quarkus security evaluates the raw path, retaining matrix parameters, while RESTEasy Reactive strips them before endpoint matching. Consequently, authorization may evaluate an apparently unprotected path while routing reaches a protected endpoint. The issue is classified as CWE-551 and CWE-863 and carries CVSS 4.0 score 8.8.
Likely exposure
Exposure is most likely in internet-accessible or otherwise untrusted-reachable Quarkus applications running affected versions, using RESTEasy Reactive endpoints protected by HTTP path-based authorization. Applications using unaffected versions or authorization enforced independently at the endpoint may not be exposed; the supplied sources do not enumerate every configuration dependency.
Exploitation context
The attack is remotely reachable, low complexity, requires no privileges or user interaction, and primarily threatens confidentiality. The bundle marks this CVE as absent from KEV and provides no cited evidence of active exploitation. That does not establish that exploitation has never occurred.
Researcher notes
The core flaw is inconsistent canonicalization across authorization and routing boundaries. Review should focus on whether both layers authorize the same normalized path and whether endpoint-level controls provide defense in depth. The CVSS vector indicates high confidentiality impact, low integrity impact, and no stated availability impact. Avoid assuming all Quarkus deployments are exploitable without configuration validation.
Mitigation direction
Inventory Quarkus versions and identify applications using RESTEasy Reactive with path-based authorization.
Upgrade to an applicable fixed release: 3.20.6.1, 3.27.3.1, 3.33.1.1, 3.34.7, 3.35.1.1, or 3.35.2.
Apply the relevant Red Hat erratum when using affected Red Hat-distributed components.
Prioritize externally reachable administrative, account, financial, and sensitive-data endpoints.
Consult Quarkus or Red Hat guidance if immediate upgrading is operationally constrained.
Validation and detection
Confirm deployed Quarkus versions against the affected ranges and fixed-release list.
Map path-based authorization policies to their RESTEasy Reactive endpoints.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-551: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
CWE-863: Authorization and privilege behavior lookup
Authorization weaknesses can support privilege escalation and valid-account review, depending on exploit path. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references privilege impact, so privilege escalation and authorization behavior review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-551 · source CWE mapping
Incorrect Behavior Order: Authorization Before Parsing and Canonicalization
Incorrect Behavior Order: Authorization Before Parsing and Canonicalization represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Incorrect Authorization represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.