GHSA-h5p6-j8m9-xx4p: Octo STS discloses trust policy contents to unauthorized callers via Exchange error messages
Octo STS (github.com/octo-sts/app) before 0.11.2 returns trust policy configuration to callers whose OIDC token does not satisfy that policy. TrustPolicy.CheckToken included the policy's issuer, subject and audience values or patterns and claimpattern names and regular expressions in its PermissionDenied errors, which Exchange returned verbatim. Exchange also selected the GitHub App installation before checking the token, so errors from resolving the policy's app or apppattern pin were returned to callers the policy does not trust. An attacker who holds any validly signed OIDC token, such as a GitHub Actions token from a repository they own, and who knows or guesses a target owner/repo and identity name can read that policy's matching rules, even when the policy is stored in a private repository. These rules often name internal repositories, branches, environments or cloud account identifiers. The issue does not allow minting tokens or bypassing a trust policy. This issue is fixed in 0.11.2.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
github.com/octo-sts/appto a version that resolves this vulnerability.Fixed in 0.11.2
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs any validly signed OIDC token, such as a GitHub Actions token issued for a repository they control. They must also know or guess the target owner/repository and identity name.
What information can be exposed?
Error responses can reveal trust-policy issuer, subject, and audience values or patterns, plus claim_pattern names and regular expressions. This may disclose internal repository names, branches, environments, or cloud account identifiers, including when the policy is stored in a private repository.
Can this be used to obtain credentials or bypass policy checks?
No. The issue does not permit token minting or bypassing a trust policy; it exposes policy matching rules through returned error messages.
What should teams do if they use Octo STS?
Upgrade to version 0.11.2, which fixes the issue. Until then, treat trust-policy values as potentially exposed to callers with valid OIDC tokens and avoid placing unnecessary sensitive identifiers in those rules.