Incus CVE-2026-115373

The attacker must hold a valid Incus TLS client certificate that is project-restricted (PR:L, so they are authenticated but confined to their own project), and the deployment must use Incus's multi-project / restricted-certificate tenancy model. They must know the exact 122-bit crypto/rand UUIDv4 of a specific operation, which Incus does not disclose to a restricted client - the reporter verified that /1.0/operations?project=attacker, ?all-projects=true and ?project=victim all return empty - so the UUID must come from out-of-band leakage (operator shell history, CI logs, a proxy or APM trace capturing the async Location header, 'incus monitor' output pasted into a ticket, a former project membership, or a shared automation account). The targeted operation must be in-flight at the instant of the read because operations are transient; this out-of-band-UUID requirement plus the timing window are the key limiting factors that make exploitation targeted rather than widespread. No victim interaction is needed once the UUID is known. The demonstrated escalation to full server admin additionally requires a trust-enrolment ('incus config trust add') operation to be pending at the moment of the read.

The vendor-assigned CVSS 4.0 score is 7.0 (HIGH) with vector AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/SC:H, which I concur with. Although the attack vector is network (the Incus REST API over TLS), three signals pull real-world risk below the raw score: AT:P (an attack requirement must be met - a target operation must be in-flight), PR:L (a valid project-restricted client certificate is required), and the reporter-verified fact that the 122-bit random operation UUID cannot be enumerated through any API path and must be obtained out-of-band. There is no CISA KEV listing, so this is NOT confirmed actively exploited; EPSS was not provided in the input, so probabilistic exploitation likelihood cannot be stated. A detailed, reproducible PoC is published inside the GHSA advisory itself. The vuln.today decision label is 'this_week', consistent with a serious but non-emergency authorization flaw: a genuine priority for anyone running multi-tenant Incus with restricted certificates, but not a mass-exploitable, internet-spray issue because of the out-of-band UUID dependency and the transient nature of operations. CWE-862/863 (missing authorization) is confirmed by the vendor. Note the input Tag 'Authentication Bypass' is inaccurate: the attacker is already authenticated (they hold a valid certificate) and the defect is a missing authorization check, i.e. an authorization bypass.

A tenant whose client certificate is restricted to project 'attacker' obtains the UUID of an in-flight exec operation running in project 'victim' from an out-of-band source (a CI log, operator shell history, or a proxy/APM trace of a Location header), then sends GET /1.0/operations/{uuid}. The handler performs no authorization at all and returns the victim's full command line, its environment variables (where deployment tooling places DB_PASSWORD, API tokens and cloud credentials) and the operation's websocket secrets; a full reproduction sequence is published in the GHSA advisory. If a trust-enrolment operation happens to be pending at read time, the same read discloses the enrolment token, which the reporter demonstrated can enrol a fresh unrestricted certificate and yield full server admin.