Hackers reached several of Meta’s private repositories on GitHub and took the records of about 1,500 people, together with source code for a number of the company’s products. Meta says its internal systems and networks were not entered.
How they got in
Not through a flaw in any Meta product. The company says an outside group used one employee’s stolen login to open repositories Meta keeps on GitHub, the platform where developers store source code and work on projects together. The breach was identified a few weeks ago, and formal notification of the people affected began on Tuesday. Most of them are Meta staff working in the United States.
What was taken
Meta told the security publication SecurityWeek that roughly 99 per cent of the stolen material is business information and product source code. The remaining 1 per cent is personal data. A significant share of that, the company says, is synthetic or anonymised test data — the sort developers generate to exercise software — and it believes real and test records sitting side by side will make it harder for an attacker to tell which is which.
Meta adds that a preliminary investigation conducted with GitHub found no indication the attackers set out specifically to steal Meta’s data. That is worth reading carefully: it suggests opportunism rather than a targeted operation, which is both reassuring about intent and unsettling about exposure.
The admission inside the statement
The most useful sentence in Meta’s account is not about the attacker at all. Personal data was not supposed to be on GitHub. It ended up in several repositories by mistake, which the company itself describes as a violation of its internal security policy.
That is the ordinary failure underneath an extraordinary-sounding headline. A repository is where code lives, and code needs data to be tested against. Somewhere along the way a developer reached for real records instead of generated ones, or a fixture file that began as test data acquired real rows, and nobody caught it before the commit. The attacker did not need to defeat Meta’s defences to find it; they needed one password and the patience to look.
What Meta is doing about it
Access was cut as soon as the breach was identified. Meta is working with GitHub’s security team, with regulators and with law enforcement. The people affected are being offered free credit monitoring and dark-web monitoring, services that look for signs a person’s details are being traded or misused. Secrets and access credentials tied to those repositories have been rotated, new controls added to stop personal data being stored on GitHub in future, and further hardening agreed with GitHub itself.
What a Dhaka software firm should take from this
Almost every development shop in Bangladesh keeps client code on GitHub, and a great many freelancers keep their portfolio work there too. The lesson is not that GitHub is unsafe. It is that a repository is only as private as the weakest account that can read it, and that what ends up inside one is rarely audited by anybody.
Four things cost nothing and close most of this. Turn on two-factor authentication or passkeys for every account with repository access, and make it mandatory at organisation level rather than hoping. Use GitHub’s secret scanning and push protection, which refuse a commit containing something shaped like an API key. Rotate personal access tokens on a schedule and delete the ones belonging to people who have left — that is the account a stolen password usually turns out to be. And treat test fixtures as production data: a file of real NID numbers, phone numbers or customer addresses is a breach waiting to be committed, whatever the folder is called.
Related: Japan’s cyberspace state of emergency.
