Home Depot exposed a GitHub personal access token in a public repository, which could have allowed unauthorised access to source code and related systems. The safe lesson is to assume exposed tokens are compromised, revoke them immediately, inspect repository history and access logs, and add secret scanning to prevent future commits from publishing credentials.
What actually happened in the Home Depot token exposure
Home Depot exposed a GitHub personal access token in a public repository, which created a direct path to source code and any systems reachable with that token. The incident is best understood as a secrets exposure event, not just a code hygiene mistake, because the token itself was the access mechanism and had to be treated as compromised the moment it was published.
That distinction matters operationally. A leaked token can be replayed immediately, copied outside the organisation’s control, and used before anyone notices the commit or cleans the repository. Home Depot Year-Long Token Exposure covers the same exposure pattern and the remediation lesson: exposure equals compromise until the secret is revoked and replacement is complete.
Why a GitHub token leak is a security event, not a repository event
A personal access token can authenticate as a developer, automation account, or integration account, so the blast radius depends on what it could reach, not where it was found. In practice, that can include source code, private repositories, CI/CD systems, package publishing, and other developer tooling connected to GitHub. If the token had broad scopes, the exposure becomes a privileged access problem as well as a secrets problem.
Token exposure also changes the evidence you need to preserve. The first question is not only whether the repository was public, but whether the token was ever used after publication and whether it granted write, admin, or workflow permissions. That is why this class of incident usually requires both secret rotation and log review, not one or the other. Guide to the Secret Sprawl Challenge is useful for understanding how source code, CI/CD, and token leakage reinforce each other.
Because GitHub tokens often sit inside a wider automation chain, the exposure may also reveal more than the repository itself. If the token could call APIs, trigger workflows, or reach deployment tooling, the organisation should assume the secret may have exposed a broader trust relationship than the commit history suggests.
What responders should do after finding an exposed token
The practical response starts with revocation, not investigation. If the token is still valid, revoke it immediately, replace it with a new credential, and check whether the replacement needs narrower scope or shorter lifetime. Then inspect repository history, runner logs, audit logs, and access logs for signs that the token was used after it became public.
History review matters because secrets often survive in older commits, tags, forks, and cached build artefacts even after the obvious file is cleaned up. If the token was embedded in automation or a deploy path, confirm whether any downstream systems inherited that credential or accepted it as trust. GitHub and GitHub Actions Security Guide helps teams think through workflow permissions, token scope, and runner exposure when a leak may have touched automation.
Where evidence suggests misuse, treat the issue as a possible source-code and credential compromise event. That usually means checking whether new branches, releases, secrets, or repository settings changed unexpectedly during the exposure window, and whether any connected services accepted the token from unusual locations or at unusual times.
Risk and Threat Considerations
An exposed GitHub token is valuable to an attacker because it can turn a single mistake into authenticated access. The risk is highest when the token can read private code, push changes, manage workflows, or reach connected services, because the initial leak may become code theft, malicious commit activity, or downstream credential harvesting.
Failure mechanism: The token is copied from the public repository, replayed before revocation, and used to access repositories or related systems that still trust it.
Impact: Organisations can lose source-code confidentiality, allow unauthorised changes, expose additional secrets, and expand the incident into a broader supply-chain or account-takeover problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The incident is a GitHub token leak, which is secret exposure by definition. |
| NHI-07 — Long-Lived Secrets | The lesson centers on exposed tokens needing fast rotation and shorter lifetime. | |
| Recommendation — Scan repositories for leaked secrets and revoke any exposed token immediately. Reduce token lifetime and rotate any credential that appears in source control. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | A leaked personal access token is an authenticator whose lifecycle must be controlled. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Investigating possible misuse depends on reviewing logs and access records. | |
| Recommendation — Revoke, replace, and monitor authenticators as soon as exposure is confirmed. Review audit and access logs for use of the exposed token after publication. | ||
| OWASP ASVS | V6 — Authentication | The exposure affects an authentication credential used to access systems. |
| Recommendation — Treat exposed tokens as compromised authentication material and replace them promptly. | ||
Practitioner Guidance
What to verify: Confirm the token’s scopes, age, and last use, then compare that against commit timestamps, audit logs, and repository visibility history. If the token could authenticate to more than one system, assume each of those systems may need separate inspection.
Decision rule: If a secret has been publicly exposed, treat it as compromised regardless of whether you have proof of abuse. The burden is on the organisation to show the token was not usable or was immediately revoked, not on an attacker to prove they saw it first.
What good looks like: Secrets scanning prevents the commit from landing, revoked tokens stop working quickly, and the response path can show exactly when the token was exposed, revoked, and replaced.
Practitioner takeaway: The key judgement is to respond to exposed tokens as live credentials, not as harmless artefacts, because the security outcome is determined by what the token could do before anyone found the commit.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org