CVE-2023-6267 is a High severity (CVSS 8.6) flaw in Quarkus. When a REST resource is secured with annotations, the JSON request body is deserialized before the security check runs. Red Hat Important advisories deliver Red Hat build of Quarkus 2.13.9.SP1 and 3.2.9.SP1, so update and review your endpoint security.
What's affected
The NVD record lists the Quarkus project, with version 2.13.9 as a named example, and does not publish a clean upstream range. Red Hat's advisories give concrete fixed builds.
- Fixed (Red Hat build of Quarkus): 2.13.9.SP1 and 3.2.9.SP1, delivered by Red Hat advisories RHSA-2024:0494 and RHSA-2024:0495, both issued 25 January 2024 and rated Important.
- Affected configuration: REST resources secured with annotation based security. The description states that configuration based security does not show the behaviour.
- Severity: NVD scores it 8.6 High. Red Hat rates the updates Important.
- Upstream community versions: the record does not give them. Check the Quarkus release notes and the project's security advisories for the fixed community release you should use.
I did not confirm which advisory maps to which stream, so read both if you use Red Hat's build.
How to check if you're exposed
Start by finding which Quarkus version each service uses.
mvn dependency:tree | grep quarkus
./gradlew dependencies | grep quarkus
Next, look at how endpoints are secured. Search your code for annotations such as @RolesAllowed or @Authenticated on REST resource methods that accept a request body. Those are the configuration that matters here. Endpoints protected only through configuration properties, such as HTTP permission rules, are described as not affected.
A dependency scan tells you which services include a vulnerable Quarkus build. Reachability analysis helps with the second question, which services have an annotated resource that takes a JSON body. The free in-browser dependency scan is a quick first pass.
What to do now
- Upgrade Quarkus to the fixed release for your stream. For Red Hat's build, apply 2.13.9.SP1 or 3.2.9.SP1 as appropriate.
- Where you cannot upgrade yet, consider moving sensitive endpoints to configuration based security, which the description says is not affected.
- Review request body types for annotated endpoints and confirm they do not enable risky polymorphic deserialization.
- Add authentication at the gateway or filter level so unauthenticated callers never reach the application at all.
- Rebuild and redeploy services and container images. A dependency bump in a pom file does nothing until it ships.
Why it matters
The weakness is CWE-755, improper handling of exceptional conditions. The description is about the order of operations. A secured endpoint should refuse an unauthorized caller before it does any work on the request. Here the framework parsed and deserialized the JSON body first and applied the annotation based check after.
That order matters because deserialization is not free of risk. It uses CPU and memory, and depending on what the application's data types allow, it can trigger code in constructors and setters. Even without a deeper chain, an unauthenticated caller could make the service do work that it would otherwise refuse. The record's kev flag is false. The sources I read do not describe exploitation in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does configuration based security have the same problem?
The description says it does not. The ordering problem is specific to annotation based security.
Which versions fix it for Red Hat customers?
Red Hat build of Quarkus 2.13.9.SP1 and 3.2.9.SP1, in advisories RHSA-2024:0494 and RHSA-2024:0495.
Sources
Last reviewed: 19 October 2026.
