Home Depot Internal Systems Exposure: Leaked GitHub Token Left Sensitive Access Open for Nearly a Year

Home Depot has revoked access tied to a leaked GitHub access token after a cybersecurity researcher reported that the credential exposed parts of the retailer’s internal engineering environment for nearly a year. The incident is a modern example of how a single long lived secret, published in the wrong place, can open a wide path into source code, build pipelines, and cloud connected systems.

What happened

According to the researcher, an employee’s private GitHub access token was accidentally published online in early 2024. In early November 2025, the researcher discovered the token and validated that it still worked. When tested, it reportedly granted access to hundreds of Home Depot private repositories hosted on GitHub and enabled write level actions, meaning code could potentially be altered rather than merely viewed.

The researcher said the access extended beyond repositories into parts of Home Depot’s cloud connected engineering environment, including systems associated with order fulfillment and inventory management, along with development pipelines. After the researcher says they received no response for weeks, the matter gained attention and the exposed token was removed and access revoked following media outreach in early December 2025.

Why a leaked token can be as dangerous as a breach

Incidents like this blur the line between “exposure” and “intrusion.” A working credential posted publicly is not just a theoretical weakness. It is a usable key. If the token truly had write permissions, the risk expands from data access into integrity compromise, where an attacker could tamper with code, alter workflows, or introduce changes that are difficult to detect in large development environments.

The most serious downstream scenario is a supply chain style attack. If an adversary can modify source code or CI/CD workflows, they may be able to inject malicious logic into internal tools, infrastructure templates, or deployed services. Even small changes, like altering a build script, adding a dependency, or modifying a deployment workflow, can become a quiet mechanism for persistence and lateral movement.

Potential impact areas

While public reporting does not confirm malicious use, the exposure described carries several high impact risk categories:

• Source code exposure: Private repositories can reveal proprietary logic, internal service endpoints, architectural patterns, and occasionally embedded secrets.
• Code integrity risk: Write access raises the possibility of stealthy code modification, including backdoors, credential harvesting, or logic changes that affect business workflows.
• Pipeline compromise: CI/CD systems are powerful because they can build, sign, and deploy. If a token touches pipeline configuration, it can become a stepping stone to broader compromise.
• Cloud access expansion: If the token’s scope included integrations or linked infrastructure, a repository foothold can translate into access to environments that support operational systems.
• Operational disruption risk: Systems connected to fulfillment and inventory are business critical. Any tampering, even without a classic ransomware event, can disrupt operations and trust.

Why detection is hard after the fact

When a token is exposed for months, security teams face two practical challenges. First, they must determine whether the credential was used by anyone besides the reporter. Second, they must confirm whether any actions performed with that credential changed code, pipelines, or configurations in ways that could persist after revocation.

This is why audit logs matter. Git hosting platforms, identity providers, and cloud services usually provide event trails, but retention windows vary. If logs are not centralized and preserved long enough, the ability to reconstruct a credible timeline becomes limited, which prolongs remediation and increases uncertainty.

How this typically happens

Most leaked tokens come from a handful of repeat patterns:

• Accidental commits of credentials into code repositories
• Secrets copied into troubleshooting snippets, gists, or paste sites
• Build logs or debug output that prints environment variables
• Over-permissive tokens that never expire and are reused across tools
• Missing automated scanning for secrets in source control and developer workflows

The consistent theme is not sophistication. It is normal engineering behavior combined with a secret that was too powerful, too persistent, or insufficiently monitored.

Immediate remediation actions that reduce real risk

If an organization discovers a similar exposure, the safest response is to treat it as potentially malicious until proven otherwise. Practical steps that matter most are:

• Revoke and rotate immediately: Remove the token, rotate any reachable secrets, and invalidate related sessions or credentials.
• Scope the token’s permissions: Identify every resource the token could access, including repos, CI workflows, package registries, and cloud integrations.
• Hunt for misuse: Review Git audit logs, repo events, and CI/CD runs for unusual IPs, odd timestamps, unexpected workflow edits, or new deploy keys and runners.
• Verify code integrity: Look for unauthorized commits, altered pipeline definitions, dependency changes, and suspicious releases.
• Strengthen controls: Enforce short lived tokens, least privilege scopes, and mandatory multi factor authentication for privileged actions.

Longer term fixes that prevent repeats

This type of incident is preventable with layered controls that are now considered baseline for mature engineering organizations:

• Automated secret scanning: Enable platform native scanning and pre-commit hooks to catch secrets before they leave a laptop.
• Token hygiene: Prefer fine grained, time boxed tokens with narrow scopes, plus automatic expiration.
• Protected branches and required reviews: Make it harder for a compromised credential to push changes into production paths.
• CI/CD hardening: Restrict who can edit workflows, lock down runners, and require approvals for sensitive environments.
• Centralized logging with long retention: Preserve Git events, identity events, and cloud control plane logs long enough to support investigations.
• Clear security reporting channels: A visible vulnerability disclosure path reduces the time between discovery and action.

What to watch next

The key unanswered question in exposures like this is whether any unauthorized party used the token before it was revoked. Even if no misuse is found, organizations often take the opportunity to tighten token policies, validate CI/CD trust boundaries, and improve how fast external researchers can reach the right internal team.

For defenders, the broader lesson is simple: treat secrets as high risk production assets. A leaked credential is not just an accident. It is a potential entry point into the software supply chain, and the speed of response often determines whether it stays a close call or becomes a headline breach.