Back to all incidents

Vodafone — Lapsus$ source-code dump after failed extortion

Lapsus$ dumped 7.1 GB of Vodafone internal source code after failed extortion; leaked repos contained hardcoded database credentials. Vodafone says no customer data affected.

Target
Vodafone — Lapsus$ source-code dump after failed extortion
Date public
12 May 2026
Sector
Telecoms
Attack type
Data Breach
Threat actor
Lapsus$
Severity
Medium
Region
United Kingdom

Lapsus$ — the extortion crew behind the Nvidia, Okta, Microsoft and Samsung breaches — added Vodafone to its leak site in late April 2026 and gave the company fifteen days to negotiate. Vodafone declined. On 12 May the group dumped roughly 7.1 GB of internal source code, most of it tied to two projects, OnePortal and Cyberhub. Vodafone says the intrusion happened back in March, that it came through "compromised third-party development software", and that no customer data was taken. That last reassurance is thinner than it sounds. Researchers reading the dump found working PostgreSQL database passwords hardcoded straight into the committed code. The database itself was not breached — but the keys to it were published to the internet. The story here is not that source code leaked. It is what organisations still leave sitting inside their source code.

What happened

Lapsus$ added Vodafone to its dark-web leak site in late April 2026, with a fifteen-day window for the company to open negotiations. On 12 May the deadline expired, the group posted the message “Time expired. Vodafone refused to pay. Data is now public,” and uploaded an archive of approximately 7.1 GB. The archive contained source code and test environments for several Vodafone applications, with a customer-facing platform labelled OnePortal and a project labelled Cyberhub the most prominent, alongside a manifest of the wider GitHub repository tree the attacker had been able to reach.

Vodafone’s public position is that no customer data was affected, that the intrusion itself occurred in March 2026, and that the access route was “compromised third-party development software” rather than its own infrastructure. The company declined to identify the specific tool, and independent researchers have suggested the more likely entry point was a compromised internal GitHub account. In Vodafone’s framing the breach is a contained, source-only exposure — an embarrassment rather than an incident with a blast radius.

That framing is where the interesting disagreement sits. Within a fortnight of the dump, researchers analysing the published archive flagged hardcoded PostgreSQL database credentials embedded in committed source files: working, standing passwords pointing at backend databases, sitting in code that was now on the public internet. Whether those specific credentials are still live is Vodafone’s validation problem. The material point for everyone else is that they existed in the repository at all.

How it worked

Lapsus$ has never been a group that relies on exotic technical exploits, and this incident is consistent with its catalogue against Nvidia, Okta, Microsoft and Samsung. The group’s initial access is human and identity-centric: social engineering of help desks, SIM swaps, purchased or phished credentials, MFA-fatigue prompts, and in some past cases the outright recruitment of insiders. The target of that access is not a production system directly but the developer ecosystem around it — the accounts, source-control tenants and CI pipelines where an enterprise keeps the code that describes how everything fits together. Once inside, the pattern is fixed: locate the internal source-code repositories, bulk-exfiltrate, attempt extortion, and publish on refusal to pay.

The mechanism that turns this from a leak into an exposure is what the code carried. A modern source repository is not just application logic; it is a detailed map of the estate — internal endpoint addresses, infrastructure topology, service-to-service authentication logic, and API design — and, far too often, live secrets. In Vodafone’s case the researchers’ finding was explicit: embedded PostgreSQL credentials in committed files. That converts a “source-only” incident into a set of directions and keys. The database was never touched during the breach. It did not need to be. The credentials that reach it were published in the dump, which is why the honest description of the event is deferred exposure rather than a contained one. An attacker who takes the source today can return through the front door of the database tomorrow, using credentials the victim handed over in the archive.

Timeline

  • March 2026 — Vodafone dates the underlying intrusion to this month, attributing access to “compromised third-party development software”; the specific tool is not named.
  • Late April 2026 — Lapsus$ lists Vodafone on its leak site with a fifteen-day negotiation window.
  • 12 May 2026 — deadline expires; Lapsus$ posts “Time expired… Data is now public” and uploads a ~7.1 GB archive of source and test environments (OnePortal, Cyberhub, and a repository-tree manifest).
  • Mid-to-late May 2026 — researchers analysing the dump flag hardcoded PostgreSQL credentials in committed code; Check Point’s threat-intelligence reporting notes the listing and dump.
  • As of writing — the compromised third-party tool remains unnamed, no customer-data exposure has been demonstrated, and no UK regulator has publicly opened a formal investigation.

What defenders should learn

The first lesson is to distrust the phrase “source code only, no customer data.” It sounds like containment and it is frequently the opposite. Source code with embedded credentials, internal endpoints and infrastructure detail is the route to the customer data, not an alternative to it. The Vodafone dump did not expose the database; it exposed the keys to the database and a map of where to use them. Any organisation reassuring itself that a code leak is low-impact should first go and check what its code actually contains.

The durable fix is an identity and pipeline problem, and this is where the Zero Trust lens goes — worth Andy expanding. You cannot guarantee that a repository will never leak, so the objective is to make a leaked repository worthless to an attacker. That means secrets scanning enforced on every commit rather than run occasionally, short-lived workload identities in place of long-lived database passwords, no standing developer access to production-grade credentials, and credential rotation treated as a reflex rather than an incident-only event. The principle is the same one that governs network segmentation: assume the boundary will be crossed, and make sure that crossing it does not hand over a working credential. A repo should be able to leak in full and still not authenticate anyone to anything.

Finally, the actor lesson. Lapsus$ has run essentially the same playbook since 2022 — identity-led access to a developer-adjacent account, locate the source, exfiltrate, extort, dump — because it keeps working against large enterprises with sprawling internal source estates and patchy secret-management discipline. The defensive response has not changed either; it has simply not been enforced widely. The unromantic, immediately executable action for anyone with a private GitHub or GitLab estate is to run a fresh secrets scan across the whole history and see what falls out, then rotate whatever does. Vodafone is a reminder that the recommendation everyone has heard for years is still, in most places, un-done.

Sources

Back to all incidents