What is the CVSS score of CVE-2026-55772?

CVE-2026-55772 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.5%.

Which versions of CedarJava are affected by CVE-2026-55772?

CedarJava contains a type confusion vulnerability affecting authorization controls that allows authenticated attackers to bypass access restrictions when authorization objects are built from…. A patch is available.

How to fix or mitigate CVE-2026-55772?

Within 24 hours: Identify all services using CedarJava versions prior to 2.3.6, 3.4.1, or 4.9 and document whether they construct CedarMap objects from headers, metadata, or other untrusted sources. Within 7 days: Implement input validation to reject CedarMap objects containing reserved keys '__entity' or '__extn' from untrusted sources; restrict authenticated user privileges on authorization-critical operations. Within 30 days: Establish continuous monitoring for vendor patches; develop and test deployment procedures for patched versions once released by the vendor.

CedarJava CVE-2026-55772

HIGH

Access of Resource Using Incompatible Type (Type Confusion) (CWE-843)

2026-06-19 https://github.com/cedar-policy/cedar-java

GHSA-93g4-m6xv-cmvr

Java Information Disclosure Memory Corruption

8.8

CVSS 3.1 · Vendor: https://github.com/cedar-policy/cedar-java

Severity by source

Vendor (https://github.com/cedar-policy/cedar-java) PRIMARY

8.8 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

6.8 MEDIUM

Network-reachable via integrating service (AV:N); AC:H because exploitation requires a specific integration pattern (user-controlled map keys) and a policy referencing it; PR:L for authenticated submitter; no direct availability impact.

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/cedar-policy/cedar-java).

CVSS VectorVendor: https://github.com/cedar-policy/cedar-java

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jun 19, 2026 - 15:51 vuln.today

Analysis Generated

Jun 19, 2026 - 15:51 vuln.today

DescriptionCVE.org

Summary

CedarJava is an open source Java implementation of the Cedar policy language, used for fine-grained authorization decisions. Under certain circumstances, improper input handling could allow type confusion across the Java-Rust FFI boundary.

Impact

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.

Impacted versions:

< 4.9

Patches

Addressed in CedarJava version 2.3.6, 3.4.1, and 4.9 and above. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

Enable schema-based request validation to catch type mismatches. Validate that user-controlled data does not contain reserved keys (__entity or __extn) before building CedarMap objects.

References

If you have any questions or comments about this advisory, we ask that you contact us directly via email to [cedar-policy-security@lists.cncf.io](mailto:cedar-policy-security@lists.cncf.io). Please do not create a public GitHub issue.

Articles & Coverage 1

News 3 New Java Vulnerabilities - 3 High Severity, No POC Available Jun 19, 2026

AnalysisAI

Type confusion in CedarJava versions prior to 2.3.6, 3.4.1, and 4.9 allows authenticated remote attackers to manipulate authorization decisions by injecting reserved JSON keys (__entity or __extn) into CedarMap objects built from attacker-controlled input. When an integrating service constructs a CedarMap from caller-supplied data such as headers, metadata, or resource tags, the Rust cedar-policy evaluator can be tricked into interpreting a record as an entity reference, undermining fine-grained authorization. No public exploit identified at time of analysis, but the CVSS 8.8 rating reflects high impact on confidentiality, integrity, and availability of authorization outcomes.

Technical ContextAI

CedarJava is the Java binding for the Cedar policy language (originally developed by AWS, now a CNCF project), used by services to express and evaluate fine-grained authorization policies. The Java layer marshals authorization requests to the underlying Rust cedar-policy evaluator over an FFI boundary using a JSON protocol that reserves magic single-key shapes - {"__entity": ...} for entity references and {"__extn": ...} for extension values - to distinguish typed values from plain records. The root cause maps to CWE-843 (Access of Resource Using Incompatible Type, i.e., type confusion): the CedarMap serialization performs no filtering of these reserved keys, so a record containing them is indistinguishable from an entity reference once decoded on the Rust side. The affected package is pkg:maven/com.cedarpolicy:cedar-java across the 2.x, 3.x, and 4.x release lines.

RemediationAI

Vendor-released patch: upgrade to CedarJava 2.3.6, 3.4.1, or 4.9.0 (or later) depending on which release line you run, per https://github.com/cedar-policy/cedar-java/security/advisories/GHSA-93g4-m6xv-cmvr. If immediate upgrade is not possible, two compensating controls are available: enable Cedar's schema-based request validation so that records flagged with __entity/__extn keys fail type checking before reaching the evaluator (trade-off: requires that you actually have a Cedar schema defined and that all entity types are declared, which not every deployment does), and add an explicit reject-list at the integration layer that strips or rejects any caller-supplied key beginning with __ before the data is fed into a CedarMap (trade-off: must be applied everywhere user data enters policy evaluation, easy to miss in tag/metadata pipelines). Any forked or vendored copies of cedar-java must independently pick up the fix.