CVE-2026-87744
Patch Available.
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Quarkus is a Kubernetes-native Java framework optimized for cloud-native applications, containers, and serverless workloads. It builds on standard libraries (Jakarta EE, Eclipse Vert.x, Hibernate, Netty) and compiles to both JVM and GraalVM native images for fast startup and low memory use. The REST Data Panache extensions generate CRUD REST endpoints at build time from a Panache entity or repository resource interface, including the security annotations declared on that interface.
An authorization bypass vulnerability (CVE-2026-87744) has been identified in the Quarkus REST Data Panache code generator, which allows unauthenticated attackers to call generated endpoints that the developer restricted to specific roles. When an operation is customized with @MethodProperties and does not re-declare rolesAllowed, the class-level role requirement is silently dropped, which can lead to unauthorized information disclosure or data modification.
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 all versions of Quarkus that include the io.quarkus:quarkus-hibernate-orm-rest-data-panache package.
Details
Module Info
- Product: Quarkus
- Affected packages:
io.quarkus:quarkus-hibernate-orm-rest-data-panache - Affected versions: >=0.0.0
- GitHub repository: https://github.com/quarkusio/quarkus
- Published packages: https://central.sonatype.com/artifact/io.quarkus/quarkus-hibernate-orm-rest-data-panache
- Package manager: Maven
- Fixed in:
- NES for Quarkus v2.16.18, v3.20.11
Vulnerability Info
This Critical-severity vulnerability is found in the io.quarkus:quarkus-hibernate-orm-rest-data-panache package in all versions of Quarkus. A REST Data Panache resource can restrict every generated operation with @ResourceProperties(rolesAllowed = ...), and an individual operation can be customized with @MethodProperties, for example to change its path:
@ResourceProperties(path = "pieces", rolesAllowed = "admin")
public interface PiecesResource extends PanacheEntityResource<Piece, Long> {
@MethodProperties(path = "custom")
boolean delete(Long id);
}
At build time, the shared REST Data Panache deployment code decides which roles to place on each generated method by calling ResourceProperties.getRolesAllowed:
public String[] getRolesAllowed(String methodName) {
if (methodProperties.containsKey(methodName)) {
return methodProperties.get(methodName).getRolesAllowed();
}
return rolesAllowed;
}
As soon as an operation has a @MethodProperties annotation, this method returns that annotation's rolesAllowed value, even when the developer never set it. The attribute defaults to an empty array, so the resource-level roles are never consulted for that operation. StandardMethodImplementor.addSecurityAnnotations only adds @RolesAllowed to the generated method when the returned array is non-empty, so the customized endpoint is generated with no role check at all. In the example above, GET /pieces still requires the admin role, but an anonymous DELETE /pieces/custom/1 request is accepted and deletes the row. Any operation customized this way (list, count, get, add, update or delete) becomes reachable without authentication, while the uncustomized operations of the same resource stay protected, which makes the gap easy to miss in review.
Mitigation
Only recent versions of Quarkus are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue. Quarkus LTS releases are maintained for 12 months from release; see the project's LTS release policy.
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.