Where
-Infinity
0

Vendor Risk Score

See how quarkus compares to other vendors in security performance

View Risk Score →
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

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

1 / 3
Source: GitHub
First published (updated )
Severity
7.5
XEE
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

A flaw was found in FasterXML Jackson Databind which did not have entity expansion secured properly making it vulnerable to XML external entity (XXE). This vulnerability is similar to CVE-2019-10172. The primary threat from this flaw is data integrity.

1 / 2
Source: Red Hat
First published (updated )
Severity
8.8
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

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.

1 / 5
Source: MITRE
First published (updated )
Severity
8.1
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

1 / 3
First published (updated )
Severity
7.5
Input Validation
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

In the Jakarta Expression Language implementation 3.0.3 and earlier, a bug in the ELParserTokenManager enables invalid EL expressions to be evaluated as if they were valid.

1 / 2
First published (updated )
Severity
5.3
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

A flaw was found in RESTEasy in all versions of RESTEasy up to 4.6.0.Final. The endpoint class and method names are returned as part of the exception response when RESTEasy cannot convert one of the request URI path or query values to the matching JAX-RS resource method's parameter value. The highest threat from this vulnerability is to data confidentiality.

1 / 3
First published (updated )
Severity
7.5
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

A vulnerability was found in Quarkus. The Quarkus CORS filter allows simple GET and POST requests with an invalid Origin to proceed. Simple GET or POST requests made with XMLHttpRequest have no event listeners registered on the object returned by the XMLHttpRequest upload property, and have no ReadableStream object used in the request.

1 / 2
First published (updated )
Severity
4

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.

First published (updated )
Severity
9.8
AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

pgjdbc is the offical PostgreSQL JDBC Driver. A security hole was found in the jdbc driver for postgresql database while doing security research. The system using the postgresql library will be attacked when attacker control the jdbc url or properties. pgjdbc instantiates plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties. However, the driver did not verify if the class implements the expected interface before instantiating the class. This can lead to code execution loaded via arbitrary classes. Users using plugins are advised to upgrade. There are no known workarounds for this issue.

1 / 3
First published (updated )
Severity
6.5
SQL Injection
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

A flaw was found in Hibernate ORM in versions before 5.3.18, 5.4.18 and 5.5.0.Beta1. A SQL injection in the implementation of the JPA Criteria API can permit unsanitized literals when a literal is used in the SELECT or GROUP BY parts of the query. This flaw could allow an attacker to access unauthorized information or possibly conduct further attacks.

1 / 3
First published (updated )
Severity
5.9
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Apache Kafka could allow a remote attacker to obtain sensitive information, caused by a timing attack flaw due to the use of "Arrays.equals" to validate a password or key. By utilizing brute-force attack techniques, an attacker could exploit this vulnerability to obtain credentials information, and use this information to launch further attacks against the affected system.

1 / 3
Source: IBM
First published (updated )
Severity
3.3
Infoleak
AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

A flaw was found in Guava that creates temporary directories with default permissions similar to /tmp. This issue may allow local users access, possibly permitting information exposure.

1 / 5
First published (updated )
Severity
7.4
SQL Injection
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

A flaw was found in Hibernate ORM of all versions before and including 5.4.23.Final. A SQL injection in the implementation of the JPA Criteria API can permit unsanitized literals when a literal is used in the SQL comments of the query. This flaw could allow an attacker to retrieve/update/delete unauthorized information if only the attacker already has the table names and column names.

1 / 3
Source: Red Hat
First published (updated )
Severity
1

Description: Security checks for standard security annotations on the RESTEasy Reactive inherited endpoints are not performed eagerly, but are performed by standard security interceptors instead. Apart from functional differences it also means security checks for inherited endpoints are not performed eagerly.

As long as you know any POST / PUT / PATCH request paths, you can send unauthenticated HTTP requests with illegal payload and see response status. When you get 500 ... this way you detect endpoints (though there can be other reasons...) Can you significantly raise processing time? You can send valid content which means requests will be stopped after JAX-RS filters. Resulting impact depends on what they do in JAX-RS filters.

Affected Quarkus version: 999-SNAPSHOT, 3.8.x. 3.7.x, 3.2.x, 2.13.x

Mitigations with affected version: Don't use inherited endpoints (or use HTTP permissions, depending on the scenario)

References: https://github.com/quarkusio/quarkus/pull/38832 https://github.com/quarkusio/quarkus/issues/38754

First published (updated )
Severity
5.3
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

A flaw was found in RESTEasy client in all versions of RESTEasy up to 4.5.6.Final. It may allow client users to obtain the server's potentially sensitive information in headers, cookies and body when the server got WebApplicationException from the RESTEasy client call.

1 / 4
Source: Red Hat
First published (updated )
Severity
5.3
Input Validation
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

A flaw was found in Hibernate Validator version 6.1.2.Final. A bug in the message interpolation processor enables invalid EL expressions to be evaluated as if they were valid. This flaw allows attackers to bypass input sanitation (escaping, stripping) controls that developers may have put in place when handling user-controlled data in error messages.

1 / 2
First published (updated )
Severity
6.1
XSS, CSRF
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

A flaw was found in Quarkus. If the Quarkus Form Authentication session cookie Path attribute is set to /, then a cross-site attack may be initiated, which might lead to information disclosure.

1 / 2
First published (updated )
Severity
6.6
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H

An unspecified vulnerability in Oracle MySQL Connectors related to the Connector/J component could allow an authenticated attacker to take control of the system.

1 / 3
Source: IBM
First published (updated )
Severity
7.9
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H

Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Connectors. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all MySQL Connectors accessible data and unauthorized ability to cause a hang or frequently repeatable crash.

External Reference:

https://www.oracle.com/security-alerts/cpuoct2021.html

1 / 3
Source: Red Hat
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

A flaw was found In FasterXML jackson-databind. This issue could allow an attacker to benefit from resource exhaustion due to the lack of a check in BeanDeserializer.deserializeFromArray to prevent the use of deeply nested arrays. An application is only vulnerable with certain customized choices for deserialization.

1 / 4
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

A flaw was found in FasterXML jackson-databind. This issue could allow an attacker to benefit from resource exhaustion when the UNWRAPSINGLEVALUEARRAYS feature is enabled due to unchecked primitive value deserializers to avoid deep wrapper array nesting.

1 / 5
First published (updated )
Severity
5.3
Input Validation
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Apache HttpClient versions prior to version 4.5.13 and 5.0.3 can misinterpret malformed authority component in request URIs passed to the library as java.net.URI object and pick the wrong target host for request execution.

First published (updated )
Severity
6.5
XSS
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

Impact If a Content-Length header is present in the original HTTP/2 request, the field is not validated by Http2MultiplexHandler as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (HttpRequest, HttpContent, etc.) via Http2StreamFrameToHttpObjectCodec and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.

In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked.

An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. A sample attack request looks like:

POST / HTTP/2 :authority:: externaldomain.com Content-Length: 4

asdfGET /evilRedirect HTTP/1.1 Host: internaldomain.com

Users are only affected if all of this is true: HTTP2MultiplexCodec or Http2FrameCodec is used Http2StreamFrameToHttpObjectCodec is used to convert to HTTP/1.1 objects These HTTP/1.1 objects are forwarded to another remote peer.

Patches This has been patched in 4.1.60.Final

Workarounds The user can do the validation by themselves by implementing a custom ChannelInboundHandler that is put in the ChannelPipeline behind Http2StreamFrameToHttpObjectCodec.

References Related change to workaround the problem: https://github.com/Netflix/zuul/pull/980

1 / 5
First published (updated )
Severity
6.2
Infoleak
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Impact

When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled.

The CVSSv3.1 score of this vulnerability is calculated to be a 6.2/10

Vulnerability Details

On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems.

The method File.createTempFile on unix-like systems creates a random file, but, by default will create this file with the permissions -rw-r--r--. Thus, if sensitive information is written to this file, other local users can read this information.

This is the case in netty's AbstractDiskHttpData is vulnerable.

https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101

AbstractDiskHttpData is used as a part of the DefaultHttpDataFactory class which is used by HttpPostRequestDecoder / HttpPostMultiPartRequestDecoder.

You may be affected by this vulnerability your project contains the following code patterns:

java channelPipeline.addLast(new HttpPostRequestDecoder(...));

java channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...));

Patches

This has been patched in version 4.1.59.Final.

Workarounds

Specify your own java.io.tmpdir when you start the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.

References

- CWE-378: Creation of Temporary File With Insecure Permissions - CWE-379: Creation of Temporary File in Directory with Insecure Permissions

Similar Vulnerabilities

Similar, but not the same.

- JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - Google Guava - https://github.com/google/guava/issues/4011 - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824

For more information If you have any questions or comments about this advisory: Open an issue in netty Email us here

Original Report

Hi Netty Security Team, I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: https://lgtm.com/query/7723301787255288599/ Netty contains three local information disclosure vulnerabilities, so far as I can tell. One is here, where the private key for the certificate is written to a temporary file. https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 One is here, where the certificate is written to a temporary file. https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 All of these vulnerabilities exist because File.createTempFile(String, String) will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: -rw-r--r--, thus, any other local user on that system can read the contents of that file. Impacted OS: - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. Mitigation. Moving to the Files API instead will fix this vulnerability. https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- This API will explicitly set the posix file permissions to something safe, by default. I recently disclosed a similar vulnerability in JUnit 4: https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. https://github.com/netty/netty/security/advisories This vulnerability disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. Cheers, Jonathan Leitschuh

1 / 5
First published (updated )
Severity
5.9
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

Impact The content-length header is not correctly validated if the request only use a single Http2HeaderFrame with the endStream set to to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1

This is a followup of https://github.com/netty/netty/security/advisories/GHSA-wm47-8v5p-wjpj which did miss to fix this one case.

Patches This was fixed as part of 4.1.61.Final

Workarounds Validation can be done by the user before proxy the request by validating the header.

1 / 5
First published (updated )
Severity
6.5
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

Impact

Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better fail fast as these are not allowed by the spec and could lead to HTTP request smuggling.

Failing to do the validation might cause netty to "sanitize" header names before it forward these to another remote system when used as proxy. This remote system can't see the invalid usage anymore and so not do the validation itself.

1 / 5
First published (updated )
Severity
9.8
Code Injection
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

A vulnerability was found in quarkus. This issue occurs in Dev UI Config Editor, which is vulnerable to drive-by localhost attacks leading to remote code execution.

1 / 3
First published (updated )
Severity
5.3
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

A flaw was found in Wildfly Elytron in versions prior to 1.10.14.Final, prior to 1.15.5.Final and prior to 1.16.1.Final where ScramServer may be susceptible to Timing Attack if enabled. The highest threat of this vulnerability is confidentiality.

1 / 3
First published (updated )
Severity
7.5
Input Validation
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Crafted input may cause the jsoup HTML and XML parser to get stuck, timeout, or throw unchecked exceptions

1 / 4
Source: Microsoft
First published (updated )
Severity
5.4
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

A flaw was found in Keycloak’s Admin Console, where it is missing HTTP security headers in HTTP responses. This issue is not a direct vulnerability and may not lead to a security issue, but increases the chances of allowing attackers to exploit other security flaws. Examples of these possible exploits are servers being prone to clickjacking, channel downgrade attacks, and other similar client-based attack vectors.

1 / 3
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203