CVE-2026-121837 in Quarkus
Summary
by MITRE • 11/06/2026
A flaw was found in the REST Data Panache component of Quarkus. When a security constraint is applied to an entity property using the @SecureField annotation on its getter method rather than the field itself, the generated REST resource fails to enforce this constraint for filtering and sorting operations. This allows an authenticated user to infer sensitive data values by observing which records match specific filter criteria or how they are ordered, even though the values are omitted from the final response.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/06/2026
The vulnerability identified in the Quarkus framework specifically affects the REST Data Panache component when developers utilize the @SecureField annotation incorrectly. In a secure implementation of this pattern, security constraints applied to entity properties must be attached directly to the field declaration within the Java class definition. However, when the annotation is mistakenly placed on the getter method instead of the underlying field, the framework's internal logic fails to recognize and enforce these restrictions during specific data manipulation operations. This misconfiguration creates a discrepancy between how data is retrieved for standard display purposes versus how it is processed for filtering and sorting queries. The core technical flaw lies in the query generation mechanism, which bypasses the security layer intended to mask or restrict access to sensitive fields when constructing database requests based on user-supplied filter criteria or sort orders.
The operational impact of this vulnerability centers on information disclosure through side-channel analysis rather than direct data exfiltration. Although the application correctly omits the values of secured fields from the final JSON response sent to the client, an authenticated attacker can exploit the filtering and sorting mechanisms to infer these hidden values. By submitting a series of requests with varying filter parameters that target specific potential values for the secure field, or by observing how records are ordered when sorted by that field, the attacker can deduce the actual data contained within those fields. This technique effectively turns the application's search functionality into an oracle, allowing the reconstruction of sensitive information such as personal identifiers, financial details, or internal status codes without ever receiving them in a readable format from the server response.
This vulnerability aligns with CWE-209, which describes the generation of error messages containing sensitive information that could aid attackers, although in this specific case it is more accurately categorized under CWE-613, Insufficient Session Expiration, or more precisely CWE-284, Improper Access Control, as it involves a failure to enforce security constraints. Furthermore, from an offensive perspective, this behavior facilitates data inference attacks that are consistent with the ATT&CK technique T1074, Data Staged, where attackers collect and stage sensitive information for later exfiltration by leveraging application logic flaws rather than exploiting buffer overflows or injection vulnerabilities directly. The attack vector requires authentication, placing it within the scope of authenticated user exploitation, which significantly raises the barrier to entry but also increases the potential impact since legitimate users often have access to broader datasets that can be systematically probed.
To mitigate this vulnerability, developers must ensure that all security annotations intended to restrict field-level access are applied directly to the entity fields themselves rather than their corresponding getter methods. This ensures that the Quarkus framework correctly intercepts and enforces these constraints across all data operations, including filtering and sorting queries generated by the REST Data Panache component. Additionally, organizations should implement comprehensive code review processes focused on security annotation placement within JPA entities and ORM mappings. Regular static analysis tools configured to detect misapplied annotations can help identify such issues before deployment. It is also advisable to conduct penetration testing that specifically targets data inference through query manipulation to verify the effectiveness of access controls in place, ensuring that sensitive fields remain truly obscured even when subjected to complex filtering or ordering operations by authenticated users.