Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 (writerepos/writebranches allowlist) and policies/builtins/workingdir.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 push to an attacker-controlled repo (code / secret exfiltration), - push to a protected branch, - escape its…
Recommended action: Upgrade to 0.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authenticated, non-admin user can obtain arbitrary host-filesystem read/write (and host environment-secret disclosure) on an Omnigent runner by uploading an agent bundle whose osenv.cwd points outside any intended workspace (e.g. / or /home/<victim). The cwd field is taken verbatim from the bundle with no validation, normalization, or boundary check anywhere in the spec pipeline. This is a different sink from GHSA-jrrm-9hc7-2v3h (CWE-94, shared-agent bundle overwrite - stdio MCP RCE). It shares the bundle-upload vector but is reached through the user's own session-scoped agent and is not addressed by that advisory's proposed shared-agent guard. Preconditions - Runner realizes a session-scoped uploaded bundle without OMNIGENTRUNNERWORKSPACE set. When that env var is set (CLI- and host-launched sessions set it), the spec cwd is overridden and the attack is neutralized — so this is deployment-gated, not universal. - Attacker is any authenticated user (no admin scope;…
Recommended action: Upgrade to 0.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/{sessionid}/agent. 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. Details The vulnerable endpoint is the full agent bundle upload route: PUT /sessions/{sessionid}/agent This route checks whether the caller can edit the session: LEVELEDIT session permission check But it does not check whether the bound agent is a shared/template agent. Shared/template agents have: The API already exposes that these agents are not meant to be MCP-editable: mcpserverseditable is false for shared/template agents The direct MCP edit endpoint correctly blocks shared/template agents: sessionmcpservers.py shared-agent guard The…
Recommended action: Upgrade to 0.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authenticated user can upload a crafted agent bundle that defines a server-side Python callable tool. The server validates the uploaded bundle, but it does not block dangerous callable: paths in untrusted user-provided agent configs. When the tool is invoked, the runner imports and executes that Python callable. A crafted bundle can point the tool at subprocess.checkoutput, which lets the attacker run a local command on the runner machine. This is serious because hosted Omnigent deployments can have multiple users and shared or managed runner hosts. A normal logged-in user should not be able to make the runner execute arbitrary local commands. Details The uploaded bundle path is reachable through session creation. Omnigent supports custom agent bundles through multipart POST /v1/sessions; the Web UI uses this same endpoint for custom agents: Create custom agent builds and uploads a bundle \ createBundledSession posts the bundle to /v1/sessions A crafted bundle can also be…
Recommended action: Upgrade to 0.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.