Octopus Server EUVD-2026-110722

Exploitation requires a target Octopus Server configured so that at least one service account has one or more OIDC identities defined - i.e. OIDC authentication is in use for service accounts (not a default on a fresh install that does not use OIDC). The attacker must additionally know or guess specific details of that OIDC identity (such as the subject/claims the legitimate trusted issuer would present) and must configure a non-legitimate OIDC issuer capable of minting a matching token. Limiting factors: the dependence on knowing a particular identity's details prevents blind, large-scale exploitation and skews toward targeted attacks; the Octopus authentication endpoint must be network-reachable; and the affected version must be deployed (2024.1.0-<2026.1.11781, 2026.2.0-<2026.2.13438, or 2026.3.0-<2026.3.15816). No end-user interaction is required.

This is a genuine authorization/authentication-bypass flaw (CWE-1289, inconsistent OIDC token issuer validation) that allows impersonation of a service account, with the vendor CVSS 4.0 vector rating impact VC:H/VI:H/VA:H (score 8.7). The vendor vector is AV:N/AC:L/AT:N/PR:L/UI:N, i.e. network-reachable and low-complexity. However, that rating is in tension with the description, which states exploitation requires (a) a service account that already has an OIDC identity configured and (b) the attacker knowing or guessing details of that identity and standing up a 'suitably configured' malicious issuer - these are real attack requirements that argue for higher complexity (AT:P / AC:H) than AC:L/AT:N suggest. The vendor's PR:L is also debatable: the attacker forges a token from their own issuer rather than using Octopus credentials, so no Octopus privilege is strictly needed (arguably PR:N), with the difficulty living in the knowledge/configuration requirement - verify intended PR with the vendor. On the decision signals: no CISA KEV listing, no EPSS score supplied, and no public exploit, while the vuln.today decision label is 'this_week' (not act_now/emergency). Taken together this is a serious, patch-this-week issue rather than an active-exploitation emergency; the requirement to know a specific OIDC identity's details makes opportunistic mass exploitation unlikely and points toward targeted use. Exploitation status: no public exploit identified at time of analysis.

An attacker who learns the details of a service account's configured OIDC identity on a target Octopus Server stands up their own non-legitimate OIDC issuer and mints a token crafted to match the trusted issuer's claims. Because issuer validation is applied inconsistently, Octopus accepts the forged token as belonging to the legitimate service account, granting the attacker that account's privileges (deployments, variables/secrets, and connected infrastructure). No public proof-of-concept or exploit code is identified at time of analysis.