CVE-2026-58443

GitHub's public-only tokens contain an authorization gap that lets them write to private pull request head branches in public repositories — a failure mode that most developers using these tokens would find counterintuitive and potentially dangerous. When you generate a token scoped to 'public-only' access, your mental model is that the token can read public content and nothing else. What you likely aren't reasoning about is that pull request head branches exist in a conceptual gray area: they live in a private namespace but are operationally tied to public workflow contexts. The authorization system appears to evaluate these differently at the action level than the token's visibility-level scope intended. This is not a traditional missing-check bug — it's a composition failure. The token scope correctly restricts public repository operations. The PR mechanism correctly links across contexts. But the intersection — updating a private branch as part of a public workflow — falls into a gap neither boundary was designed to cover. The CVSS 9.1 score reflects the severity of this cross-boundary reach. What should you do? First, audit any automation using public-only tokens that interacts with pull request workflows — the token may have had more reach into private execution contexts than you assumed. Second, review CI/CD pipelines triggered by PR events from public contributors; the trigger itself may have been reachable through this gap. Third, consider whether any downstream automation (auto-merge, deployment triggers, environment provisioning) could have been activated by writes you didn't authorize. Finally, treat public-only tokens as a deprecated abstraction going forward — the platform has layered Actions, workflow triggers, and deployment environments onto authorization surfaces that the 'public-only' design predates. If you need precise boundary control, migrate to more granular token scopes or repository-specific tokens rather than relying on visibility-based authorization for workflow automation. The gap exists precisely because nobody modeled public tokens as having any path into private execution contexts — and your threat model should assume that path may have been there all along.

Reviewed through automated stages and approved by a human before publication.