The GitHub Breach, and What It Means If You Build Software for Clients

What happened

On 20 May 2026, GitHub confirmed unauthorised access to its internal repositories. Reporting put the volume at roughly 3,800 to 4,000 private repositories containing platform source code, internal tools and organisational data. A threat actor subsequently advertised the material on underground forums.

The initial access vector is the part worth dwelling on. It was a compromised employee device, infected via a malicious Visual Studio Code extension. From that one laptop, the attacker moved into internal systems and exfiltrated thousands of private repositories.

The extension in question had been published using a contributor token stolen weeks earlier in a separate incident, and was live on the marketplace for a matter of minutes.

The wider pattern in 2026

This was not isolated. The year has been defined by attacks on the tools developers trust implicitly:

• A campaign published 84 malicious versions across 42 packages in one ecosystem via the project's own legitimate CI, in roughly six minutes.
• A separate campaign pushed 5,718 malicious commits into 5,561 GitHub repositories in six hours, disguised as automated contributions. Later analysis attributed over a third of affected accounts directly to infostealer-infected developer workstations.
• OpenAI confirmed two employee devices were affected by compromised packages, with limited access to internal repositories.

The consistent theme, as one analysis put it, is that attackers are not exploiting flaws in package registries. They are taking over maintainer accounts, then publishing through entirely legitimate channels. The malicious package is signed with a valid key by an authenticated account over HTTPS. Perimeter defences and signature checks do not help.

Why this is a different problem for an agency

If you build software for other people, your risk profile is not the same as a product company's.

A software house with twenty clients holds twenty sets of production credentials, twenty codebases, and in many cases deployment access to twenty live environments. Compromising you is dramatically more efficient than compromising any one of your clients.

That is why agencies get targeted, and it is why your clients have started sending security questionnaires. The question on those questionnaires is not really about the software you build. It is about the environment you build it in.

The findings we actually see at agencies

• Secrets in git history. API keys and cloud credentials committed years ago, still valid, because rotating them is permanently somebody's someday task. Anything ever committed should be treated as disclosed, and secret scanning across full history usually finds more than people expect.
• Developer workstations as the weak point. The 2026 campaigns confirm it. An infostealer on one laptop reaches everything that laptop can reach, which at an agency is a great deal.
• Shared credentials for client environments, so no action can be attributed to a person.
• Long-lived CI/CD tokens with more scope than the pipeline needs.
• Former staff with live access to client repositories and cloud accounts.

What to actually do

1. Scan full git history for secrets, not just the current tree. Then rotate what you find rather than deleting the commit and hoping.
2. Lock down extensions and dependencies. Pin versions, review what developers install, and treat the editor as part of your attack surface, because 2026 established that it is.
3. Short-lived, least-privilege CI credentials. A token that never expires and can deploy anywhere is an incident waiting for a trigger.
4. Separate client environments properly. If one client's credentials are compromised, work out honestly what else that reaches.
5. Offboard the same day, across every client system, not just your own.
6. Test the applications you ship, particularly authorisation. Broken object-level authorisation, where the interface enforces access but the API does not, remains the most common serious finding in web application and API testing.

The commercial angle worth planning for

Client security questionnaires are going to keep arriving, and they will increasingly ask about your environment rather than your product. It is worth deciding now whether you absorb that cost, refer it, or pass it through at margin.

Scrambling to arrange testing two weeks before a go-live never goes well, and the version arranged under that pressure is rarely the version that satisfies the reviewer.

More on how we work with development firms on our software development page, and for product companies specifically, SaaS providers. If a client contract is what is driving this, testing for client contracts covers what usually satisfies the requirement.

Common questions