Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
3.27.4.13.37.03.33.2.13.36.33.20.6.2· Vendor fix available
Issue
Quarkus HTTP path-based authorization policies can be bypassed using encoded semicolons (%3B) to smuggle matrix parameters past the security layer, and using encoded slashes (%2F) or backslashes (%5C) to access protected static resources. This is a distinct issue from CVE-2026-39852, which addressed only literal semicolon stripping. Technical Details The security layer (AbstractPathMatchingHttpSecurityPolicy) normalizes request paths using Vert.x's normalizedPath(), which only decodes unreserved RFC 3986 characters (letters, digits, -, ., , ~). It then strips matrix parameters by looking for literal ; characters. This creates two mismatches: 1. Encoded semicolons (%3B): Since %3B is not decoded by normalizedPath(), the matrix parameter stripping in pathWithoutMatrixParams() never sees it. The encoded semicolon and everything after it become part of the path segment, causing policy matching to fail. This affects all path-policy-protected endpoints. 2. Static resource path…
Recommended action: Upgrade to 3.37.0, 3.36.3, 3.33.2.1 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
3.35.1.13.33.1.13.27.3.13.20.6.1· Vendor fix available
Issue
Quarkus version 3.32.4 is vulnerable to an authorization bypass issue (GHSL-2026-099), in which semicolons (matrix parameters) in HTTP requests can be used to bypass security constraints, potentially allowing unauthorized access to protected resources. Unauthenticated or lower-privileged users can bypass HTTP path-based authorization policies by appending a semicolon (;) and arbitrary text to the request URL. The vulnerability arises from a path-normalization inconsistency: Quarkus's security layer performs authorization checks on the raw URL path (which preserves matrix parameters), whereas RESTEasy Reactive's routing layer strips matrix parameters before matching endpoints. This allows requests like /api/admin;anything to bypass policies protecting /api/admin while still routing to the protected endpoint. Impact This issue may lead to Authentication/Authorization bypasses. Credits This issue was discovered with the GitHub Security Lab Taskflow Agent and manually verified by GHSL…
Recommended action: Upgrade to 3.35.1.1, 3.33.1.1, 3.27.3.1 or 3.20.6.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
2.16.11.Final3.3.33.2.6.Final· Vendor fix available
Issue
A flaw was found in Quarkus where HTTP security policies are not sanitizing certain character permutations correctly when accepting requests, resulting in incorrect evaluation of permissions. This issue could allow an attacker to bypass the security policy altogether, resulting in unauthorized endpoint access and possibly a denial of service.
Recommended action: Upgrade to 3.3.3, 3.2.6.Final or 2.16.11.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If the Quarkus Form Authentication session cookie Path attribute is set to / then a cross-site attack may be initiated which might lead to the Information Disclosure. This attack can be prevented with the Quarkus CSRF Prevention feature.
Recommended action: Upgrade to 2.13.7.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Quarkus CORS filter allows simple GET and POST requests with invalid Origin to proceed. Simple GET or POST requests made with XMLHttpRequest are the ones which have no event listeners registered on the object returned by the XMLHttpRequest upload property and have no ReadableStream object used in the request.
Recommended action: Upgrade to 2.14.2.Final or 2.13.5.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.