Advisory · CVE-2026-116870
Octopus Server OIDC issuer validation gap can accept tokens from a non-legitimate issuer
Octopus Server performed OIDC token issuer validation inconsistently, so a token issued by a suitably configured non-legitimate issuer could be accepted as a token belonging to a service account from a legitimate trusted issuer, where a service account has an OIDC identity configured. CVSS 4.0 8.7.
- Vendor
- Octopus Deploy
- Product
- Octopus Server
- Identifier / CWE
- CVE-2026-116870
CWE-1289 - Action timing
- Immediate
Explain it like I’m five
The deployment server checks who issued an identity token, but not the same way every time. A token stamped by the wrong issuer can slip through and be treated as if a trusted issuer vouched for the service account.
- 01Service account configured
A deployment uses an Octopus service account with at least one OIDC identity configured.
- 02Rogue issuer token obtained
The attacker obtains a token from a suitably configured non-legitimate issuer and knows or guesses details of the service account identity.
- 03Token presented
The attacker presents the token to Octopus Server as the service account.
- 04Validation passes wrongly
Inconsistent issuer validation accepts the token as belonging to the legitimate trusted issuer's service account.
What happened
Octopus Deploy published CVE-2026-116870 on October 27, 2026 in advisory SA2026-15, rated CVSS 4.0 8.7 in the record: in affected versions of Octopus Server, OIDC token issuer validation was performed inconsistently, which could result in a token issued from a suitably configured non-legitimate issuer being accepted as a token belonging to a service account from a legitimate trusted issuer.
Per the record, exploitation requires a service account with at least one OIDC identity configured, and the attacker would also need to know or guess some details of that identity. The record lists Octopus Server 2024.1.0 before 2026.1.11781, 2026.2.0 before 2026.2.13438, and 2026.3.0 before 2026.3.15816 as affected, making those boundary builds the fixed versions for each branch.
What to do
- Inventory Octopus Server instances and note versions, then identify service accounts with OIDC identities configured.
- Upgrade to 2026.1.11781, 2026.2.13438, or 2026.3.15816 or later, matching the branch in use.
- Until upgraded, review which external issuers can reach the server and consider disabling OIDC service account authentication where it is not required.
- Audit deployment and release creation logs for service account activity from unexpected issuers, networks, or times.
- Rotate service account credentials and downstream deployment secrets if unexpected service account activity is found.
- Verify the deployed version after updating.
Management note
Octopus is a skeleton key for production estates: its service accounts deploy code everywhere. An issuer-validation gap at that layer is an identity incident, not a routine patch, so pair the upgrade with a hard look at what the affected service accounts did.