Intelligence
AEV-2026-0015

Omnigent shared agent bundle overwrite let a session edit reach future session RCE (CVE-2026-62674)

Omnigent's session agent bundle upload endpoint checked session edit permission but not whether the bound agent was a shared or template agent, letting an authenticated user overwrite a shared agent's bundle with a malicious stdio MCP server that later, unrelated sessions using that agent would execute with the runner process's own privileges. Disclosed by the Omnigent project, patched in 0.3.0, with no evidence of exploitation before the fix.

AESS 8.8 highConfirmedStatus: resolvedEvent: 29 June 2026Execution AuthorityDelegated Authority

Affected

Organisation
Omnigent project
Product
Omnigent
Component
PUT /sessions/{session_id}/agent, the full agent bundle upload endpoint
Versions
Versions before 0.3.0; fixed in 0.3.0
Configurations
A shared or template agent, agent.session_id is none, reachable through more than one trusted session or user; A shared agent configured, or configurable, with a stdio Model Context Protocol server

Execution authority facts

Fields the evidence does not establish are shown as unknown rather than guessed.

Intended task
An authenticated user editing the agent bundle bound to their own session
Agent
An authenticated Omnigent user or client calling the session agent bundle upload endpoint
Delegating actor
Whatever mechanism granted the caller LEVEL_EDIT permission on the named session
Action
Overwrote a shared or template agent's own bundle, not a private copy scoped to the caller's session
Target resource
A shared or template agent object other sessions and users depended on
Environment
The Omnigent server and runner infrastructure hosting the session
Credentials used
unknown
Privileges available
The runner process's own privileges on the host, once a later session loaded the poisoned agent and started its configured stdio MCP server
Authority presented
LEVEL_EDIT permission on one named session
Authority required
Authority over the specific agent object the session's edit actually resolved to, including whether that object was shared
Applicable policy
The session level permission check the endpoint enforced
Approval mechanism
none
Required approver
unknown
Independent approval
no
Action binding
The session permission check was never bound to whether the target agent was session exclusive or shared
Sequence context
The consequence did not require the exploiting caller's presence: a later, unrelated session loading the same shared agent triggered execution

Impact

Consequence
Remote code execution on shared runner infrastructure with the runner process's own privileges, in every later session that loaded the poisoned shared agent
Reach
organisational
Reversibility
unknown
Detectability
silent
Propagation
potential
Recovery
Fixed in 0.3.0 by adding an explicit guard rejecting bundle uploads that target a shared or template agent; no documented mechanism found for detecting or restoring a shared agent already overwritten before the fix

Evidence

Primary sources

Supporting sources

Reproduction status
Not reproduced by Moona Intelligence; the mechanism is corroborated across three independently retrieved project artifacts, the advisory, the pull request and the commit, each describing the same endpoint, the same agent.session_id check and the same fix, retrieved through automated page fetch and summarization rather than a raw source diff read line by line.
Evidence state
Confirmed

Known unknowns

  • Whether this was exploited against a real deployment before the fix.
  • What share of Omnigent deployments run multi tenant, with a shared agent reachable by more than one trusted operator.
  • Whether the project documents a way to detect or restore a shared agent already overwritten before the fix.

Limitations

  • This record's access to Omnigent's own repository and advisory came through automated retrieval and summarization rather than a direct, line level read of the vulnerable and patched source.
  • No independent CVE Program or National Vulnerability Database record was separately fetched; CVE and CVSS detail is taken from the GitHub Security Advisory and its GitHub Advisory Database mirror.

Claim provenance