ZaneOps CVE-2026-121734

Exploitation requires a multi-workspace (multi-tenant) ZaneOps deployment; single-workspace instances are not affected. The attacker must already hold the administrator role in at least one workspace (PR:L - self-created workspace suffices), and the target project must have preview environments enabled with an active fork PR preview still in the PENDING (unapproved) state. The attacker obtains the exact project slug and environment name - including the random fake.slug() suffix - from the public PR comment ZaneOps auto-posts (approval_url at models/main.py:2321), so nothing must be guessed. Limiting factors that reduce real-world risk: the route is read-only (no write/deploy to the victim workspace), exposure is confined to the PENDING window until a maintainer approves/declines the fork preview, the correctly-scoped POST sibling is unaffected, and no RCE or integrity impact is possible through this path.

This is a genuine but bounded cross-tenant confidentiality flaw, best characterized as a moderate, targeted-risk issue rather than a mass-exploitation emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) and the VC:H/VI:N/VA:N impact set agree with the evidence: network-reachable API, but requiring privileges (PR:L - the attacker must hold a workspace admin role) and an attack requirement (AT:P - an active fork PR preview must exist in the PENDING state in the target workspace), with impact limited to confidentiality only (no integrity or availability loss, no scope change). The vuln.today decision label is 'this_month', consistent with a real but non-critical priority. No EPSS score and no KEV status were provided - absence of both, combined with a product requiring multi-tenant deployment and an insider admin foothold, points to targeted rather than widespread opportunistic exploitation. The PoC in the GHSA advisory is explicitly derived from static review and was not executed against a live deployment, so it should not be treated as confirmed active exploitation. Net: prioritize patching within the stated this_month window on shared multi-workspace instances, but this is not a drop-everything event given the privilege and deployment-mode preconditions and read-only, confidentiality-only impact.

On a shared multi-tenant ZaneOps instance, an attacker who is administrator of their own workspace reads the slug and environment name that ZaneOps automatically posts in a public comment on a victim workspace's fork pull request. They then call the GET handler of ReviewPreviewEnvDeployAPIView with those parameters; because the lookup omits the workspace/project scoping filter used by its POST sibling, the victim's pending preview environment is returned, disclosing plaintext environment variables (cloned from production) and the preview basic-auth credentials. A public PoC reference exists in the GHSA advisory; it is not verified as working exploit code, as it was derived from static review and not run against a live deployment.