### 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 [[email protected]](mailto:[email protected]). Please do not create a public GitHub issue.
### 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 [[email protected]](mailto:[email protected]). Please do not create a public GitHub issue.
### 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 [[email protected]](mailto:[email protected]). Please do not create a public GitHub issue.
### 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 [[email protected]](mailto:[email protected]). Please do not create a public GitHub issue.
Update com.cedarpolicy:cedar-java to 2.3.6; com.cedarpolicy:cedar-java to 3.4.1; com.cedarpolicy:cedar-java to 4.9.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanCedarJava has type confusion vulnerability affects com.cedarpolicy:cedar-java (maven), com.cedarpolicy:cedar-java (maven), com.cedarpolicy:cedar-java (maven). Severity is high. ### 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 [[email protected]](mailto:[email protected]). Please do not create a public GitHub issue.
AI coding agents often install or upgrade packages automatically in maven. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| com.cedarpolicy:cedar-javamaven | <2.3.6 | 2.3.6 |
| com.cedarpolicy:cedar-javamaven | >=3.1.2,<3.4.1 | 3.4.1 |
| com.cedarpolicy:cedar-javamaven | >=4.0.0,<4.9.0 | 4.9.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate com.cedarpolicy:cedar-java to 2.3.6; com.cedarpolicy:cedar-java to 3.4.1; com.cedarpolicy:cedar-java to 4.9.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanCedarJava has type confusion vulnerability affects com.cedarpolicy:cedar-java (maven), com.cedarpolicy:cedar-java (maven), com.cedarpolicy:cedar-java (maven). Severity is high. ### 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 [[email protected]](mailto:[email protected]). Please do not create a public GitHub issue.
AI coding agents often install or upgrade packages automatically in maven. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| com.cedarpolicy:cedar-javamaven | <2.3.6 | 2.3.6 |
| com.cedarpolicy:cedar-javamaven | >=3.1.2,<3.4.1 | 3.4.1 |
| com.cedarpolicy:cedar-javamaven | >=4.0.0,<4.9.0 | 4.9.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard