Omnigent is an open-source AI agent framework and meta-harness for orchestrating coding agents. Prior to 0.3.0, PUT /sessions/{session_id}/agent checks LEVEL_EDIT permission for a session but does not reject a bound shared or template agent whose agent.session_id is None. An authenticated user with edit access to a session can replace that shared agent bundle through omnigent/server/routes/sessions.py, add a stdio MCP server, and cause later sessions that use the shared agent to launch an attacker-controlled command through omnigent/tools/mcp.py. The command executes with the Omnigent runner process permissions and can expose files, credentials, workspace data, internal services, and runner availability. This issue is fixed in version 0.3.0.
Security readout for executives and security teams
Plain-English summary
An authenticated Omnigent user with session-edit rights can overwrite a shared agent definition. When another session later uses that agent, the runner may execute an attacker-controlled command with its own privileges, threatening credentials, source code, internal services, and availability. Omnigent versions before 0.3.0 are affected; 0.3.0 fixes the issue.
Executive priority
Treat this as an urgent upgrade for affected, multi-user, or credential-bearing Omnigent runners. The vulnerability can convert limited authenticated editing access into runner-level code execution and affect users beyond the attacker’s session. Prioritize internet-accessible and shared environments first, then investigate unexpected agent changes and rotate exposed secrets when evidence warrants it.
Technical view
The session agent update route validates session-level edit permission but, before 0.3.0, fails to reject shared or template agents whose session_id is null. This authorization-boundary flaw permits bundle replacement and insertion of a stdio MCP server. A later session can trigger command execution under the Omnigent runner process identity. CVSS 3.1 is 9.0, with CWE-94.
Likely exposure
Exposure requires Omnigent earlier than 0.3.0, an authenticated account with edit access to a session, and use of a bound shared or template agent. Risk is greatest where runners hold valuable credentials, access sensitive workspaces or internal services, or serve multiple users. The supplied evidence does not establish how commonly affected deployments expose this route.
Exploitation context
The attack requires authentication, low complexity, session-edit privileges, and a later user interaction that invokes the modified shared agent. The resulting command inherits runner permissions and crosses session boundaries. The bundle marks KEV false, and no supplied source reports active exploitation; real-world exploitation status therefore remains unconfirmed.
Researcher notes
The central defect is an ownership check gap: session authorization is validated, but the target agent may be globally shared because its session_id is null. Impact is deferred until a later session launches the altered MCP configuration. The supplied fix references are pull request 1418 and commit 25a22dc9e6da4648d23749f0a589e47e6aed991b; no exploit evidence is supplied.
Mitigation direction
Upgrade Omnigent to version 0.3.0 or later.
Check the vendor advisory and release notes before applying the update.
Restrict session-edit access to trusted users until every runner is upgraded.
Review shared and template agent bundles for unauthorized changes.
Rotate runner-accessible credentials if compromise indicators are found.
Validation and detection
Inventory Omnigent server and runner versions; flag every installation earlier than 0.3.0.
Identify sessions bound to shared or template agents.
Audit agent-update activity involving PUT /sessions/{session_id}/agent.
Inspect shared bundles for unexpected stdio MCP server definitions.
Review runner execution and access records for unexplained processes or credential use.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-94: Code execution behavior lookup
Code execution and unsafe deserialization weaknesses often justify reviewing execution behavior and process telemetry. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references code or command execution, so execution technique review may help defensive triage. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
5Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-94 · source CWE mapping
Improper Control of Generation of Code
Improper Control of Generation of Code represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.