Omnigent: six advisories hit agent policies, sandbox and multi-user auth

01What happened

Omnigent published six security advisories on October 13 and 14, 2026, five of them alongside version 0.18.0. The reporters named in them are Rea1mindxRing, TahirMars, sfwani, manus-pi, manus-use and fg0x0, and maintainer TomeHirata published each record. None of the six carries a CVE id.

02How it works

Three of the flaws are incomplete input lists, the weakness class CWE-184: Omnigent's GitHub and working-directory policies misread git global options and some shell syntax, so commands that should have needed approval ran unchecked. A fourth ran uploaded Python source tools during tool-schema discovery, which happens before the isolation that covers later tool calls. The session import path did not confirm that the chosen host belonged to the importing user. On Linux, the bubblewrap sandbox gave helper executors host temporary files, so code inside the sandbox could take over the launcher.

03Who is affected

Multi-user Omnigent servers carry the most risk, because four of the six advisories need an authenticated account on the server. Affected version ranges differ per advisory and are listed below. The header authentication flaw is the exception: no account is needed, and it reaches deployments below 0.7.0 that answer requests without a proxy that strips the X-Forwarded-Email header.

04What to do

Upgrade to Omnigent 0.18.0 or later and restart agent and runner processes, and do not rely on the changelog to flag the need, because the 0.18.0 release notes do not mention these fixes. Review imported sessions for host associations that do not belong to their owner and stop any session that should not reach its host. Operators who pin OMNIGENT_AUTH_PROVIDER=header should confirm their proxy strips client-supplied copies of the identity header.

Questions people ask

Which Omnigent version fixes these advisories?

Omnigent 0.18.0, released October 13, 2026, patches five of the six advisories, and the sixth, the X-Forwarded-Email impersonation flaw, was already fixed in 0.7.0. Upgrading to 0.18.0 or later therefore covers all six. The advisories also ask operators to restart agent and runner processes after upgrading, because processes already running keep the old behaviour.

Am I affected if I run Omnigent for just myself?

Single-user and local Omnigent installs face less exposure, because four of the six advisories require an authenticated account on a multi-user server. The sandbox launcher flaw still applies wherever agent code runs under bubblewrap on Linux. Omnigent also keeps source-tool support for trusted, operator-authored bundles on local or single-user servers after the fix.

Do these Omnigent flaws have CVE ids?

No CVE id is assigned to any of the six advisories, and each GitHub record states that no known CVE exists, so tracking them needs the GHSA ids instead. Omnigent does carry CVEs for earlier flaws, including CVE-2026-62677 for an agent bundle path traversal fixed in 0.3.0, so the gap is specific to the October batch.

How do I check whether another user reached my Omnigent host?

Review imported sessions on the server for host associations that do not belong to the owning user, which the critical advisory recommends directly, and stop any session that should not reach its host. Host identifiers can be visible to anyone able to view a shared session. Omnigent 0.18.0 verifies host ownership when an imported session is saved or replaced.

Sources 9 links, all fetched

1. 1github.comSession Import Advisory
2. 2github.comHeader Auth Advisory
3. 3github.comSandbox Launcher GHSA
4. 4github.comSource Tools GHSA
5. 5github.comGit Policy Bypass GHSA
6. 6github.comShell Policy Bypass GHSA
7. 7github.comSub-Agent cwd GHSA
8. 8vulncheck.comCVE-2026-112015
9. 9github.comOmnigent 0.18.0 Release