CVE-2026-105770 in Octo STS
Summary
by MITRE • 11/03/2026
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 claim_pattern 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 app_pattern 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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified in Octo STS prior to version 0.11.2 represents a critical information disclosure flaw rooted in improper error handling and token validation logic within the OpenID Connect (OIDC) provider implementation. The core technical deficiency lies in how the TrustPolicy.CheckToken function processes authentication requests that fail policy compliance checks. Instead of returning generic, non-descriptive error messages for unauthorized access attempts, the system returned verbose PermissionDenied errors containing sensitive configuration details. Specifically, these error responses included the exact issuer, subject, and audience values or patterns defined in the trust policy, as well as claim pattern names and regular expressions used to validate incoming tokens. This behavior effectively leaks internal security configurations to any external party capable of submitting a request that does not meet the specified criteria.
The operational impact is exacerbated by the order of operations within the authentication flow. The Exchange component selected the GitHub App installation associated with the requested identity before fully validating whether the presented OIDC token satisfied the trust policy requirements. Consequently, if an attacker targeted a specific repository or organization and attempted to authenticate using any validly signed OIDC token—such as one generated by a GitHub Actions workflow in a public repository they control—the system would attempt to resolve the associated app configuration. If this resolution failed due to mismatched policies, the resulting error message revealed details about the intended application pinning rules. This allows an attacker who possesses knowledge or can guess the target owner-repository pair and identity name to enumerate internal security configurations without needing valid credentials for that specific resource.
This information leakage poses a significant risk to organizational security posture by exposing sensitive architectural details stored in private repositories. The disclosed trust policy matching rules often contain identifiers for internal repositories, protected branches, deployment environments, or cloud account IDs. Such intelligence enables attackers to map out the infrastructure landscape and identify potential targets with greater precision. Although this vulnerability does not permit token minting nor allow an attacker to bypass a valid trust policy directly, it facilitates reconnaissance activities that can lead to more severe exploits in subsequent stages of an attack chain. The exposure of regular expressions and claim patterns may also aid attackers in crafting tokens that might satisfy future or less restrictive policies if the organization updates its configuration without addressing these underlying flaws.
From a standards perspective, this vulnerability aligns with CWE-209: Generation of Error Message Containing Sensitive Information, as it involves the disclosure of sensitive data through error messages. It also relates to CWE-778: Insufficient Initial Input Validation, given that the system processed requests and returned detailed feedback before completing full policy validation. In terms of MITRE ATT&CK framework techniques, this behavior supports reconnaissance activities under T1592: Gather Victim Host Information or T1046: Network Service Discovery, as it allows an adversary to gather information about application configurations and internal services from the outside perimeter.
To mitigate this vulnerability, organizations must upgrade Octo STS to version 0.11.2 or later, where the issue has been resolved by ensuring that error responses do not leak policy-specific details for unauthorized requests. Additionally, developers should implement generic error handling practices across all authentication endpoints to prevent information leakage through verbose stack traces or configuration dumps. It is also recommended to review trust policies in private repositories to ensure they do not inadvertently expose sensitive internal identifiers even if such leaks were possible in previous versions. Regular security audits of API responses and strict adherence to the principle of least privilege in error messaging are essential steps to maintain a robust defense against information disclosure attacks.