<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T07:18:01.698659+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-62674</id>
    <title>CVE-2026-62674 — Omnigent: Shared Agent Bundle Overwrite Leads to Authenticated Runner RCE</title>
    <updated>2026-09-28T07:18:02.788486+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> omnigent-ai omnigent</p>
<p>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.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-62674"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-jrrm-9hc7-2v3h</id>
    <title>GHSA-jrrm-9hc7-2v3h — Omnigent: Shared Agent Bundle Overwrite Leads to Authenticated Runner RCE</title>
    <updated>2026-09-28T07:18:02.788640+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: omnigent</p>
<p>### Summary</p>
<p>An authenticated user with edit access to their own session can overwrite a shared/template agent by uploading a full agent bundle through `PUT /sessions/{session_id}/agent`.</p>
<p>Shared/template agents are shown as not MCP-editable, but this upload path still accepts a replacement bundle. By adding a `stdio` MCP server to the shared agent, the attacker can cause future runner sessions using that shared agent to start an attacker-controlled command.</p>
<p>### Details</p>
<p>The vulnerable endpoint is the full agent bundle upload route: [`PUT /sessions/{session_id}/agent`](https://github.com/omnigent-ai/omnigent/blob/10f5ae3110e162f96fb99bb6662c581abdc56cd6/omnigent/server/routes/sessions.py#L18979-L19077) 
This route checks whether the caller can edit the session: [`LEVEL_EDIT` session permission check](https://github.com/omnigent-ai/omnigent/blob/10f5ae3110e162f96fb99bb6662c581abdc56cd6/omnigent/server/routes/sessions.py#L19003-L19025)
But it does not check whether the bound agent is a shared/template agent.
Shared/template agents have:
```python
agent.session_id is None
```
The API already exposes that these agents are not meant to be MCP-editable: [`mcp_servers_editable` is false for shared/template agents](https://github.com/omnigent-ai/omnigent/blob/10f5ae3110e162f96fb99bb6662c581abdc56cd6/omnigent/server/routes/sessions.py#L18842-L18857)
The direct MCP edit endpoint correctly blocks shared/template agents: [`session_mcp_servers.py` shared-agent guard](https://github.com/…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-jrrm-9hc7-2v3h"/>
  </entry>
</feed>
