GitHub incident shows how poisoned developer tools can expose code

GitHub disclosed on May 20, 2026 that an unauthorized access incident involving GitHub-owned repositories took place after it detected and contained a compromised employee device on May 18. It was reported that this attack was linked to the activity by the group PCP.

GitHub disclosed on May 20, 2026, an unauthorized access incident involving GitHub-owned repositories after it detected and contained a compromised employee device on May 18. WIRED linked the incident, along with the TanStack npm compromise, to TeamPCP’s wider software supply-chain campaign. The shared concern is the path attackers used: trusted developer tools became an entry point into larger organizations.

What happened

The company linked the incident to a malicious third-party VS Code extension, removed the affected extension version, isolated the endpoint, rotated critical secrets, and began incident response. GitHub said its current assessment found exfiltration of internal repositories only, with attacker claims of about 3,800 repositories directionally consistent with its investigation. The investigation found no evidence (so far) of impact to customer-owned enterprises, organizations, or repositories.

WIRED attributed the activity to TeamPCP, describing the GitHub incident as part of a wider software supply-chain campaign in which malicious code was inserted into developer tools and open-source packages. The broader campaign also overlaps with TanStack’s May 11 npm compromise.

Going deeper

In the TanStack case, the compromise began inside the software release process, where an attacker used GitHub Actions cache poisoning and OIDC token extraction to publish 84 malicious versions across 42 @tanstack packages to npm between 19:20 and 19:26 UTC on May 11, 2026. The connection between cases relates to a shared campaign pattern with developer machines, CI/CD workflows, package managers, extensions, and trusted open-source dependencies, showing that all of these tools could be used as entry points.

OpenAI’s response to the TanStack attack reveals the downstream risk, with two employee devices affected in its corporate environment. OpenAI said it found no evidence of customer-data access, production-system compromise, intellectual-property compromise, or altered software.

What was said

According to the Github disclosure of the event, “Our current assessment is that the activity involved exfiltration of GitHub-internal repositories only. The attacker’s current claims of ~3,800 repositories are directionally consistent with our investigation so far.”

Why it matters

TanStack’s postmortem shows the same broader risk pattern as an attacker used GitHub Actions cache poisoning and OIDC token extraction to publish 84 malicious versions across 42 @tanstack packages on May 11, with the malware designed to harvest credentials from developer and CI environments. WIRED linked both incidents to TeamPCP’s wider supply-chain campaign, where developer tools become a path into other organizations.

A software supply chain study explains why these incidents are so difficult to contain: “attackers require finding single weaknesses, while defenders need to cover the whole attack surface.” One trusted package, extension, or build workflow can expose credentials, internal code, vendor connections, and downstream systems before security teams see a traditional perimeter breach.

See also: HIPAA Compliant Email: The Definitive Guide (2026 Update)

FAQs

What is cache poisoning?

Cache poisoning happens when an attacker manipulates a stored version of data, code, or files so a trusted system later uses the attacker’s version.

What is OIDC?

OIDC stands for OpenID Connect. It is an identity layer used to help systems prove who they are without relying on long-lived passwords or static credentials.

What is OIDC token extraction?

OIDC token extraction happens when an attacker steals an OIDC token from a system or workflow. A token works like a temporary digital pass.