GHSA-c33x-vcv4-vg3g: Missing Slot Identifier Validation in Cedar Policy Language JSON Template Parser Causes Panic and Authorization Divergence

The Cedar Policy Language is an open-source authorization policy language and evaluation engine used to express and enforce fine-grained permissions across applications. Cedar supports two primary policy serialization formats: the human-readable native Cedar syntax and a structured JSON representation known as the Entity Syntax Tree (EST). Both formats support policy templates, which allow administrators to author parameterized policies containing placeholder slots (?principal and ?resource) that are dynamically linked to concrete entity identifiers at runtime.

Within the cedar-policy-core crate, the EST module (cedar-policy-core/src/est/scope_constraints.rs) is responsible for deserializing JSON-formatted scope constraints and converting them into internal Abstract Syntax Tree (ast) representations. In Cedar's semantic model, the principal scope may only reference the ?principal slot, and the resource scope may only reference the ?resource slot. While the native syntax parser strictly enforces this invariant during lexical and syntactic analysis, the JSON EST parser failed to validate slot names when processing is <EntityType> in <Slot> scope constraints.

This flaw is classified under CWE-20 (Improper Input Validation). By omitting verification of the slot field inside the PrincipalOrResourceInConstraint::Slot variant, the parser silently coerced any arbitrary or mismatched slot identifier into the default slot corresponding to the enclosing scope position. Consequently, the internal AST representation diverged from the authored JSON specification.

This discrepancy exposes applications ingesting JSON policy templates to two distinct failure modes. When a single slot is mismatched, attempting to link the template triggers an internal invariant violation, resulting in an unrecoverable Rust runtime panic and denial of service. When both the principal and resource slots are inverted, template linking succeeds but binds the target entities to the wrong scope positions, causing decision divergence that can lead to unauthorized access or unintended denials.

The root cause of GHSA-c33x-vcv4-vg3g resides in the TryFrom trait implementations that convert est::PrincipalConstraint and est::ResourceConstraint into ast::PrincipalOrResourceConstraint within cedar-policy-core/src/est/scope_constraints.rs. In Cedar's JSON format, a scope constraint using the is operator combined with an in clause is represented by the PrincipalOrResourceIsConstraint struct, which contains an entity_type string and an optional in_entity field of type PrincipalOrResourceInConstraint.

When a policy template defines a slot inside the in clause, the JSON object takes the form {"slot": "?principal"} or {"slot": "?resource"}, which deserializes via Serde into the PrincipalOrResourceInConstraint::Slot { slot: ast::SlotId } enum variant. At this stage of deserialization, Serde validates that the string is a valid SlotId (?principal or ?resource), but it does not possess the contextual awareness to verify whether that specific SlotId is legal within the surrounding PrincipalConstraint or ResourceConstraint.

Contextual validation is deferred to the TryFrom conversion functions. However, when handling the Is constraint variant, the conversion logic matched the in_entity field using a Rust struct wildcard pattern: Some(PrincipalOrResourceInConstraint::Slot { .. }). By using the { .. } wildcard, the compiler ignored the inner slot field entirely. The conversion immediately invoked ast::PrincipalOrResourceConstraint::is_entity_type_in_slot(Arc::new(entity_type)), which implicitly constructs an AST node bound to SlotId::principal() when called from the principal conversion path, or SlotId::resource() when called from the resource conversion path.

Because the AST construction succeeded without raising an InvalidSlotName error, the resulting ast::Template contained internal state contradictions. Specifically, the high-level template metadata or calling application expected the slot identifiers declared in the JSON source, whereas the underlying scope constraint AST nodes were hardcoded to positional defaults. This violation of internal invariants directly enables the downstream linking panic and evaluation divergence.

The vulnerability was remediated in Pull Request #2351 via commit a4adfaaa300cc925c644e4a0d7b1a3469bafbfd5. The patch modifies cedar-policy-core/src/est/scope_constraints.rs across both impl TryFrom<PrincipalConstraint> for ast::PrincipalOrResourceConstraint and impl TryFrom<ResourceConstraint> for ast::PrincipalOrResourceConstraint.

In the unpatched code, both implementations ignored the slot variable using { .. } and wrapped the entire match expression in an unconditional Ok(...) constructor:

// Unpatched implementation in cedar-policy-core/src/est/scope_constraints.rs
PrincipalConstraint::Is(PrincipalOrResourceIsConstraint {
    entity_type,
    in_entity,
}) => {
    ast::EntityType::from_normalized_str(entity_type.as_str())
        .map_err(Self::Error::InvalidEntityType)
        .and_then(|entity_type| {
            Ok(match in_entity {
                None => ast::PrincipalOrResourceConstraint::is_entity_type(Arc::new(
                    entity_type,
                )),
                Some(PrincipalOrResourceInConstraint::Entity { entity }) => {
                    ast::PrincipalOrResourceConstraint::is_entity_type_in(
                        Arc::new(entity_type),
                        Arc::new(entity.into_euid(&|| {
                            JsonDeserializationErrorContext::EntityUid
                        })?),
                    )
                }
                // VULNERABILITY: Wildcard pattern `{ .. }` discards the `slot` value.
                // Assumes the slot is valid for this position without verification.
                Some(PrincipalOrResourceInConstraint::Slot { .. }) => {
                    ast::PrincipalOrResourceConstraint::is_entity_type_in_slot(
                        Arc::new(entity_type),
                    )
                }
            })
        })
}

The patched implementation destructures the slot field explicitly (Slot { slot }) and compares it against the expected positional ast::SlotId. If the identifier does not match ast::SlotId::principal() within a PrincipalConstraint (or ast::SlotId::resource() within a ResourceConstraint), the conversion halts and returns Err(Self::Error::InvalidSlotName):

// Patched implementation in cedar-policy-core/src/est/scope_constraints.rs
PrincipalConstraint::Is(PrincipalOrResourceIsConstraint {
    entity_type,
    in_entity,
}) => ast::EntityType::from_normalized_str(entity_type.as_str())
    .map_err(Self::Error::InvalidEntityType)
    .and_then(|entity_type| match in_entity {
        None => Ok(ast::PrincipalOrResourceConstraint::is_entity_type(
            Arc::new(entity_type),
        )),
        Some(PrincipalOrResourceInConstraint::Entity { entity }) => {
            Ok(ast::PrincipalOrResourceConstraint::is_entity_type_in(
                Arc::new(entity_type),
                Arc::new(
                    entity.into_euid(&|| JsonDeserializationErrorContext::EntityUid)?,
                ),
            ))
        }
        // FIX: Bind `slot` and explicitly validate it against `SlotId::principal()`.
        Some(PrincipalOrResourceInConstraint::Slot { slot }) => {
            if slot == ast::SlotId::principal() {
                Ok(ast::PrincipalOrResourceConstraint::is_entity_type_in_slot(
                    Arc::new(entity_type),
                ))
            } else {
                Err(Self::Error::InvalidSlotName)
            }
        }
    }),

The exact same structural change was applied to TryFrom<ResourceConstraint>, verifying if slot == ast::SlotId::resource(). The fix is complete and brings the Is constraint conversion into parity with other constraint types in scope_constraints.rs (such as Eq and In constraints without entity type restrictions), which already performed explicit slot identifier comparisons during EST-to-AST translation.

Triggering this issue requires an application or service to accept Cedar policy templates in the JSON (EST) format, instantiate templates containing is ... in scope constraints with slot placeholders, and subsequently link and evaluate those templates. Depending on how the JSON template is constructed, two distinct operational failures occur.

Mode 1: Single-Slot Mismatch (Runtime Panic)

If a policy author or attacker supplies a JSON template where only one scope uses a mismatched slot—for example, setting the principal constraint's in clause to {"slot": "?resource"} while leaving the resource scope unconstrained—the EST parser silently converts the principal slot into ?principal inside the scope constraint AST. When the host application attempts to link the template by passing a concrete entity UID for ?resource (matching the JSON definition), Cedar rejects the operation with a linking error because the AST does not register ?resource as an active slot. However, if the caller links the template by supplying a value for ?principal, the initial slot check passes, but downstream linking routines encounter an internal invariant mismatch, causing the Rust thread to panic and terminating the host process if panics are not caught across FFI or thread boundaries.

Mode 2: Dual-Slot Inversion (Authorization Bypass)

A more severe logical failure occurs when both principal and resource constraints define is ... in clauses with inverted slot identifiers. Consider the following JSON policy template designed to forbid members of a specific project (?resource mistakenly used in principal) from accessing classified documents (?principal mistakenly used in resource):

{
  "effect": "forbid",
  "principal": {
    "op": "is",
    "entity_type": "User",
    "in": { "slot": "?resource" }
  },
  "action": { "op": "All" },
  "resource": {
    "op": "is",
    "entity_type": "Doc",
    "in": { "slot": "?principal" }
  },
  "conditions": []
}

When this template is parsed, the principal scope constraint silently binds to ?principal and the resource scope constraint silently binds to ?resource. Because both ?principal and ?resource are present in the resulting template, linking succeeds without errors or panics when the application provides values for both slots:

• ?principal = Classification::"topsecret"
• ?resource = Project::"alpha"

Instead of generating the intended policy forbid(principal is User in Project::"alpha", action, resource is Doc in Classification::"topsecret");, the engine evaluates forbid(principal is User in Classification::"topsecret", action, resource is Doc in Project::"alpha");. When a user in Project::"alpha" requests access to a Doc in Classification::"topsecret", the forbid rule fails to match because the user is not a member of Classification::"topsecret". Consequently, the explicit deny rule is bypassed.

The overall severity of GHSA-c33x-vcv4-vg3g is rated Low with a CVSS v4.0 score of 2.1 (CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:L/SC:L/SI:L/SA:L). The score reflects the high privileges required (PR:H) and specific attack requirements (AT:P), as policy template creation is typically restricted to administrative users or control-plane services rather than unauthenticated end users.

In environments where untrusted or semi-trusted tenants are permitted to submit custom JSON policy templates (such as multi-tenant policy-as-a-service platforms or delegated administration portals), the availability impact (VA:L) is realized directly on the vulnerable authorization service. Triggering the single-slot linking invariant violation causes an immediate Rust panic!. In standard Rust binaries or WebAssembly modules (@cedar-policy/cedar-wasm), an unhandled panic aborts execution or traps the WASM instance, resulting in an application-level denial of service.

The subsequent system impacts (SC:L/SI:L/SA:L) stem from authorization decision divergence in downstream applications relying on Cedar to enforce access control boundaries. If a permit template experiences dual-slot inversion, principals may be granted access to unintended resources. Conversely, if a forbid template experiences dual-slot inversion, restrictive guardrails fail to activate, allowing unauthorized operations to proceed.

To remediate this vulnerability, development teams must upgrade their Cedar dependencies to versions that enforce strict slot identifier validation during JSON EST deserialization. The patches are available in the following releases:

• Rust (cedar-policy on Crates.io): Upgrade to version 4.11.1 (for the 4.x release branch) or 3.4.3 (for the 3.x release branch).
• JavaScript / WebAssembly (@cedar-policy/cedar-wasm on npm): Upgrade to version 4.11.1 (for the 4.x release branch) or 3.4.3 (for the 3.x release branch).

> [!NOTE] > Upgrading to the patched versions introduces stricter validation that will reject previously accepted malformed JSON policy templates with an InvalidSlotName deserialization error. Organizations should audit stored JSON templates prior to upgrading to ensure existing policies do not break at runtime.

For environments where immediate dependency upgrades are not feasible, administrators can mitigate the issue through static auditing and pre-validation of JSON policy templates before passing them to the Cedar engine. Specifically, inspect all JSON policy definitions where principal.op == "is" or resource.op == "is" and verify the inner in.slot property:

1. Ensure that any principal object containing "op": "is" and an "in" slot specifies "slot": "?principal".
2. Ensure that any resource object containing "op": "is" and an "in" slot specifies "slot": "?resource".
3. Reject or correct any JSON policy template where ?resource appears inside the principal constraint or ?principal appears inside the resource constraint.

Alternatively, converting policy ingestion pipelines to parse templates using the native Cedar policy syntax rather than the JSON EST format avoids the vulnerable code path entirely, as the native parser was not affected by this flaw.