Failed resource resolution inherits the trust of the apparent path

Description

This weakness sits at the moment a system tries to establish what a filesystem path, or another indirect reference, actually resolves to before deciding whether an action against it is in scope. Canonicalization, symlink resolution and similar checks exist precisely because an apparent, syntactic identity, the path or reference as written, is not reliable evidence of the effective identity an action will actually reach; something in the workspace can point outside it. The weakness appears when that resolution step fails, for any reason, and a downstream code path treats the failure as equivalent to a successful resolution back to the apparent, unverified identity, rather than as a rejection. It is distinct from an authentication failure converted into an accepted authority state (AEW-016): there the boundary is a credential check at an identity translation point, and the fallback fabricates a principal; here the boundary is a resource identity check on a filesystem or reference target, and the fallback trusts a syntactic value that was never actually verified. It is distinct from reachability substituting for authorization in the absence of any check (AEW-008): here a check exists, runs and fails, and the gap opens in what happens immediately after. It is distinct from an actor controlling whether its own control applies (AEW-004): the actor does not disable the check; it only needs to make the check's own resolution fail, which a symlink pointing at a nonexistent or unreadable target can do without touching the check's configuration at all. The failure to resolve need not be an exception a canonicalization function throws; a permission rule's own matching step not reaching a command's or a path's actual, resolved identity before comparing it against the rule's own written form is the same gap, evidenced by a second vendor below. The corrective, now evidenced by two independent vendors' own fixes, is the same shape the other fail open weaknesses in this registry already document: treat a resolution failure, or an inability to resolve at all, as untrusted and block the action, rather than proceeding on the last value that looked acceptable.

The authority gap

The authority required is authority over the action's effective target, the resource the reference actually resolves to. The authority presented, once resolution fails, is authority over the reference's apparent, syntactic target, a value the system was never able to verify was the same thing, and the two are treated as interchangeable.

Failure conditions

• A consequential action, such as a file write, is gated on first resolving a target reference, such as a path, to its effective identity.
• The resolution step can fail, for example because the reference is a symlink pointing at a target that does not exist or cannot be read.
• A downstream code path treats a resolution failure as though it had produced the reference's original, apparent, unresolved value, rather than rejecting the action.
• An actor able to construct the reference, such as an in workspace symlink, can choose a target designed to make resolution fail on demand.

Consequences shown by the evidence

• A write intended for an in workspace target instead reaching an external location a symlink pointed at, because a failed canonicalization was trusted rather than rejected.
• An enforcement mechanism itself, such as a sandbox helper binary, becoming reachable as a write target through the same fallback, letting a later action escape the control the first action should never have been able to reach.

Detection signals

• A path or reference resolution function's error or exception path returns the original input rather than propagating a failure.
• The fix for an incident adds an explicit rejection on resolution failure, where the prior code silently continued with an unresolved value.
• A symlink, alias or other indirection inside a nominally trusted scope can be constructed to point outside it.

Known examples

• Cursor's own advisory for CVE-2026-50549, published 5 June 2026, states that Cursor attempted to canonicalize a write target's path to confirm it remained inside the workspace, and that when canonicalization failed, affected versions fell back to the original path and wrote without approval. An agent could create an in workspace symlink pointing outside the workspace and deliberately cause canonicalization to fail, by making the target nonexistent or removing read permissions from it, so the write proceeded through the unverified, apparent path. Cato AI Labs' DuneSlide research, disclosed 1 July 2026, describes zero click prompt injection as one path for an agent to reach this mechanism, and both Cursor's own advisory and reporting on Cato's research describe the demonstrated impact as reaching overwriting the cursorsandbox helper itself, enabling later commands to run unsandboxed. Fixed in Cursor 3.0, which treats a canonicalization failure as untrusted and blocks the write rather than falling back to the original path.
• Claude Code v2.1.268, published 10 September 2026 at 20:30 UTC, adds a second, independent vendor's own instance at a different resource boundary, a permission rule's own matching step rather than a sandboxed write's canonicalization, and across two distinct targets rather than one. Anthropic's own release note, verified directly by this session against the GitHub release page (this session's own direct curl and git-protocol access to anthropics/claude-code returned a repository-scope denial rather than reaching the page, but this session's own automated page-fetch tool reached it through a separate path and returned matching text, corroborating the upstream evidence bundle this session was separately supplied), states that deny and ask permission rules on symlinked system directories, /etc, /tmp and /var on macOS and /bin on Linux, did not apply when a path was addressed by its already-resolved real location rather than the symlinked spelling a rule was written against, and that Bash commands separately ignored a deny rule written on that symlinked spelling; and that a Read or Edit deny rule did not apply when an env -C, eval or similar command the permission checker states it cannot analyze shared its line. Claude Code's own permissions documentation, already cited above, states an allow rule requires both a symlink path and its resolved target to match and a deny rule fires if either does; this fix closes a case that existing mechanism did not yet reach, where the specific direction of resolution a tool call used, symlinked or already-resolved, did not line up with the spelling a rule was written against. The unanalyzable-command case generalizes this weakness beyond a canonicalization function throwing an exception: the permission checker's own stated inability to resolve what a compound command actually targets was, before this fix, read as the rule simply not matching rather than as a reason to deny by default, the identical fail-open direction Cursor's own fix corrected for a filesystem path. This session's own connected read of AEW-005 above, which already documents Claude Code's own v2.1.251 fix for a symlink swapped inside the working directory after a permission check had already run, keeps that record distinct from this one: v2.1.251's own gap was a timing gap between a check and a later, moved target; this weakness's own gap, evidenced here, is a matching gap with no timing element, between a rule's written spelling and the spelling or analyzability a specific access actually presented.

Recorded instances

• AEV-2026-0024 Cursor sandbox escape via symlink and failed path canonicalization fallback (CVE-2026-50549) AESS 7.2 high Confirmed

Related Intelligence Records

The published Moona Intelligence Records whose evidence establishes this weakness.

• The Sandbox Asked the Agent Where the Boundary Should Be.
• Claude Code Just Automated the Decision to Ask You for Permission

Protocol evidence

Published authority architectures whose artifacts bear on the requirement this weakness names: which satisfy it, which expose a way past it, and which leave it unanswered.

• Supports requirement

  Agent Action Decision Protocol (AADP)

  Shamik Saha, individual submission to the IETF

  Requirement A Policy Decision Point owns authorization state and evidence; PEPs enforce it

  AADP's own Policy Decision Point and Policy Enforcement Point separation presumes the Policy Decision Point evaluates a request against the resource or command it will actually govern; a decision correctly made against an apparent, unresolved identity that later diverges from the effective one the Policy Enforcement Point acts on is not a supported decision at all, whatever the decision's own logic says, because it decided about the wrong object. Claude Code's own v2.1.268 fix is response side evidence for exactly that reading: a deny or ask rule, this weakness's own instance of a Policy Decision Point's stored permit, is confirmed by Anthropic's own release note to have not applied when a symlinked directory's already-resolved real location, rather than the spelling the rule was written against, was what a tool call actually addressed, and separately when a compound command the permission checker could not analyze stood between the rule and the target it named. Both are cases where the requirement AADP states in the abstract, that a permit binds to a specific action against a specific object, was not met at the resolution step itself, before any Policy Enforcement Point ran. Cursor's own CVE-2026-50549 fix, this weakness's first known example, supports the same requirement from a canonicalization failure rather than a rule-matching gap.

  View protocol evidence