CedarJava CVE-2026-55773

The integrating application must call toCedarExpr() on Cedar Value types and concatenate the result into Cedar policy source text at runtime, with at least one of the interpolated values coming from attacker-controlled input (e.g., HTTP request fields, tenant metadata). Exploitation is limited by this non-default integration pattern: applications that load static .cedar files, use Cedar's typed entity/value APIs without string assembly, or that already sanitize/allowlist user input do not reach the vulnerable code path. The attacker also needs whatever access the surrounding application requires to influence the injected field (the CVSS PR:L implies some authenticated context), and the injectable payload must syntactically fit the surrounding permit/forbid/when clause.

The vendor-assigned CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, 8.8) overstates real-world risk for most consumers: exploitability is fully gated on the integrator pattern of feeding user-controlled values into toCedarExpr() to build policy text at runtime, which is an unusual integration choice rather than the library's default usage. There is no EPSS score, no CISA KEV listing, and no POC referenced, so this falls under 'no public exploit identified at time of analysis.' The primary impact is integrity of authorization decisions (C:H/A:H are debatable since injected Cedar typically toggles permit/forbid rather than disclosing data or causing DoS); teams using CedarJava only for static or schema-validated policies are not realistically exposed, while teams that compose policies from request-time user input should treat this as high priority.

An application uses CedarJava to dynamically assemble a permit policy by interpolating a user-supplied attribute (for example, a tenant-supplied display name) into a when-clause via toCedarExpr(). The attacker submits a value such as foo" || true || "foo, which, after unescaped serialization, terminates the original string literal and appends '|| true' to the condition, causing the permit clause to evaluate true unconditionally and granting access the policy was meant to deny. No public POC is referenced, but the technique mirrors classic string-context code injection.