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.
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
- Shared Agent Bundle Overwrite Leads to Authenticated Runner RCE (GHSA-jrrm-9hc7-2v3h) (omnigent-ai (GitHub Security Advisory))
Supporting sources
- fix(server): block shared-agent overwrite via bundle upload (#1418) (omnigent-ai/omnigent (GitHub, Pull Request #1418))
- block shared-agent overwrite via bundle upload (25a22dc9e6da4648d23749f0a589e47e6aed991b) (omnigent-ai/omnigent (GitHub, commit))
- Omnigent v0.3.0 (omnigent-ai/omnigent (GitHub, release))
- GHSA-jrrm-9hc7-2v3h (GitHub Advisory Database)
- 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
- verified
The Omnigent project's own security advisory and its independently rendered mirror in the GitHub Advisory Database, both retrieved directly, state CVE-2026-62674, CVSS 3.1 base score 9.0, Critical, CWE-94, the affected and patched version ranges, and the vulnerable mechanism consistently.
You Could Edit Your Session. That Did Not Mean You Could Rewrite Everyone's Agent. - verified
The merged fix pull request and its commit, both retrieved directly, describe the same fact pattern as the advisory and state the fix as an explicit guard rejecting a bundle upload when the target agent's session_id is none, mirroring a check an existing sibling endpoint already carried.
You Could Edit Your Session. That Did Not Mean You Could Rewrite Everyone's Agent.
