# Omnigent's Nested Path Closed in September. The CVE Is Today.

> The primary is GitHub advisory GHSA-p5x3-3gqh-x44g, published 16 September 2026. An authenticated upload could set a nested sub-agent working directory that the root check rejected. PyPI omnigent 0.14.0, uploaded at 13:00 UTC on 15 September, is the patched release. VulnCheck numbered the same advisory CVE-2026-112015 on 18 October. Upgrading does not rewind a run that already escaped the workspace.

Source: https://hackerlogs.com/blog/omnigent-subagent-cwd-clock
Published: 2026-10-18

## Key takeaways

- GHSA-p5x3-3gqh-x44g published 11:17 UTC on 16 September, severity high. A nested sub-agent working directory skipped the root check. Patched in 0.14.0.
- PyPI 0.14.0 uploaded at 13:00 UTC on 15 September. The GitHub release published at 13:06 UTC. Tag v0.14.0rc1 already contains the fix commit. Tag v0.13.0 does not.
- VulnCheck CVE-2026-112015 published at 11:38 UTC on 18 October. The GitHub advisory API still had no CVE id. GitHub scores 8.8. The CVE scores 7.5 and 7.7.
- 0.3.0 fixed a different advisory, GHSA-p8rw-8qj3-hf33, for the root agent only. That patch is not this nested path.
- The fix checks new uploads. The advisory says it does not change terminal runtime directory precedence, and it does not rewind a run that already happened.

[GHSA-p5x3-3gqh-x44g](https://github.com/omnigent-ai/omnigent/security/advisories/GHSA-p5x3-3gqh-x44g) is the primary. GitHub published it at 11:17:43 UTC on 16 September 2026 and marked it high. An authenticated user could upload an agent bundle whose nested sub-agent set a working directory the root-agent check would have rejected. The same value, refused on the root, was accepted one level down. The advisory's patched version is Omnigent 0.14.0.

[CVE-2026-112015](https://www.cve.org/CVERecord?id=CVE-2026-112015) is VulnCheck's number for that advisory, published at 11:38:36 UTC on 18 October 2026 and updated at 12:23:31 UTC the same morning. A read of the GitHub advisory API on 18 October still showed no CVE id on the advisory. The package clock and the number clock are a month apart. PyPI lists the author as Databricks, Inc. The repository describes Omnigent as a meta-harness for Claude Code, Codex, Cursor, Pi, and custom agents.

US X trends at 22:28 UTC on 18 October were NFL names. This CVE was not one of them.

 High follows the GitHub advisory. The two published scores do not match, and the gap is the complexity field, not a second bug.

<img src="/omnigent-subagent-cwd-clock.svg" alt="Three panels for the Omnigent nested workspace check: a sub-agent directory the root check missed, version 0.14.0 in September, and a CVE number that arrived on 18 October." width="1200" height="675" />

## The package clock is 0.14.0.

[Pull request 7457](https://github.com/omnigent-ai/omnigent/pull/7457) merged at 08:24:06 UTC on 15 September. The merge commit is `4a406d5b`, which the CVE cites. PyPI `omnigent` 0.14.0 uploaded at 13:00:15 UTC that day. The GitHub release [v0.14.0](https://github.com/omnigent-ai/omnigent/releases/tag/v0.14.0) published at 13:06:10 UTC, six minutes later. Tag `v0.14.0rc1` already contains that commit. PyPI uploaded 0.14.0rc1 at 11:10:22 UTC on 15 September. The CVE's semver range, 0.3.0 before 0.14.0, includes that release candidate. The candidate is not an unpatched build.

Tag `v0.13.0` does not contain the commit. PyPI 0.13.0 uploaded at 14:29:07 UTC on 9 September, and the GitHub release published at 14:56:32 UTC the same day. The advisory's vulnerable range is `<= 0.13.0`, patched at 0.14.0. The CVE starts the range at 0.3.0. Keep both sentences. Do not collapse them into "everything before 0.14.0" without the parent bug underneath.

PyPI latest on 18 October is 0.18.0, uploaded at 08:32:17 UTC on 13 October. The GitHub release v0.18.0 published at 08:34:10 UTC the same morning. This brief did not diff 0.18.0. The advisory says 0.14.0 or later.

> The number landed on 18 October. The stable package that the advisory names shipped on 15 September. A scanner that only learned the CVE today is late. A runner still on 0.13.0 is not.

## The score split is complexity.

GitHub's CVSS 3.1 vector is `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`, score 8.8. VulnCheck's CVSS 3.1 vector is `AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H`, score 7.5. VulnCheck's CVSS 4.0 vector marks attack requirements present and scores 7.7. The advisory lists CWE-22 and CWE-668. The CVE lists CWE-22.

The prerequisites in the advisory are the requirements the 4.0 vector is pointing at. The server accepts untrusted bundles. The runner does not have `OMNIGENT_RUNNER_WORKSPACE` set. The reported configuration sets `sandbox.type` to `none`. The caller is authenticated. Trusted single-user local operation, where the operator already controls the executed code, is outside the report's threat model. This brief does not rescore the bug. It reports both vectors so a ticket does not quote 8.8 and 7.5 as if they were two findings.

The advisory credits @carfeii. A duplicate, GHSA-f2xx-j6gv-ffc8, submitted 14 September, was closed as the same defect, and the advisory also credits zx (@manus-pi). A terminal-path report, GHSA-598r-29w2-g93q, is a different precondition and is not this CVE.

## 0.3.0 closed a different check.

[GHSA-p8rw-8qj3-hf33](https://github.com/omnigent-ai/omnigent/security/advisories/GHSA-p8rw-8qj3-hf33), CVE-2026-62677, covers versions before 0.3.0 and was published at 14:52 UTC on 29 June. Its patched version is 0.3.0. The September advisory says that root-agent check must not be interpreted as the nested path. A fleet pinned at 0.3.0 through 0.13.0 can be "patched" on the June CVE and still inside this one.

The impact clock is a run that already happened. The advisory says the 0.14.0 change enforces the upload boundary. It does not change how a terminal chooses its directory at runtime, and it does not turn a trusted local config into an untrusted upload. Installing 0.14.0 does not rewind files a previous bundle already read or wrote as the runner user.

## What to do on a shared runner.

1. If the server accepts bundles you do not trust, move to 0.14.0 or later. Current PyPI latest is 0.18.0. Set `OMNIGENT_RUNNER_WORKSPACE` on runners. The reported case had the OS sandbox off. Turn that sandbox back on unless you have a written reason not to.
2. Do not close the ticket with "we are on 0.3.0." That version is the parent fix. The nested range runs through 0.13.0.
3. Treat a release candidate carefully. `v0.14.0rc1` contains the fix commit, even though a semver "before 0.14.0" rule would still flag it. `v0.13.0` does not contain the commit.
4. Review runners that executed uploaded bundles before 15 September. The upgrade does not undo that work. The advisory's threat model is the shared server, not a laptop where the operator already controls the code.
5. Quote one score and name the source. GitHub's 8.8 and VulnCheck's 7.5 are the same advisory with a different complexity bit. They are not two CVEs.

## Sources

- [Uploaded bundle's sub-agent working directory escapes workspace containment](https://github.com/omnigent-ai/omnigent/security/advisories/GHSA-p5x3-3gqh-x44g) (2026-09-16)
- [CVE-2026-112015](https://www.cve.org/CVERecord?id=CVE-2026-112015) (2026-10-18)
- [Omnigent 0.14.0](https://github.com/omnigent-ai/omnigent/releases/tag/v0.14.0) (2026-09-15)
- [omnigent 0.14.0 on PyPI](https://pypi.org/project/omnigent/0.14.0/) (2026-09-15)
- [Unvalidated working directory in an agent bundle](https://github.com/omnigent-ai/omnigent/security/advisories/GHSA-p8rw-8qj3-hf33) (2026-06-29)
