CVE-2024-1726

Overview

Quarkus is a Kubernetes-native Java framework optimized for cloud-native applications, containers, and serverless workloads. It is designed around fast startup, low memory use, build-time processing, and developer-friendly integrations across REST, HTTP, security, data, messaging, and observability extensions.

A Denial of Service (DoS) vulnerability (CVE-2024-1726) has been identified in Quarkus RESTEasy Reactive, which allows attackers to force the server to perform request processing before the authorization check rejects the request. Security annotations such as @RolesAllowed and @DenyAll declared on inherited JAX-RS endpoint methods were not enforced by the eager pre-processing security path, so the check ran only after the request body had already been deserialized and handled. An attacker who knows a protected POST, PUT, or PATCH path can therefore drive repeated pre-rejection work and degrade the availability of the application.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource unavailable for the purpose it was designed.

This issue affects multiple versions of Quarkus RESTEasy Reactive in the io.quarkus:quarkus-resteasy-reactive package.

Details

Module Info

• Product: Quarkus
• Affected packages: io.quarkus:quarkus-resteasy-reactive
• Affected versions: <3.2.11.Final, >=3.3.0.CR1 <3.7.4, 3.8.0.CR1
• GitHub repository: https://github.com/quarkusio/quarkus
• Published packages: https://central.sonatype.com/artifact/io.quarkus/quarkus-resteasy-reactive
• Package manager: Maven
• Fixed in:
  • NES for Quarkus 2.16.12-quarkus-2.16.14
  • OSS Quarkus 3.2.11.Final, 3.7.4 and 3.8.0

Vulnerability Info

This Medium-severity vulnerability is found in the io.quarkus:quarkus-resteasy-reactive package in multiple versions of Quarkus. RESTEasy Reactive enforces JAX-RS security annotations eagerly through EagerSecurityHandler, which runs before the request body is deserialized. To find the security check for the current endpoint, the handler builds a MethodDescription keyed on the resource class name:

MethodDescription methodDescription = new MethodDescription(lazyMethod.getResourceClass().getName(),
        lazyMethod.getName(), MethodDescription.typesAsStrings(lazyMethod.getParameterTypes()));

For an inherited endpoint method, where the endpoint is declared on a superclass or interface and the security annotation is registered against that declaring type, the handler keyed its lookup on the concrete subclass name instead of the declaring class. The lookup returned no match, so the eager check silently did nothing and enforcement fell back to the lazy security path that runs only after the request body has been deserialized and processed. An unauthenticated attacker who guesses such a path can send requests that the server fully processes before ultimately rejecting them, consuming processing resources on work that should have been refused up front and enabling a denial of service. Confidentiality and integrity are not affected because the lazy check still denies the request.

Mitigation

Only recent versions of Quarkus are community-supported. The affected 2.16.x line is End-of-Life and will not receive public updates to address this issue.

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.