CVE-2026-62677

Omnigent (a pip-distributed agent framework) does not validate the 'os_env.cwd' field of uploaded agent bundles, so a bundle author can set the agent's working directory to any host path, such as '/' or '/home/<victim>', with no normalization or boundary check anywhere in the spec pipeline. An authenticated, non-admin user can upload a session-scoped bundle with a malicious cwd; on runners deployed without the 'OMNIGENT_RUNNER_WORKSPACE' environment variable, the runner accepts the attacker-supplied path verbatim, making everything under that path in-bounds for the agent's file and shell tools. The attacker gains arbitrary read and write access to the runner host filesystem plus disclosure of host environment secrets; with 'fork=true' and a cwd set to another user's home directory, the runner copies that tree into the agent-readable workspace. Only Omnigent deployments whose runners realize session-scoped uploaded bundles without 'OMNIGENT_RUNNER_WORKSPACE' set are affected, and any authenticated user can trigger it — no admin scope, user interaction, or shared-agent overwrite is required. No public proof of concept is known, the issue is not in CISA KEV, and EPSS currently estimates a 0.4% probability of exploitation within 30 days; CVSS 3.1 scores it 8.8 (High).

What to do: Set 'OMNIGENT_RUNNER_WORKSPACE' on every Omnigent runner — CLI- and host-launched sessions already set it, so audit any other launch paths — because it is the only control that overrides attacker-supplied cwd values. No fixed version is stated in the advisory; until a patched pip release ships, restrict agent-bundle uploads to trusted authenticated users and note that the shared-agent guard proposed for the related GHSA-jrrm-9hc7-2v3h advisory does not address this flaw. Once a fix is released, upgrade and re-verify that runner configurations still set the workspace variable so uploaded bundles no longer control the environment root.