One Stolen Employee Login Opened Meta’s GitHub Repositories: Questions and Answers on What Was Taken

Meta has confirmed that hackers got into part of its code-hosting setup on GitHub, and the cause was not an exotic exploit. It was one employee’s stolen login. Here are the key questions, answered from what the company has said publicly.

Meta’s statements were first reported by Eduard Kovacs at SecurityWeek; Cybernews also covered the notifications.

What happened?

An outside group accessed some of Meta’s GitHub repositories using credentials stolen from a Meta employee. Meta detected the intrusion a few weeks ago, shut off the attackers’ access, and brought in GitHub and law enforcement. Notification letters to affected people began going out on Tuesday, October 13.

What did the attackers take?

Mostly code. Meta told SecurityWeek that 99% of what was taken was business data, in the form of software code related to some of its products. The other 1% was personal data affecting roughly 1,500 people, most of them Meta employees in the United States.

Why was personal data in a code repository at all?

It should not have been. Meta says the personal information was added to the repositories by mistake, against company policy. It also says a significant portion of what looked like personal data was actually synthetic or anonymized test data, which may make it hard for the attackers to tell real records from fake ones.

What kinds of personal information were involved?

Meta has not said. Reporting so far also does not say who the attackers were, how the employee’s credentials were stolen, how many repositories were accessed, or when the intrusion began.

Were Meta’s products or users affected?

Meta says no. A spokesperson told SecurityWeek the incident “was not a vulnerability in any Meta product” and that the company’s internal systems were not breached. Based on its work with GitHub so far, Meta also does not believe the attackers were specifically targeting its data.

What is Meta doing about it?

Rotating secrets, such as keys and passwords, that it found in the affected repositories.
Adding controls to stop user data from being stored on GitHub, plus proactive scanning as a second line of defense to catch data uploaded by mistake.
Working with GitHub on extra protections for its repositories, and hardening product security against risks from the exposed business data.
Notifying regulators and offering affected people credit and dark web monitoring.

What this means for your company

You do not need to be Meta for this to apply. If your business, or a developer you hire, keeps code in GitHub, GitLab, Bitbucket or a similar service, three lessons stand out:

Protect developer accounts like admin accounts. Require multi-factor authentication for everyone with repository access, and remove access as soon as someone leaves or a contract ends.
Keep secrets and real customer data out of code. Passwords, API keys and spreadsheets of customer records have a way of ending up in repositories. Use a proper secrets store and test data instead, and turn on the secret-scanning features most platforms now offer.
Know what is in your repositories. If you could not say today whether personal data is sitting in your code storage, a short review is worth the time, because that is what decides whether a code leak becomes a reportable data breach.

Need help reviewing who can reach your code and what is stored there? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.