CVE-2026-55773
HighCVSS 8.8Exploitation Probability (EPSS)
Low risk21th percentile - higher than 21% of all known CVEs
Summary
In CedarJava library versions prior to 2.3.6, 3.4.1, and 4.9.0, a vulnerability allows Cedar-expression injection due to improper input handling. The toCedarExpr() method does not escape special characters, enabling injection of arbitrary policy expressions.
Risk Assessment
The risk involves bypassing access controls by injecting expressions like || true, which can make a permit policy unconditional, or && false, which can disable a forbid policy.
Recommendation
Immediately update CedarJava to version 2.3.6, 3.4.1, or 4.9.0. If updating is not possible, avoid using toCedarExpr() with user-controlled input.
Other vulnerabilities in CedarJava
See all- CVE-2026-55771High
In CedarJava versions prior to 4.9.0, the EntityIdentifier.equals() method has inverted logic for null and self-reference checks, causing incorrect equality comparisons. This does not affect Cedar authorization decisions but may impact integrators performing their own entity identifier comparisons.
- CVE-2026-55772High
CedarJava prior to versions 2.3.6, 3.4.1 and 4.9.0 contains a vulnerability where 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 vulnerability has been fixed in versions 2.3.6, 3.4.1, and 4.9.
Original NVD description (English source)
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 Cedar-expression injection via unescaped toCedarExpr(). The toCedarExpr() method on Cedar Value types does not escape special characters (" or \) when converting values to Cedar source code. If an integrator uses toCedarExpr() to build policy text at runtime from user-controlled values, an actor could inject arbitrary Cedar expressions. For example, injecting || true into a permit ... when { ... } clause could make the permit unconditional, or injecting && false into a forbid clause could prevent the forbid from triggering. This issue requires the integrator to use toCedarExpr() to build policy text at runtime from user-controlled input. This vulnerability has been fixed in versions 2.3.6, 3.4.1, and 4.9.0.