CVE-2023-5675

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.

An Authorization Bypass vulnerability (CVE-2023-5675) has been identified in Quarkus RESTEasy Reactive, which allows attackers to reach JAX-RS endpoints that the application intended to protect. When an application enables application-wide default authorization through quarkus.security.jaxrs.deny-unannotated-endpoints or quarkus.security.jaxrs.default-roles-allowed, those default security checks are not applied to endpoint methods that are inherited from an abstract superclass or interface, or that are synthesized by an extension's annotation processor, leaving those endpoints unintentionally exposed.

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 in the io.quarkus:quarkus-resteasy-reactive-common and io.quarkus:quarkus-resteasy-reactive-common-deployment packages.

Details

Module Info

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

Vulnerability Info

This Medium-severity vulnerability is found in the io.quarkus:quarkus-resteasy-reactive-common and io.quarkus:quarkus-resteasy-reactive-common-deployment packages in multiple versions of Quarkus. The concrete flaw lives in the deployment (build-time) module, which drives the security processing for the paired runtime extension coordinate.

At build time, the setUpDenyAllJaxRs build step in ResteasyReactiveCommonProcessor implements the application-wide JAX-RS default security options. For each scanned resource class that carries no security annotation, it enumerates the class's endpoint methods and registers them for a default denyAll() or rolesAllowed(...) check by producing an AdditionalSecuredMethodsBuildItem:

for (ClassInfo classInfo : scannedResources.values()) {
    if (!hasSecurityAnnotation(classInfo)) {
        Collection<MethodInfo> methods = collectClassEndpoints(classInfo, httpAnnotationToMethod, ...);
        additionalSecuredClasses.produce(new AdditionalSecuredMethodsBuildItem(methods));
    }
}

The collectClassEndpoints(...) helper only returns endpoint methods whose declaring class is the scanned resource class itself:

if (method.declaringClass().equals(classInfo)) {
    collectEndpoints(classInfo, currentClassInfo, method, ...);
}

Because of this equality check, HTTP method handlers that are inherited from an abstract superclass or interface, or that are added or rewritten by a Quarkus extension's annotation processor, are never collected and therefore never registered as secured methods. The deny-unannotated-endpoints and default-roles-allowed defaults are silently not enforced on those endpoints, so they remain reachable over the network without the intended authorization. Endpoints whose HTTP methods are declared directly on the resource class are unaffected.

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.