Addressing CVE-2023-4853 in Quarkus

The CVE-2023-4853 vulnerability in question impacts the Quarkus framework’s HTTP Security Policy mechanism. This policy provides path-based access control to various endpoints within an application, enabling developers to enforce security constraints based on URL path configurations. However, a critical security flaw was identified in how the HTTP Security Policy normalized request paths containing multiple adjacent forward-slash characters.

Issue Summary

Quarkus provides several mechanisms to secure HTTP endpoints, ranging from programmatic security annotations to configuration-driven HTTP security policies in application.properties. The path-based security policy mechanism failed to properly normalize request paths containing duplicate or redundant forward slashes before applying policy rules.

For example, given the following configuration in application.properties:

quarkus.http.auth.permission.role-admin.paths=/secured/*
quarkus.http.auth.permission.role-admin.policy=roles
quarkus.http.auth.permission.role-admin.roles=admin

In affected releases, an unauthenticated or unauthorized user could bypass the policy matching rule by inserting extra forward slashes in front of the target endpoint path (for instance, requesting //secured/admin-dashboard instead of /secured/admin-dashboard):

Besides properties-based configuration, please note that this security issue also affected legacy or web-descriptor secured HTTP resources via web.xml patterns. For example:

<security-constraint>
        <web-resource-collection>
            <web-resource-name>example</web-resource-name>
            <url-pattern>/secured/*</url-pattern>
            <url-pattern>/openapi/*</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>

Versions Affected

This issue affects several legacy release branches of Quarkus, including versions 2.16, 3.2, and 3.3.

Resolution and Upgrading to Quarkus 3.x

The immediate patch fixes were made available in Quarkus 2.16.11.Final, 3.2.6.Final, and 3.3.3. If you are using the Red Hat build of Quarkus, refer to 2.13.18.SP2 as documented in https://access.redhat.com/security/cve/cve-2023-4853.

However, modern Java applications should standardise on the latest stable Quarkus 3.x releases (such as Quarkus 3.8 LTS or Quarkus 3.15+ LTS), which incorporate full path normalization fixes alongside performance enhancements and updated Jakarta EE standards.

To update your project, update your Maven pom.xml properties or Gradle build scripts to target a secure Quarkus 3.x platform version:

<!-- Recommended: Upgrade to current Quarkus 3.x LTS release -->
<quarkus.platform.version>3.15.0</quarkus.platform.version>

Alternatively, if you are maintaining a legacy maintenance pipeline:

<quarkus.platform.version>2.16.11.Final</quarkus.platform.version>

Migrating to Jakarta EE and RESTEasy Reactive / Quarkus REST

When upgrading your application from older Quarkus versions to Quarkus 3.x, you must perform the mandatory migration from Java EE (javax.*) to Jakarta EE (jakarta.*) packages. This includes updating annotations for JAX-RS REST endpoints, CDI, and Security annotations.

1. Package Namespace Changes

Replace all legacy javax.* imports with their modern jakarta.* equivalents in your security and REST controllers:

// OLD (Quarkus 2.x - Java EE)
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import javax.annotation.security.RolesAllowed;

// NEW (Quarkus 3.x - Jakarta EE)
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;
import jakarta.annotation.security.RolesAllowed;

2. Updating Reactive Programming Components (Mutiny & RESTEasy Reactive)

In Quarkus 3.x, reactive web services rely on modern RESTEasy Reactive (now standardized as Quarkus REST) and SmallRye Mutiny. Non-blocking reactive endpoints seamlessly integrate security checks with Mutiny streams (Uni and Multi).

Here is an example of a secure non-blocking endpoint in Quarkus 3.x using SmallRye Mutiny and Jakarta EE security annotations:

package com.mastertheboss.jaxrs;

import io.smallrye.mutiny.Uni;
import jakarta.annotation.security.RolesAllowed;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;

@Path("/secured")
@ApplicationScoped
public class SecuredReactiveResource {

    @GET
    @Path("/data")
    @RolesAllowed("admin")
    @Produces(MediaType.APPLICATION_JSON)
    public Uni<SecuredData> getSecuredData() {
        return Uni.createFrom().item(() -> new SecuredData("Sensitive Payload"))
                .onItem().invoke(data -> System.out.println("Access granted to admin"));
    }
}

In Quarkus 3.x, both declarative method-level security (@RolesAllowed, @Authenticated) and global HTTP path security policies share the same underlying Vert.x routing engine, guaranteeing uniform normalization against double-slash bypass vectors across both imperative and Mutiny reactive pipelines.

Workaround & Mitigation

If you cannot immediately upgrade your Quarkus runtime version, you can mitigate the vulnerability by configuring a fallback global 'deny' policy in application.properties. This ensures that any unnormalized or unexpected path that fails to match designated rules defaults to blocked access:

# Define HTTP permissions
quarkus.http.auth.permission.deny-all.paths=/*
quarkus.http.auth.permission.deny-all.policy=deny

quarkus.http.auth.permission.secured.paths=/secured/*
quarkus.http.auth.permission.secured.policy=authenticated

Conclusion

Addressing CVE-2023-4853 is essential to preventing path traversal and security policy bypasses in Quarkus applications. Upgrading to modern Quarkus 3.x releases resolves this vulnerability while providing access to Java 17/21 capabilities, Jakarta EE standards, and non-blocking reactive features powered by SmallRye Mutiny and RESTEasy Reactive. Implementing these upgrades ensures your microservices remain secure, maintainable, and aligned with current enterprise Java best practices.

Frequently Asked Questions (FAQs)