A security researcher disclosed on Thursday that a GitHub personal access token committed to a public repository in May granted read access to 340 private repositories across two semiconductor companies, including repositories containing firmware build definitions and the workflow configuration for signing operations. The token belonged to an engineer at a contract design firm that works with both companies and had been scoped with broad organization access. It was live for approximately nine weeks before the researcher found it and reported it. Both companies have rotated credentials, audited access logs, and say they found no evidence of use by anyone other than the researcher.
How the token got there
The engineer committed a configuration file to a personal public repository while working on a build tooling side project. The file contained a token used for a legitimate internal purpose, and it had been copied into the working directory during debugging. The commit was one of about forty in a routine push. This is the most ordinary credential leak imaginable and it happens continuously.
GitHub's secret scanning did detect the token and notified the engineer, which is the system working. What did not work is the response: the notification went to an email address the engineer rarely checked, and the token was a classic personal access token rather than a fine-grained one, so GitHub's automatic revocation for provider-partnered secret types did not apply. GitHub revokes tokens it detects for many third-party services automatically and does not automatically revoke its own personal access tokens, a decision that looks worse each time this happens.
What the access covered
Read access to 340 private repositories is a substantial exposure and it is not, by itself, catastrophic. The researcher's report is careful about this: the token could read the workflow definitions that describe how firmware images are built and signed, including the names of the signing services and the structure of the pipeline. It could not read the signing keys, which live in hardware security modules, and it could not modify anything.
That distinction matters and it understates the risk. Knowing exactly how a signing pipeline is structured, which service accounts it uses, and what checks it performs is precisely the reconnaissance an attacker needs to target the pipeline itself. The 2020 SolarWinds intrusion and the 2023 3CX compromise both involved attackers who understood their target's build system in detail. Read access to build configuration is the first step toward that understanding.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
Why contractor access keeps producing these
The engineer worked for a design services firm engaged by both semiconductor companies, which is entirely normal in an industry where specialized contract teams move between clients. Each client granted organization access through GitHub, and the token was scoped to the engineer's full access rather than to a specific repository or purpose, because that is the default and because narrower scoping requires knowing in advance what you will need.
Fine-grained personal access tokens have existed since 2022 and allow per-repository scoping with expiry. Adoption has been slow because the classic tokens work, because the fine-grained interface is more work to configure, and because organizations have not enforced them. Both affected companies have now disabled classic tokens organization-wide, which is the correct response and which will produce a week of broken automation at each of them.
The disclosure process
The researcher, who works independently and asked to be identified only by handle, found the token through routine scanning of public repositories, verified its scope with a single read-only API call, and reported it within two hours to both companies through their published security contacts. One responded in 40 minutes and revoked within the hour. The other took eleven hours, which the researcher noted without complaint and which is the sort of detail that tells you about an organization's maturity.
Neither company offered a bounty, since the finding falls outside their program scopes, which cover product vulnerabilities rather than credential exposure. Several security researchers have argued that credential leak reporting should be compensated, since the alternative is that finders sell to less scrupulous buyers. The counterargument is that paying for scan results incentivizes mass automated scanning, which already happens continuously.
What organizations should do
Disable classic personal access tokens at the organization level and require fine-grained tokens with expiry. That is a one-line policy change followed by weeks of fixing automation, and it is the single highest-value action available. Beyond that, enable push protection so that secret scanning blocks commits containing detected secrets rather than reporting them afterward, which GitHub supports and which many organizations leave off because it occasionally blocks a legitimate commit.
For contractor access specifically, the durable answer is short-lived credentials issued through OIDC rather than tokens at all, which works for CI and does not work for a human running a script on a laptop. For the human case, the practical control is scoping and expiry, and reviewing what contractors can reach on a schedule rather than at offboarding. Every organization discovers during that review that someone who left in 2024 still has access to something.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Open Source
- Zero Trust
