A flaw was found in the json payload. If annotation based security is used to secure a REST resource, the JSON body that the resource may consume is being processed (deserialized) prior to the security constraints being evaluated and applied. This does not happen with configuration based security.

A flaw was found in undertow. The undertow client is not checking the server identity the server certificate presents in HTTPS connections. This is a compulsory step ( that should at least be performed by default) in HTTPS and in http/2.

It was found that Quarkus 2.10.x does not terminate HTTP requests header context which may lead to unpredictable behavior.

Critical: Red Hat build of Quarkus 3.8.6.SP1 Security Update

Critical: Red Hat build of Quarkus 3.2.12.SP1 Security Update

A flaw was found in Quarkus in versions prior to 2.7.1.Final. State and potentially associated permissions can leak from one web request to another in RestEasy Reactive, leading to the possibility of a low-privileged user to be able to perform operations on the database with a different set of privileges than intended.

Upstream commit: https://github.com/quarkusio/quarkus/pull/23397

A flaw was found in Keycloak before version 11.0.0, where the code base contains usages of ObjectInputStream without type checks. This flaw allows an attacker to inject arbitrarily serialized Java Objects, which would then get deserialized in a privileged context and potentially lead to remote code execution.

In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. The problem has been patched and released with Gradle 7.0. As a workaround, on Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. If you are unable to change the permissions of the system temporary directory, you can move the Java temporary directory by setting the System Property java.io.tmpdir. The new path needs to limit permissions to the build user only. For additional details refer to the referenced GitHub Security Advisory.

In Gradle from version 5.1 and before version 7.0 there is a vulnerability which can lead to information disclosure and/or dependency poisoning. Repository content filtering is a security control Gradle introduced to help users specify what repositories are used to resolve specific dependencies. This feature was introduced in the wake of the "A Confusing Dependency" blog post. In some cases, Gradle may ignore content filters and search all repositories for dependencies. This only occurs when repository content filtering is used from within a pluginManagement block in a settings file. This may change how dependencies are resolved for Gradle plugins and build scripts. For builds that are vulnerable, there are two risks: 1) Information disclosure: Gradle could make dependency requests to repositories outside your organization and leak internal package identifiers. 2) Dependency poisoning/Dependency confusion: Gradle could download a malicious binary from a repository outside your organization due to name squatting. For a full example and more details refer to the referenced GitHub Security Advisory. The problem has been patched and released with Gradle 7.0. Users relying on this feature should upgrade their build as soon as possible. As a workaround, users may use a company repository which has the right rules for fetching packages from public repositories, or use project level repository content filtering, inside buildscript.repositories. This option is available since Gradle 5.1 when the feature was introduced.

A flaw was found in Quarkus, where it does not properly sanitize artifacts created using the Gradle plugin, allowing certain build system information to remain. This flaw allows an attacker to access potentially sensitive information from the build system within the application.

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 mismatch: Static resource handlers (StaticHandlerImpl, FileSystemStaticHandler) perform full percent-decoding via URIDecoder.decodeURIComponent() and backslash-to-slash conversion before filesystem resolution. Reserved characters like %2F (slash) and %5C (backslash) that survive the security layer's partial decoding are fully decoded before file serving.

REST endpoints using Quarkus REST (RESTEasy Reactive) are not affected by the %2F/%5C vectors because the routing layer also uses normalizedPath() — both security and routing agree on the path, so no mismatch exists.

Attack Vectors

Encoded semicolon (matrix parameter smuggling), affects all path-policy-protected endpoints: - /api/admin%3Bbypass=true/data: security sees this as a single segment admin%3Bbypass=true, which does not match the /api/admin/ policy. The request passes through unauthenticated. - /api/secret%3b/data: same mechanism with lowercase hex digit.

Encoded slash/backslash on static resources, affects static files behind path policies: - /static-secret%2Fhtml, security does not match /static-secret.html policy; static handler decodes %2F to / and may resolve the file. - /static-secret%5Chtml . static handler decodes %5C to \, then converts to /.

Double encoding, affects static resources: - /secret%252Fconfidential.html, first decode by normalizedPath() turns %25 into %, producing %2F. Static handler's second decode turns %2F into /.

The following vectors were investigated and confirmed not exploitable:

- Unreserved character encoding (/api/adm%69n/data): normalizedPath() decodes these. Both security and routing see /api/admin/data. - Null byte injection (/api/admin%00/data): %00 is not decoded by normalizedPath(). - Encoded dot segments (/api/%2e%2e/secret/data): Period is unreserved, so %2e is decoded to . by normalizedPath(), then removeDots() normalizes .. segments. - REST endpoint bypass via %2F/%5C: Routing uses the same normalizedPath() as security. The encoded slash/backslash doesn't match any route.

Root Cause

pathWithoutMatrixParams() operates on the partially-decoded output of normalizedPath(), where reserved characters remain encoded. It searches for literal ; but never sees %3B. The fix (normalizePath()) performs full percent-decoding in a loop before stripping matrix parameters, removing null bytes, normalizing backslashes, and resolving dot segments, aligning the security layer's view of the path with what downstream handlers resolve.

Impact

- Unauthenticated access to endpoints protected by quarkus.http.auth.permission path-based policies via %3B smuggling - Static resource exposure by bypassing path policies on protected files via %2F/%5C - Applications using annotation-based security (@RolesAllowed, @Authenticated) on JAX-RS resources without path-based policies are not affected by the %2F/%5C vectors, but may still be affected by %3B if path policies coexist

Proof of Concept

# Encoded semicolon bypass — works on any path-policy-protected endpoint # Security sees "/api/admin%3Bbypass=true/data", doesn't match /api/admin/ policy curl -v http://target/api/admin%3Bbypass=true/data

# Encoded semicolon on authenticated endpoint curl -v http://target/api/secret%3b/data

# Static resource bypass via encoded slash (if static file behind path policy) curl -v http://target/static-secret%2Fhtml

# Static resource bypass via encoded backslash curl -v http://target/static-secret%5Chtml

A flaw was found in Undertow where a potential security issue in flow control handling by browser over HTTP/2 may potentially cause overhead or DOS in the server. The highest impact of this vulnerability is availability.(incomplete fix for CVE-2021-3629)

A flaw was found in Undertow. A buffer leak on the incoming WebSocket PONG message may lead to memory exhaustion. This flaw allows an attacker to cause a denial of service. The highest threat from this vulnerability is availability.

A flaw was found in Quarkus. Quarkus OIDC can leak both ID and access tokens in the authorization code flow when an insecure HTTP protocol is used, which can allow attackers to access sensitive user data directly from the ID token or by using the access token to access user data from OIDC provider services. Please note that passwords are not stored in access tokens.

Important: Red Hat build of Quarkus 2.13.9.SP1 release and security update

Important: Red Hat build of Quarkus 3.2.9.SP1 release and security update

Important: Red Hat build of Quarkus 3.2.10 release and security update

An update for Red Hat Build of Apache Camel 4.0 for Quarkus 3.2 is now available (updates to RHBQ 3.2.10.Final). The purpose of this text-only errata is to inform you about the enhancements that improve your developer experience and ensure the security and stability of your products.Security Fix(es): parsson: Denial of Service due to large number parsing (CVE-2023-4043) santuario: Private Key disclosure in debug-log output (CVE-2023-44483) ssh: Prefix truncation attack on Binary Packet Protocol (BPP) (CVE-2023-48795) json-path: stack-based buffer overflow in Criteria.parse method (CVE-2023-51074) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Important: Red Hat build of Quarkus 3.2.11 release and security update

An update for Red Hat Build of Apache Camel 4.0 for Quarkus 3.2 is now available (updates to RHBQ 3.2.11).<br>The purpose of this text-only errata is to inform you about the enhancements that improve your developer experience and ensure the security and stability of your products:<br><li> TRIAGE CVE-2024-25710 commons-compress: Denial of service caused by an infinite loop for a corrupted DUMP file</li> <li> TRIAGE CVE-2024-26308 commons-compress: OutOfMemoryError unpacking broken Pack200 file</li> <li> TRIAGE CVE-2024-1300 vertx-core: io.vertx:vertx-core: memory leak when a TCP server is configured with TLS and SNI support</li> <li> TRIAGE CVE-2024-1023 vert.x: io.vertx/vertx-core: memory leak due to the use of Netty FastThreadLocal data structures in Vertx</li>

Important: Red Hat build of Quarkus 2.13.9.SP2 release and security update

An update for Red Hat Build of Apache Camel 4.0 for Quarkus 3.2 update is now available (RHBQ 3.2.12.GA).The purpose of this text-only errata is to inform you about the enhancements that improve your developer experience and ensure the security and stability of your products.: TRIAGE CVE-2024-28752 cxf-core: Apache CXF SSRF Vulnerability using the Aegis databinding TRIAGE CVE-2024-2700 quarkus-core: Leak of local configuration properties into Quarkus applications

An update for Red Hat Build of Apache Camel 4.4 for Quarkus 3.8 update is now available (RHBQ 3.8.4.SP1).The purpose of this text-only errata is to inform you about the enhancements that improve your developer experience and ensure the security and stability of your products: CVE-2024-29025 netty-codec-http: Allocation of Resources Without Limits or Throttling CVE-2024-28752 cxf-core: Apache CXF SSRF Vulnerability using the Aegis databinding CVE-2024-22371 camel-core: Exposure of sensitive data by crafting a malicious EventFactory

An update for Red Hat Build of Apache Camel 4.4 for Quarkus 3.8 update is now available (RHBQ 3.8.4.SP2).The purpose of this text-only errata is to inform you about the enhancements that improve your developer experience and ensure the security and stability of your products: CVE-2022-34169 xalan: OpenJDK: integer truncation issue in Xalan-J (JAXP, 8285407)

The vulnerability in Quarkus REST arises when REST endpoints are implemented without a CDI scope and utilize field injection for request parameters. In such cases, a single instance of the endpoint class is shared across multiple concurrent requests, leading to the potential exchange of request parameters between these requests. This means that data such as HTTP headers, URI templates, cookies, and form values from one request can inadvertently be accessed by another, posing significant security risks.Affected applications should ensure proper scoping with @RequestScoped or avoid field injection for request parameters. The issue is fixed in version 3.18.2.

Important: Red Hat build of Quarkus 3.15.4 release and security update

Important: Red Hat build of Quarkus 3.20.1 release

Quarkus is vulnerable to an authorization bypass issue where semicolons (matrix parameters) in HTTP requests can be used to bypass path-based HTTP security policies. The vulnerability arises because Quarkus's security layer performs authorization checks on the raw URL path which preserves matrix parameters.

When a path such as "/api/admin" is protected by a path-based HTTP security policy, sending a request like "/api/admin;anything" can bypass this policy while still routing to the protected endpoint unless the policy is configured to protect the exact "/api/admin;anything" path.

Important: Red Hat build of Quarkus 2.13.8 release and security update

Important: Red Hat build of Quarkus security update