Omnigent Shared Agent Hijack via Broken Object-Level Authorization Leading to MCP Command Injection
First seen Aug 22, 2026 · Updated Aug 22, 2026 · CVSS 9
A flaw in the Omnigent AI agent framework allows a user with only edit access to their own session to tamper with a shared or template agent that isn't properly bound to that session, injecting a malicious stdio MCP server configuration. When other sessions later reuse the poisoned shared agent, attacker-controlled commands execute with the full permissions of the Omnigent runner process, exposing files, credentials, and internal services. This is a critical broken-authorization vulnerability with a CVSS score of 9.0, fixed in version 0.3.0.
Technical Analysis
The vulnerability lies in the PUT /sessions/{session_id}/agent endpoint in omnigent/server/routes/sessions.py, which validates LEVEL_EDIT permission on the session but fails to verify that the target agent is actually exclusively bound to that session (i.e., agent.session_id being None indicates a shared/template agent rather than a session-private one). This missing object-level ownership check lets an authenticated but otherwise low-privileged user modify a shared agent bundle used across multiple sessions, adding an attacker-controlled stdio MCP server entry. When any other session subsequently loads that shared agent, omnigent/tools/mcp.py launches the attacker-defined command as a local process inheriting the Omnigent runner's permissions, crossing session/tenant boundaries into arbitrary code execution. The attacker gains a persistent, laterally-propagating foothold that can exfiltrate credentials, workspace files, and reach internal services reachable from the runner host.
Affected Systems
Omnigent; protocols: MCP
Detection Signatures
- PUT requests to /sessions/{session_id}/agent targeting an agent with session_id=None or a template/shared agent ID not owned by the requester
- Unexpected additions of new stdio MCP server entries in shared agent configuration/version history
- Runner process spawning unfamiliar child commands/binaries not part of the baseline MCP server allowlist
- Audit logs showing edit-level users modifying agents referenced by sessions other than their own
- Outbound network or file-system activity from the Omnigent runner process shortly after a shared agent config change
Remediation Steps
- 1
Upgrade Omnigent
Update to Omnigent 0.3.0 or later, which fixes the authorization check on the agent-update endpoint.
- 2
Enforce object-level authorization
Ensure agent-modification endpoints verify true ownership/binding (session_id match) rather than relying solely on generic session-level permission checks.
- 3
Restrict shared/template agent mutability
Treat shared or template agents as immutable or require elevated admin privileges to modify their MCP server configuration.
- 4
Sandbox and allowlist MCP servers
Run stdio MCP servers in restricted sandboxes with least-privilege permissions and maintain an allowlist of approved commands/binaries.
- 5
Audit and monitor agent configuration changes
Log and alert on any modification to shared agent bundles, especially additions of new MCP server definitions, and review historical changes for signs of compromise.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.