CVE-2026-55772 in CedarJava
Summary
by MITRE • 07/13/2026
CedarJava is an open source Java implementation of the Cedar policy language, used for fine-grained authorization decisions. In versions prior to 2.3.6, 3.4.1 and 4.9.0, under certain circumstances, improper input handling could allow Record-to-Entity type confusion across the Java-Rust FFI boundary. CedarJava sends authorization requests to the Rust cedar-policy evaluator as JSON. The JSON protocol reserves magic single-key object shapes (__entity and __extn) for entity references and extension values. When serializing a CedarMap, there is no validation preventing these reserved keys from being used. If an integrating service builds a CedarMap from caller-supplied key/value data (such as request headers, user-defined metadata, or resource tags), an actor who controls those keys could cause the Rust evaluator to interpret a record as an entity reference. This issue requires the integrating service to build a CedarMap where the an actor controls the keys, and a policy must reference that value in a when/unless clause. This vulnerability has been fixed in versions 2.3.6, 3.4.1, and 4.9.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/13/2026
The cedarjava library represents a critical security vulnerability stemming from improper input validation within the Java-Rust foreign function interface boundary. This flaw manifests as a record-to-entity type confusion vulnerability that specifically affects versions prior to 2.3.6, 3.4.1, and 4.9.0 of the open source Java implementation. The vulnerability arises from the protocol's handling of JSON serialization where CedarJava communicates with the Rust cedar-policy evaluator through a structured format that reserves specific magic single-key objects designated as __entity and __extn for entity references and extension values respectively. When serializing CedarMap structures, the system fails to validate whether these reserved keys are being used, creating a potential attack vector that allows malicious actors to manipulate authorization decisions.
The technical exploitation of this vulnerability requires multiple coordinated conditions to be met within the integrating service architecture. An attacker must first control the keys used in building CedarMap structures from caller-supplied data sources such as request headers, user-defined metadata, or resource tags. This control enables the injection of reserved magic keys into the serialized JSON payload. The second condition involves policy construction where a policy must reference the manipulated value within when/unless clauses, effectively allowing the attacker to influence how the Rust evaluator interprets the data structure. This type confusion occurs specifically at the Java-Rust FFI boundary where the Rust evaluator incorrectly processes what should be a record value as an entity reference due to the presence of these reserved keys.
The operational impact of this vulnerability extends beyond simple authorization bypasses, potentially allowing attackers to escalate privileges or access unauthorized resources within systems relying on cedarjava for fine-grained authorization decisions. The flaw represents a classic type confusion attack pattern that can lead to arbitrary code execution or data exposure depending on how the authorization system is implemented. From a cybersecurity perspective, this vulnerability aligns with CWE-129 and CWE-704 categories related to improper input validation and incorrect type handling respectively. The attack vector maps to ATT&CK technique T1068 (Local Privilege Escalation) and T1531 (Account Access Removal) through the manipulation of authorization decisions. The vulnerability's remediation requires careful attention to input sanitization at the FFI boundary, ensuring that reserved keys cannot be injected through user-controlled data flows.
This security issue highlights the critical importance of proper validation when implementing cross-language communication boundaries in security-critical systems. The fix implemented in versions 2.3.6, 3.4.1, and 4.9.0 addresses the root cause by adding validation to prevent reserved keys from being used during CedarMap serialization, thereby eliminating the potential for type confusion attacks. Organizations deploying cedarjava should prioritize upgrading to these patched versions while implementing additional monitoring for unauthorized access attempts that might indicate exploitation attempts. The vulnerability serves as a reminder of the complexities involved in maintaining security boundaries across language interfaces and the necessity of comprehensive input validation even in well-established authorization frameworks.