Omnigent: guardrail bypass via fail-open shell parser

Upgrade to the latest release. The fix shipped in 0.3.0 (2026-06-27), and later releases close more gaps of the same kind.

1. Upgrade: pip install -U omnigent (at least 0.3.0; 0.9.0 or later also includes the wrapper hardening from #3559).
2. Do not treat the github and working_dir policies as your only boundary. Give the agent a GitHub token scoped to the repositories it may write to, turn on branch protection for branches it must not push to, and run it in a sandbox.
3. If you ran 0.1.0 through 0.2.0 on untrusted input (web pages, issues, files that could carry a prompt injection), check for pushes to unexpected repositories or branches and for git worktrees outside the allowed directories.

Omnigent runs coding agents such as Claude Code, Codex and Pi under policies. Two built-in policies gate shell commands: github enforces a repository and branch allowlist for git and gh writes, and working_dir keeps the agent inside its workspace (it gates cd, git -C and git worktree). Both use a shared parser, omnigent/policies/builtins/_shell.py, to find the real command inside a shell string. When the parser did not recognize how a gated command was written, it produced no operation. The policy then returned None, which means abstain, and abstain means ALLOW. So any gated command the parser missed ran without a check.

omnigent (PyPI) before 0.3.0: releases 0.1.0, 0.1.1 and 0.2.0 and their release candidates. Fixed in 0.3.0 (2026-06-27). One of the four bypass forms, a command hidden behind a lone background operator, was already closed in 0.2.0 by #168.

The threat is the agent itself: a misaligned model, or one steered by a prompt injection, that the operator meant to keep confined. CVSS 3.1 score 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N). Such an agent could:

• push code, and any secrets in it, to a repository outside write_repos, including one the attacker controls;
• push to a branch outside write_branches, such as a protected release branch;
• leave its workspace with git worktree or git -C despite working_dir confinement.

Four forms of the same gap were confirmed against the real policy code: a shell interpreter called with other flags bundled together with -c (only a bare -c was unwrapped); process wrappers that were not on the wrapper list (timeout, nice, setsid, stdbuf); a gated command inside a command substitution, which the parser skipped as a plain variable assignment; and a gated command after a lone background operator (fixed earlier in 0.2.0). A bare gated command was correctly denied, which shows the allowlist logic was right and the parser coverage was the problem. A working exploit is withheld.

Permalinks at 7ca0cca, the parent of the fix commit.

• Wrapper list skipped one word at a time, with no entry for flag-taking wrappers: _shell.py#L22-L24
• Leading variable assignments dropped whole, including any command substitution in them: _shell.py#L64-L80
• Interpreter unwrap matched only an exact -c token: _shell.py#L93-L98
• github policy: a segment whose head is not git or gh yields no op: github.py#L771-L825
• github policy: no ops means None (abstain, ALLOW): github.py#L991-L1006
• working_dir policy: same pattern for cd, git -C and git worktree: working_dir.py#L334-L376

• #389 (commit 1a05b7b, merged 2026-06-26, shipped in 0.3.0) broadens the shared parser so the hidden command is gated as if it ran directly: any interpreter flag group that contains c now unwraps like -c; timeout, nice, setsid and stdbuf are reduced to their inner command, including their own option values; and $(...) and backtick bodies are parsed as separate segments. Because the change is in the shared module, both the github and working_dir policies get it.
• #168 (merged 2026-06-18, shipped in 0.2.0) had already split commands on a lone background operator.
• The maintainer kept abstain as the default for commands the parser does not recognize, because these policies are composable allowlists that must not block unrelated commands. The report had suggested failing closed. The gate's strength therefore still depends on how complete the parser is.
• Later hardening: #3559 (merged 2026-08-05, in 0.9.0) gives the remaining option-taking wrappers the same treatment and adds a fail-safe that asks for approval, instead of allowing, when the parser cannot reach a real command.

Review agent session logs for shell tool calls where a git push or a gh write sits inside a shell interpreter call, a process wrapper or a command substitution. On GitHub, check the audit log of the token the agent used for pushes to repositories or branches outside its allowlist. On the host, run git worktree list in the agent's repositories and look for worktrees outside the allowed directories.

1. 2026-06-13omnigent 0.1.0 published on PyPI.
2. 2026-06-18#168 splits commands on a lone background operator; shipped in 0.2.0 on 2026-06-19.
3. 2026-06-26Reported privately via GitHub PVR (GHSA-7mqg-cx4g-x2rf), with a suggested fix.
4. 2026-06-26Maintainer merges the fix, #389, the same day.
5. 2026-06-27omnigent 0.3.0 released with the fix.
6. 2026-06-29Advisory published by the maintainer.
7. 2026-07-14CVE-2026-62676 reserved by GitHub.
8. 2026-08-05Further hardening merged in #3559; shipped in 0.9.0 on 2026-08-11.
9. 2026-08-21CVE-2026-62676 published.

Finder: Aaron Elijah Mars of Aeon. Tool: Aeon.

• Fix PR (merged 2026-06-26): omnigent-ai/omnigent#389, commit 1a05b7b
• Fixed release: omnigent 0.3.0
• GitHub advisory: GHSA-7mqg-cx4g-x2rf
• CVE: CVE-2026-62676 (assigned by GitHub)
• Affected repository: omnigent-ai/omnigent