CVE-2026-87743

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-vertx-http extension provides the Vert.x based HTTP layer of Quarkus, including the path-based HTTP security permissions configured with quarkus.http.auth.permission.*.

An authorization bypass vulnerability (CVE-2026-87743) has been identified in Quarkus HTTP security, which allows unauthenticated attackers to reach endpoints protected by path-based permission policies. A crafted URL is evaluated by the security matcher as a different, possibly public, path while the router still dispatches it to the protected endpoint, which can lead to unauthorized access to sensitive information.

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 multiple versions of Quarkus that include the affected io.quarkus:quarkus-vertx-http package.

Details

Module Info

• Product: Quarkus
• Affected packages: io.quarkus:quarkus-vertx-http
• Affected versions: >=3.20.6.2 <3.21.0.CR1, >=3.27.4.1 <3.27.5.3, >=3.33.2.1 <3.33.3.3, >=3.36.3 <3.37.0.CR1, >=3.37.0 <3.38.0.CR1, >=3.38.1 <3.39.5, >=3.40.0.CR1 <3.40.0
• GitHub repository: https://github.com/quarkusio/quarkus
• Published packages: https://central.sonatype.com/artifact/io.quarkus/quarkus-vertx-http
• Package manager: Maven
• Fixed in:
  • OSS Quarkus 3.27.5.3, 3.33.3.3, 3.39.5, 3.40.0
  • NES for Quarkus v2.16.12, v3.20.10

Vulnerability Info

This High-severity vulnerability is found in the io.quarkus:quarkus-vertx-http package in multiple versions of Quarkus. Path-based HTTP permissions (quarkus.http.auth.permission.<name>.paths) are enforced by AbstractPathMatchingHttpSecurityPolicy, which looks up the policies for a request by matching its path against the configured paths. The lookup does not use the path the router dispatches on. It first passes RoutingContext.normalizedPath() through HttpSecurityUtils.normalizePath(...), a much more aggressive normalization:

String normalizedPath = context.normalizedPath();
PathMatch<List<HttpMatcher>> toCheck = pathMatcher.match(HttpSecurityUtils.normalizePath(normalizedPath));
if (toCheck.getValue() == null || toCheck.getValue().isEmpty()) {
    return result;
}

HttpSecurityUtils.normalizePath(...) strips matrix parameters and decodes repeatedly before it resolves dot segments, so a segment such as ..; or ..;x=1 (or the double-encoded %252e%252e;) is treated as .. and removes the segment before it. The router does not treat ..; as a dot segment and keeps the original structure. For a request to /admin/..;/secret, the security matcher checks /secret, while the router dispatches the request to a handler under /admin/*. With a configuration such as quarkus.http.auth.permission.admin.paths=/admin/* and policy=authenticated, the protected policy is never applied, or a permit policy for the collapsed path is applied instead (for example /admin/..;/public/data matching a /public/* permit policy). An unauthenticated attacker can therefore reach the protected endpoint and read the data it returns.

Mitigation

Only recent versions of Quarkus are community-supported. Older lines are End-of-Life 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 Read (finder)