GitHub says hackers stole data from thousands of internal repositories

GitHub says attackers stole data from roughly 3,800 internal repositories after compromising an employee device with a poisoned VS Code extension, according to TechCrunch. The company says it has no evidence so far that customer information stored outside those internal repositories was affected, but the investigation is still ongoing.

This matters because the incident hits one of the most trusted layers in modern software development. GitHub is not just another SaaS platform; it sits close to source code, developer workflows, automation pipelines, and security controls across the industry. When a breach starts with a malicious extension instead of a conventional server compromise, it also reinforces a harder truth for engineering teams: developer tooling has become part of the supply-chain attack surface.

GitHub said it detected and contained the compromise on an employee device and linked the intrusion to a poisoned extension for Visual Studio Code, the widely used code editor. The company did not identify the extension publicly in the initial disclosure. TechCrunch also reported that The Record and BleepingComputer attributed the attack to a group called TeamPCP, which has allegedly taken credit for the breach and is said to be offering the stolen data on a cybercrime forum.

The technical pattern is familiar even if the target is unusually high profile. Attackers have increasingly used software packages, plugins, and extensions as distribution points because they sit inside trusted workflows. If a malicious component reaches enough developers, the compromise can spread well beyond one company and into downstream projects, credentials, and cloud environments. GitHub itself noted that attacks on popular open-source projects and coding extensions are becoming a more common way to reach large numbers of systems at once.

The bigger implication is not only what may have been taken from GitHub, but what this says about security priorities for development organizations. Many teams already scan dependencies and container images, but extensions, local development environments, and employee devices still create blind spots. A compromise that begins at the editor layer can sidestep some of the controls companies put around production systems and central infrastructure.

For software teams, the practical lesson is to treat developer workstations and extensions as production-adjacent assets. That means stricter extension allowlists, better monitoring of endpoint behavior in engineering environments, faster review of unusual repository access, and more discipline around tokens and cloud credentials that may be exposed through local tooling. GitHub has said its investigation is continuing, so the full scope may still change. But even from the initial facts, this is already a reminder that the path into sensitive code often starts with the tools developers trust most.