Omnigent EUVD-2026-64015

Exploitation requires three concurrent conditions: (1) the attacker holds an authenticated session with bundle-upload permissions on the Omnigent server (CVSS PR:L - this is not unauthenticated exploitation); (2) the target runner has OMNIGENT_RUNNER_WORKSPACE unset in its environment - when this variable is present, resource_registry.py does not preserve the attacker-controlled path and the vulnerability does not reach the filesystem; (3) the server operates with enforce_handler_allowlist=True, which is the default for untrusted multi-user deployments (local/single-user operators with enforce_handler_allowlist=False are explicitly excluded from the new validation by design). Limiting factors: requires valid credentials, requires a specific runner misconfiguration (unset env var), and affects only Omnigent versions prior to 0.3.0.

The CVSS 3.1 score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects the broad impact - full confidentiality, integrity, and availability - achievable via a network-reachable upload endpoint requiring only authenticated access. However, the raw CVSS does not capture the critical deployment precondition: exploitation only fully materializes when OMNIGENT_RUNNER_WORKSPACE is unset on the runner. Where that variable is set, resource_registry.py does not propagate the attacker-controlled path and the impact is substantially contained. No EPSS score was provided in the input data, preventing quantitative exploitation probability assessment. KEV status is absent - no confirmed active exploitation. No public proof-of-concept is identified. The vulnerability is a logic flaw rather than a memory corruption issue, which generally implies reliable exploitability once conditions are met, but the two-factor requirement (authenticated session + unset env var) meaningfully reduces the realistic attack surface compared to the CVSS impression. Organizations running Omnigent in multi-user or cloud-runner deployments with untrusted authenticated users and without OMNIGENT_RUNNER_WORKSPACE set should treat this as high priority.

An authenticated Omnigent user crafts a valid agent bundle with the os_env.cwd field set to an absolute path such as /etc or a traversal path such as ../../etc and uploads it to a runner where OMNIGENT_RUNNER_WORKSPACE is unset. The framework accepts and stores the path verbatim, resolves it as the agent workspace root, and the agent's sys_os_read, write, edit, and shell tools then operate against the host filesystem, allowing the attacker to exfiltrate environment secrets or runner credentials. No public proof-of-concept has been identified at time of analysis.