GitHub Hacked

What You Will Learn

• What GitHub confirmed about the compromised employee device and internal repositories.
• How the poisoned Nx Console 18.95.0 extension became the reported entry point.
• Why CVE-2026-48027 replaces the old CVE and severity claims.
• How developers can use official guidance to investigate and reduce supply chain risk.

What GitHub Confirmed About the Breach

GitHub’s own security update is the starting point for this story. In a post by CISO Alexis Wales, GitHub said it detected and contained a compromise of an employee device on May 18, 2026. The device involved a poisoned Visual Studio Code extension published by a third party. GitHub said it removed the malicious extension version, isolated the endpoint, and began incident response.

GitHub’s current assessment was that the activity involved exfiltration of GitHub internal repositories only. The company said the attacker’s claim of about 3,800 repositories was directionally consistent with its investigation. That wording matters. It confirms the scale under investigation without pretending that every detail of the incident was already final.

GitHub also said it had no evidence of impact to customer information stored outside its internal repositories at the time of the update. It noted that some internal repositories can contain customer information, such as excerpts of support interactions. The statement therefore narrows the known scope while leaving room for further findings as the investigation proceeds.

The security update also warned that the investigation was ongoing. This article keeps that status visible because a breach report can change as forensic review, secret rotation, and repository analysis continue. The Canadian Cyber Centre alert records the incident for IT teams and managers.

How the Poisoned Extension Became the Entry Point

The compromised software was Nx Console, a Visual Studio Code extension used to manage Nx and Lerna projects. BleepingComputer reported that GitHub later identified a malicious version of Nx Console as the path into the employee device. The Canadian Centre for Cyber Security gave the same version, 18.95.0, in its alert about the incident.

The reported path was a software supply chain compromise rather than a direct attack on GitHub’s public service. A developer tool received a malicious build. The build reached a developer environment. Credentials and other secrets available from that environment could then be used to reach code and infrastructure. This model is dangerous because the trusted tool sits inside a workflow that already has permission to do useful work.

According to BleepingComputer’s account of GitHub and Nx statements, the malicious version was available on the Visual Studio Marketplace for about 18 minutes. The same report said it remained available on OpenVSX for about 36 minutes. The NVD record gives a more precise Marketplace interval of about 12:30 UTC to 12:48 UTC on May 19 and an OpenVSX interval of about 12:33 UTC to 13:09 UTC.

The public figures describe exposure time, not the number of people compromised. BleepingComputer reported low download counts for the affected version in Microsoft and OpenVSX data and later analytics of about 6,000 activations from Visual Studio Code. Those figures should not be converted into a claim that all users were breached. Organizations still need to check their own extension inventory and logs.

What Nx Console 18.95.0 Means for Developers

The affected version is the detail that turns a headline into an investigation task. The Canadian Centre recommended removing Nx Console 18.95.0 from affected environments and moving to a known-good version such as 18.94.0 or 18.96.0 and later. CISA’s bulletin separately lists CVE-2026-48027 in the Known Exploited Vulnerabilities catalog. The NVD record says Nx Console 18.100.0 is not compromised. Teams should follow the version guidance in the current vendor and government advisories rather than rely on an old article or a cached package.

Do not install a replacement extension into a machine that has not been assessed. If the malicious version was present, the developer workstation may have exposed GitHub tokens, package registry credentials, cloud credentials, SSH keys, or other secrets available to local processes. The correct response depends on the organization’s incident plan, the machine’s role, and the permissions attached to the accounts.

For a broader explanation of how developer tools connect to AI and automation risk, read the site’s multimodal systems analysis. The technical category is different, but the data boundary is similar. A trusted interface can expose more than the user expects when it is granted access to source code, credentials, and build tools.

The 3,800-Repository Scope

The figure of about 3,800 internal repositories came from the public incident record and was repeated by the Canadian Cyber Centre and BleepingComputer. GitHub said the attacker’s claim was directionally consistent with its assessment. The repositories were described as internal GitHub code and configuration material, not as a confirmed dump of every public repository or every customer organization on the platform.

GitHub said some internal repositories include information from customers, such as support excerpts. That is a reason for customers to take the notice seriously, but it is not the same as a finding that customer repositories outside GitHub’s internal environment were compromised. The article keeps the distinction between internal material and customer-hosted data.

The scope also explains why GitHub rotated critical secrets quickly. A repository can contain source code, deployment configuration, test fixtures, internal documentation, workflow definitions, or references to credentials. Removing a file after the fact may not be enough if a secret was visible in history, build logs, memory, or a local environment. Secret rotation and audit work must follow the access path.

Readers comparing this case with the site’s AI model security guide should focus on permissions rather than model labels. The risk came from a development tool with access to a working environment.

What TeamPCP Attribution Means

TeamPCP appears in the reporting, but attribution needs a qualifier. BleepingComputer reported that TeamPCP claimed access to about 4,000 private repositories on a criminal forum and sought payment for the data. The same report said GitHub had not attributed the incident to a specific threat actor at that point.

A criminal group’s claim is evidence of a public claim, not proof that the group performed every action in the intrusion. Threat researchers can compare infrastructure, code, credentials, and past campaigns, but the confidence level should be stated. The old article treated attribution as settled and added victims and technical details that were not established by GitHub’s official update.

The Canadian Cyber Centre described the incident without assigning it to TeamPCP. That government alert is more useful for defensive action than for naming a perpetrator. It advises organizations to look for unauthorized repository access, suspicious cloning, changes to authentication or access control, unauthorized pushes, orphan commits, and activity from bot or service accounts after May 18.

The Correct CVE and Severity

The old article used CVE-2026-45321 and a CVSS score of 9.6. Those identifiers are not supported by the authoritative records retrieved for this incident. CISA identified the malicious Nx Console version under CVE-2026-48027 and listed it in the Known Exploited Vulnerabilities catalog.

The NVD record for CVE-2026-48027 describes Nx Console 18.95.0 as containing malicious code. It gives a CVSS 4.0 score of 9.3 from the GitHub CNA and displays a CVSS 3.1 base score of 9.8. Both are rated Critical. The score format and source should be written next to the number because CVSS versions are not interchangeable.

The NVD record also records the short publication window and says version 18.100.0 is not compromised. The CISA and Canadian guidance gives additional known-good version advice. Version checks should be made against the current Nx and GitHub advisories before remediation is closed.

The site’s physical AI coverage discusses another class of technology risk. This incident shows the same editorial rule in a security context. A precise identifier is more useful than a dramatic but incorrect severity claim.

What Was and Was Not Affected

The public record supports a compromised employee device, internal repository exfiltration, and a malicious extension. It does not support a claim that GitHub’s entire platform was taken over or that every user account was exposed. GitHub said it had no evidence of impact to customer information stored outside its internal repositories in the official update.

The incident also should not be expanded into a confirmed list of OpenAI, Mistral AI, or European Commission victims. BleepingComputer reported broader TeamPCP activity involving packages and projects, while the Canadian alert focused on GitHub internal repositories. The old article’s list of organizations went beyond what the retrieved official incident record established.

Separate campaigns can share infrastructure, code, or a threat actor without being one incident. CISA’s bulletin discussed the GitHub compromise and a separate Megalodon campaign. The distinction matters because the indicators, affected repositories, and response actions may differ.

The site’s article on small reasoning models is not evidence about this breach. Internal linking provides context for readers, but it cannot replace an incident advisory.

Why a Short Extension Window Still Mattered

The malicious extension was reported to be available for about 18 minutes in the Visual Studio Marketplace and about 36 minutes in OpenVSX. A short window can still matter when a package is delivered through an automatic update path or when a developer environment has broad access to source code and credentials.

Time online is only one risk variable. The other variables include who received the package, whether the extension activated automatically, what permissions the developer had, what credentials were present, and how quickly the organization detected unusual access. A package can be available briefly and still create a long investigation if tokens must be revoked across many systems.

This is why CISA recommends pinning trusted package versions and waiting before pulling a new package. The advice is not a promise that a delay prevents every attack. It gives maintainers and security teams time to identify a suspicious release before it reaches more environments.

What CISA and the Canadian Cyber Centre Recommend

The government advisories turn the incident into a checklist for defenders. CISA recommends forensic review of CI/CD logs, cloud audit trails, and affected developer machines. It also recommends revoking and rotating secrets that were accessible to pipelines or developer systems, including cloud credentials, SSH keys, package tokens, and platform tokens.

The Canadian Cyber Centre recommends removing Nx Console 18.95.0, moving to a known-good version, reviewing logs for unexpected cloning and unauthorized pushes, and disabling IDE extension auto-updates in high-security environments. It also points organizations toward an allowlist of approved developer tools and broader security actions such as patching and hardening systems.

What Developers Should Do After Exposure

Start with the official advisory and your organization’s incident process. Do not treat a version check as the only remediation. If Nx Console 18.95.0 was present on a machine with access to company repositories or cloud services, isolate the machine according to the security team’s instructions and preserve logs before making changes that could destroy evidence.

Rotate credentials from a trusted administrative environment. The rotation list should reflect what the developer machine and its build tools could access. That can include GitHub tokens, SSH keys, package registry tokens, cloud credentials, container credentials, and secrets stored in environment files or CI systems. Revoke old tokens instead of only generating replacements.

Review access logs for the period around May 18 and after. Look for unexpected repository cloning, new keys, privilege changes, workflow edits, orphan commits, and activity from accounts that normally perform automated work. The Canadian Cyber Centre specifically calls out bot and service-account activity in its alert.

For teams building computer-use or code-generating tools, the site’s AI workflow coverage provides broader context. The security rule is direct. Give automation the minimum credentials it needs, log its actions, and make revocation fast.

The Separate Megalodon Campaign

CISA’s May 28 bulletin discussed another campaign called Megalodon. It described malicious GitHub Actions workflows that harvested CI/CD secrets, cloud credentials, and tokens from public repositories. That campaign is related to the same broad developer ecosystem, but it is not identical to the Nx Console incident.

The distinction prevents response confusion. For the Nx Console event, the initial path was a poisoned extension and compromised employee device. For Megalodon, CISA described injected workflow files and suspicious automated activity. A defender may need to check both paths, but the indicators and search queries are different.

Do not merge the old article’s claims about 5,500 repositories or a second worm into the GitHub breach unless a current official advisory supports the exact number and relationship. Incident response works better when each campaign has its own timeline, indicators, affected assets, and confidence level.

How to Read the GitHub Hacked Story

The corrected account is serious without the unsupported claims. GitHub confirmed that an employee device was compromised through a poisoned third-party VS Code extension and that about 3,800 internal repositories were involved in the investigation. GitHub isolated the endpoint, rotated critical secrets, and continued forensic work. CISA and the Canadian Cyber Centre published defensive guidance.

The correct vulnerability record is CVE-2026-48027. NVD lists Critical scores of 9.3 under CVSS 4.0 from the GitHub CNA and 9.8 under CVSS 3.1. The old CVE-2026-45321 and CVSS 9.6 claims have been removed. TeamPCP remains a qualified attribution because public reporting described the group’s claim while GitHub had not assigned the incident to a specific actor in the cited report.

The main lesson is about trust boundaries. A developer extension can be part of the software supply chain, the local credential store, and the path to production systems at the same time. Organizations reduce the blast radius by approving extensions, pinning versions, limiting tokens, auditing CI/CD activity, rotating secrets quickly, and keeping a tested recovery process.