Authority over a reference treated as authority over the shared resource it resolves to
A permission scoped to one actor's own container, a session among them, is accepted as authority to mutate a shared or template object the container merely points to. Once mutated, the change persists to every other actor that later resolves the same reference.
Description
Many systems let a narrow, individually owned container reference a broader, shared object rather than embedding a private copy of it: a session pointing at a template agent, a workspace pointing at a shared configuration, a project pointing at a common policy. An authorization check built for that container, does this caller have permission over this session, is correct and sufficient as long as the object the container points to is genuinely exclusive to it. The weakness appears when the container can instead reference a shared object, and nothing on the mutating path independently checks which kind of object the reference actually resolves to before accepting the caller's change. The check that would catch it is not absent from the system, only absent from this one path: a sibling operation elsewhere in the same system may already refuse the identical mutation once it recognises a shared or built in object, which is what makes the gap a specific, identifiable omission rather than a general absence of access control. What sets this apart from an ordinary authorization bypass is persistence: the actor who exploits the gap does not need to be present, or even the same actor, when the consequence lands. Every later user or session that legitimately resolves the same reference inherits whatever the exploiting request left behind, with no delegation step, no spawning relationship and no further decision by anyone required.
The authority gap
The authority presented is authority over the container, a session or its equivalent. The authority required is authority over the specific object the container resolves to, which may be shared, and the two are silently equated.
Failure conditions
- A container an actor is individually authorized to edit can reference either a private object or a shared, built in or template object.
- The mutating endpoint checks the caller's permission on the container but not whether the object the container resolves to is exclusive to it or shared.
- The mutated object persists and is later read or executed by other actors or sessions that resolve the same reference, with no further authorization check at that later point.
Consequences shown by the evidence
- A permission scoped to one session, workspace or project silently became persistent authority over an object every other session, workspace or project also depended on.
- A capability planted in a shared object, a configured tool server among them, executed with the mutating platform's own privileges in every later session that loaded it, with no relationship between the exploiting session and the sessions that inherited the consequence.
Detection signals
- An update endpoint checks permission on a container id but never inspects whether the object it is about to overwrite is flagged as shared, built in or template.
- A sibling endpoint in the same system already carries the missing check, and the fix for an incident is to add the same guard to the path that lacked it.
- A single exercised grant changes behaviour for users or sessions other than the one that exercised it.
Known examples
- Omnigent's PUT /sessions/{session_id}/agent endpoint checked LEVEL_EDIT permission on the session but not whether the bound agent was a shared or template agent, agent.session_id is none, letting an authenticated user overwrite a shared agent bundle with a malicious stdio MCP server that later, unrelated sessions using that agent would execute with the runner process's own privileges. The direct MCP edit endpoint in the same system already carried the missing check. CVE-2026-62674, GHSA-jrrm-9hc7-2v3h, patched in Omnigent 0.3.0.
Recorded instances
- AEV-2026-0015 Omnigent shared agent bundle overwrite let a session edit reach future session RCE (CVE-2026-62674) AESS 8.8 high Confirmed
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
Codex CLI 0.151.0, restored permission profiles and authorization bound Guardian classifications
OpenAI
Requirement A cached classification's authorization state is a specific, narrow counter pair, not a general session validity flag
Codex CLI's fix binds a cached classification to the exact, narrow authorization state it was computed against, and forces the classification to be rechecked rather than trusted once that state changes. The corrective Omnigent's own fix reaches for is the same shape one layer earlier: check the exact object a session permission actually resolves to, rather than trusting that clearing the session level check once is enough for whatever object the session currently references.
- Missing requirement
Grantex and the Delegated Agent Authorization Protocol (DAAP)
Sanjeev Kumar, Grantex
Requirement Revoking a root grant atomically marks every descendant grant revoked in one transaction, traced through parent_grant_id
DAAP's cascade revocation atomically marks every descendant grant revoked when a root grant is revoked, but that mechanism, and the specification's own subset scoped delegation model around it, addresses a delegation chain between agents. Nothing in the fetched specification establishes a comparable check for the distinct failure Omnigent's vulnerability demonstrates: whether the single resource an already granted, non delegated scope resolves to is exclusive to the grantee or shared with other principals entirely outside any delegation chain.