CedarJava CVE-2026-55772

Exploitation requires a specific application pattern: the integrating service must construct a CedarMap whose KEYS are populated from attacker-controlled input (request headers, user-defined metadata, resource tags), AND a Cedar policy must reference the resulting map value inside a when or unless clause. The attacker must be able to reach the service's authorization-evaluating endpoint and supply at least the literal key string __entity or __extn with a crafted value. Limiting factors: services that only allow user-controlled VALUES (not keys), services that enforce a Cedar schema with declared entity types, and services that sanitize __-prefixed keys are not exploitable. The CVSS PR:L reflects that some authenticated request to the integrating service is typically needed to inject the malicious key.

The CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H vector (8.8) treats this as a network-accessible, low-complexity, low-privilege flaw with high CIA impact - but that scoring assumes the typical deployment in which CedarJava sits behind a service that exposes Cedar evaluation to remote callers. In practice exploitability is gated by two non-trivial preconditions stated explicitly in the advisory: (1) the integrating service must construct a CedarMap whose KEYS (not just values) come from untrusted input, and (2) a policy must reference that map's value in a when/unless clause. EPSS and KEV data are absent from the input, and no POC is referenced; this is consistent with a freshly disclosed advisory rather than active exploitation. The realistic risk is therefore high for services that surface user-controlled headers/metadata/tags directly into Cedar entities - likely a meaningful subset of authorization gateways - but low for services that strictly schema-validate their inputs before evaluation.

An attacker submits an HTTP request to a service that uses CedarJava for authorization, setting a custom header or resource tag whose key is literally __entity and whose value is a JSON object identifying a privileged principal or resource. The service serializes that user-controlled key/value pair into a CedarMap and includes it in the authorization request; the Rust evaluator decodes the record as an entity reference, and a policy clause like when { principal.tags.role == ... } evaluates against the attacker-chosen entity instead of the intended record value, granting unintended access.