Octo STS EUVD-2026-115653

Exploitation requires the attacker to (1) possess any validly signed OIDC token from any accepted issuer - for example a GitHub Actions token minted from a repository the attacker owns - and (2) know or correctly guess a target's owner/repo and the trust-policy identity (file) name, against an Octo STS deployment running <= 0.11.1 where the GitHub App is installed for that owner. The flaw is triggered via the Exchange RPC: in vulnerable versions the installation and app_pattern/app pin were resolved, and TrustPolicy.CheckToken's patterns were interpolated into PermissionDenied errors, before the token was validated, so the config leaks on mismatch. LIMITING FACTORS: the attacker must already know/guess the owner/repo and identity name (not discoverable from the flaw itself); only configuration text is disclosed, with no ability to mint tokens or bypass policy; self-hosted deployments have no workaround other than upgrading to 0.11.2, while the hosted service is protected once the fix is deployed.

This is a genuine but moderate-severity information-disclosure issue (CWE-209) best characterized as 'medium real risk, not an emergency.' The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N = 5.3) is internally consistent with the mechanism: Octo STS's Exchange RPC is network-reachable and the flaw triggers deterministically (AC:L), impact is limited to confidentiality (C:L, I:N, A:N) because the advisory is explicit that no token minting or trust-policy bypass is possible. The PR:N rating deserves a caveat worth verifying with the vendor: exploitation does require the caller to present a validly signed OIDC token from some issuer - the vendor treats this as 'no privilege on the target' because any attacker can trivially mint a GitHub Actions token from a repository they own, which is a defensible but not strictly 'unauthenticated' reading. No EPSS score, CISA KEV listing, or public proof-of-concept was supplied in the intelligence; absence of those is not itself evidence of safety, but combined with the this_month (not act_now/emergency) priority label and the confidentiality-only impact, there is no signal of active exploitation. The practical risk is bounded by the attacker needing to know or guess a valid target owner/repo plus identity name, and the payoff is reconnaissance (leaked internal repo/branch/environment/cloud-account identifiers from private trust policies), not direct compromise - a useful stepping stone for a targeted attacker rather than a mass-exploitable flaw.

An attacker obtains a GitHub Actions OIDC token from a repository they control and sends it to a target organization's Octo STS Exchange endpoint, guessing a plausible owner/repo and identity name. Because the installation and app pin were resolved before the token was checked, the returned PermissionDenied error echoes back the trust policy's issuer/subject/audience patterns and claim regexes, revealing internal repository, branch, environment, or cloud-account identifiers even when the policy lives in a private repo. No public exploit identified at time of analysis; the attack is low-complexity (AC:L) and network-based (AV:N) but yields only configuration disclosure, not token issuance.