Jul 30, 2026·6 min read·56 visits
Quarkus applications prior to 3.37.0 are vulnerable to an authentication bypass where encoded characters (%3B, %2F, %5C) prevent security filters from matching path-based policies, while downstream routers decode and execute the requests.
A critical authentication and authorization bypass vulnerability in the Quarkus Java framework exists due to a parser differential mismatch between the HTTP security policy layer and downstream handlers. By leveraging encoded reserved characters such as semicolons, slashes, and backslashes, attackers can bypass configured path-based security policies to gain unauthorized access to secure administrative endpoints and static resources.
The Quarkus Java framework uses a robust HTTP routing and policy architecture to protect endpoints from unauthorized access. Developers configure authorization boundaries using path-based rules defined under the application configuration namespace quarkus.http.auth.permission.*. These policies are evaluated by the security policy engine, centered around the class AbstractPathMatchingHttpSecurityPolicy, which inspects incoming requests to match them against the protected path declarations.
This architecture exposes a critical attack surface when there is an inconsistency in how different components normalize and parse HTTP request paths. The vulnerability identified as CVE-2026-50559 is a classic parser differential mismatch. The security layer evaluates paths using one normalization model, while downstream request-handling components (such as JAX-RS REST routers and Vert.x static resource handlers) normalize and resolve paths using a more permissive model.
By leveraging this parser mismatch, unauthenticated remote attackers can craft specific URI patterns that bypass configured path permissions entirely. When a request bypasses the security layer, it is subsequently routed to the target controller or filesystem endpoint, allowing unauthorized execution or retrieval. This security flaw is categorized under CWE-287 (Improper Authentication) and CWE-863 (Incorrect Authorization).
The root cause of CVE-2026-50559 lies in how the Quarkus security layer retrieves and processes the request path from Vert.x. Historically, the policy matcher evaluated permissions against the path returned by Vert.x's RoutingContext.normalizedPath() method. While this method performs standard path cleaning, its implementation follows RFC 3986, which decodes unreserved characters but leaves reserved characters percent-encoded.
This behavior means that critical reserved characters, such as semicolons (%3B), forward slashes (%2F), and backslashes (%5C), remain in their percent-encoded format in the string evaluated by the security policy matcher. The matching engine compares the exact encoded path (e.g., /api/admin%3Bparam/data) against configured paths like /api/admin/*. Because of the mismatch in the literal trailing string, the matcher fails to identify the request as matching a restricted path, permitting the request to pass.
Downstream routing components process the path differently. JAX-RS REST routers and Vert.x static file handlers execute subsequent passes of percent-decoding and path parsing. For instance, the REST routing layer decodes %3B to ;, extracts matrix parameters, and normalizes the target path to /api/admin/data. The static file handler decodes %2F to / and processes directory paths. This allows the request to execute on the secure endpoint without ever triggering the authorization controls.
Prior to the patch, the Quarkus security policy engine performed naive cleaning of the request path using HttpSecurityUtils.pathWithoutMatrixParams(). This method searched for a literal semicolon character (;) and stripped any trailing parameters. It failed to check for percent-encoded semicolons (%3B or %3b), leaving them intact during permission evaluation.
// Vulnerable pattern:
String requestPath = HttpSecurityUtils.pathWithoutMatrixParams(request.normalizedPath());The maintainers resolved this vulnerability by replacing the naive logic with a centralized and rigorous normalizer HttpSecurityUtils.normalizePath(). This helper function is invoked globally by policy enforcers to resolve the parser differential before any permission matching occurs.
// Patched pattern:
String requestPath = HttpSecurityUtils.normalizePath(request.normalizedPath());The implementation of normalizePath applies sequential decoding, sanitization, separator normalization, and relative path resolution to eliminate the parser differential. It uses a recursive percent-decoding loop to neutralize double-encoded bypass attempts, strips matrix parameters after ensuring all semicolons are decoded, removes raw null bytes to prevent truncation attacks, normalizes backslashes to forward slashes, and resolves relative dot segments.
public static String normalizePath(String path) {
// Recursive percent decoding to neutralize nested encoding tricks
while (path.indexOf('%') >= 0) {
String decoded = decodePercent(path);
if (decoded.equals(path)) {
break;
}
path = decoded;
}
// Strip matrix parameters after the encoded semicolon is resolved
path = pathWithoutMatrixParams(path);
// Remove null bytes to counter raw C-style string termination exploits
if (path.indexOf('\\0') >= 0) {
path = path.replace("\\0", "");
}
// Normalize backslashes to forward slashes for unified cross-platform paths
if (path.indexOf('\\\\') >= 0) {
path = path.replace('\\\\', '/');
}
// Remove relative dot segments (. and ..)
path = HttpUtils.removeDots(path);
return path;
}An attacker can exploit this vulnerability by executing crafted HTTP requests designed to bypass the path matching logic while resolving to the target secure endpoint downstream. The principal exploit vectors are split into matrix parameter smuggling, static resource bypasses, and double-encoding bypasses.
For a matrix parameter smuggling attack against JAX-RS controllers, the attacker issues a request to GET /api/admin%3Bbypass=true/data. The security layer evaluates the literal path /api/admin%3Bbypass=true/data and does not match the rule /api/admin/*. The JAX-RS router decodes the %3B, extracts the parameter, matches the path to the administrative endpoint, and returns the protected data.
To target static files, an attacker relies on the Vert.x static resource handler decoding behavior. If access is restricted to /static-secret.html, requesting GET /static-secret%2Fhtml or GET /static-secret%5Chtml bypasses the security layer because the literal path fails the authorization pattern match. The static handler decodes the delimiter and serves the contents of the target file.
The impact of CVE-2026-50559 is categorized as high, yielding a CVSS score of 7.5. The vulnerability permits unauthenticated, remote attackers to bypass authorization constraints. This allows full compromise of the application context, enabling unauthorized administrative actions, data exposure, or server-side request manipulation.
The exploit complexity is low, and the vulnerability requires no user interaction or specialized privileges. This makes it a high-value target for automated scanners and malicious actors seeking initial access into cloud-native environments built on Quarkus.
This vulnerability represents a complete bypass of the initial fix introduced for CVE-2026-39852. While the earlier fix successfully addressed literal semicolon stripping, it did not account for percent-encoded delimiters, double-encoded variations, or filesystem-specific separators. This highlights the danger of partial sanitization inside security filters.
To remediate CVE-2026-50559, administrators and developers must upgrade their Quarkus dependencies to the patched release branches. The fix is included in versions 3.37.0, 3.36.3, 3.33.2.1, 3.27.4.1, and 3.20.6.2. Applications using older development releases must be upgraded immediately to prevent exploitation.
If immediate dependency updates are not possible, temporary mitigations can be implemented at the network perimeter. Web Application Firewalls (WAFs) and API Gateways should be configured with custom rules to reject URIs containing %3B, %3b, %2F, %2f, %5C, %5c, or double-encoded characters like %25. These edge devices must normalize paths prior to forwarding requests downstream.
Developers should enforce a defense-in-depth authorization architecture rather than relying solely on path-based security rules. Programmatic declarative annotations, such as @RolesAllowed, @Secured, or custom security interceptors applied directly to controller methods, provide strong protection. These programmatic controls do not depend on the HTTP path normalization layers, preventing routing-level bypasses.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N| Attribute | Detail |
|---|---|
| CWE ID | CWE-287 / CWE-863 |
| Attack Vector | Network |
| CVSS v3.1 Score | 7.5 (High) |
| EPSS Score | 0.00463 (37.7th percentile) |
| Impact | Authentication & Authorization Bypass |
| Exploit Status | Proof of Concept (PoC) Available |
| CISA KEV Status | Not Listed |
A path traversal vulnerability (CWE-22) in Contao CMS allows unauthenticated remote attackers to bypass directory boundary restrictions in ImagesController and access files within the project directory.
Contao Open Source CMS versions 4.0.0 through 5.3.49 and 5.4.0-RC1 through 5.7.11 contain a Cross-Site Request Forgery (CSRF) vulnerability in backend parameter handling. The `RequestTokenListener` component validates anti-CSRF tokens solely for HTTP POST requests, while GET-based declarative guards run only when an `act` parameter is present in the query string. Consequently, custom backend actions dispatched via alternative parameters such as `key=` can execute without CSRF token verification when triggered by an authenticated user.
Contao CMS versions 4.1.0 through 5.3.49 and 5.4.0-RC1 through 5.7.11 fail to validate form submission tokens and enforce rate limiting when processing activation email resend requests via HTTP POST, enabling resource exhaustion and account state enumeration.
An information disclosure vulnerability in Contao CMS allows unauthenticated site visitors to view protected page titles, URLs, and text excerpts through search queries when protected page indexing is disabled after previously being enabled.
In Vikunja prior to version 2.6.0, relation creation via the CalDAV endpoint fails to invoke the TaskRelation.CanCreate authorization check. This missing access control allows an authenticated user to establish unauthorized relationships and perform write operations against any task, provided its unique identifier (UID) is known.
A cross-project information disclosure vulnerability in Vikunja allows authenticated users with read access to one project to view private task details from unauthorized projects via subtask expansion parameters.