Meta says 1% of the data taken from GitHub was personal, notifies about 1,500 people, and names no data types

One per cent of what? A share of data, a count of people, and no unit between them

Meta says 99 per cent of the data taken from its GitHub repositories was business data, in the form of software code for some of its products, and 1 per cent was personal data. It is notifying roughly 1,500 people. Those two figures describe different things. The 1 per cent is a share of data. The 1,500 is a count of people. SecurityWeek, which reported both on 13 October 2026, gives no unit for the data (bytes, files, records, lines or repositories). So the share cannot be turned into a number of people, and the number of people cannot be turned into an amount of data (derived).

The second figure that can be computed is the gap. SecurityWeek says the intrusion "was detected a few weeks ago" and that notifications "started going out on Tuesday", which was 13 October. "A few weeks" is not defined. Read as two to six weeks, it is 14 to 42 days (derived), which puts detection between 1 and 29 September 2026. The limit in UK GDPR Article 33 is 72 hours, three days, so the gap is between 4.7 and 14 times as long (derived). That comparison proves nothing about Meta, for reasons set out below: the 72 hours runs to a regulator, not to the people affected, and it starts when a controller is aware of a personal data breach, not when it first sees an intrusion.

What is the record? Every figure and every Meta statement in this briefing comes from one article, SecurityWeek's, which quotes and paraphrases what Meta told it. No Meta statement page, notification letter or regulator filing could be found, and other outlets that carried the story repeat SecurityWeek. Meta is a company managing its own notification, its regulators and its reputation, and it decides which facts to give. Each sentence about Meta below is therefore attributed to Meta by way of SecurityWeek, not verified.

So the finding is narrow. By Meta's account, an outside group used one employee's stolen credentials to take software code, and some personal data that company policy said should not have been in the repositories. The record is silent on almost everything a defender would ask next. The next section sets out what it does and does not say, line by line.

Stated and not stated: the record, line by line

The table sets what Meta is reported to have said against what SecurityWeek's article does not state. "Not stated" means not found in the article, read in full, or in any other report found. It does not mean the information does not exist.

What Meta is reported to have said (SecurityWeek, 13 October 2026), and what no source found states. Meta's words are quoted only where the exact wording matters.

The question	Stated (Meta, via SecurityWeek)	Not stated
Who did it?	"An outside group". Based on its investigation with GitHub so far, Meta does not believe the hackers were specifically after its data.	Any name, alias or motive beyond that belief, and any claim by the group.
How were the credentials stolen?	"An employee's stolen credentials": one employee, as worded.	How, when, from which device, and what kind of credential: a password, a token, a key or a session.
Was there MFA or SSO?	Nothing.	Whether multi-factor authentication or single sign-on applied to the account or the repositories, or was bypassed.
How many repositories?	"Some of the company's GitHub repositories" (SecurityWeek). The spokesperson's two quoted sentences say "a GitHub repository" once and "the repositories" once.	A count, names, or which were private or internal.
Which products' code?	"Software code related to some of its products".	Which products, how much code, and how recent.
What personal data?	A small amount, for a limited number of people, most of them Meta employees. About 1,500 notified, most of them employees in the US. Added to the repositories by mistake, against policy.	The types, the number of records, and how many of the 1,500 are not employees or not in the US.
Real or test?	A significant portion of what looked like personal data was "synthetic or anonymized test data", so the attackers may not readily tell it from real records.	What share was real, how the data was anonymised, and whether the 1,500 counts only people in real records.
What is the 1%?	99% of the data taken was business data; the remaining 1% was personal data.	Whether the share is by bytes, files, records, lines or repositories, and the size of the total.
How long was access?	Detected "a few weeks ago" (SecurityWeek's wording). Meta's security team shut access down and brought in GitHub and law enforcement.	When access began, how long it lasted, the date of detection, and how many times data was copied.
What about secrets?	Meta "rotated secrets found in the repositories".	Which secrets and how many, whether live when taken beyond the word rotated, and whether any were missed or belonged to third parties.
Is there a downstream risk from the code?	Meta hardened its product security "to address risks stemming from access to its business data" (SecurityWeek's wording).	What the risk is, which products, and whether the code reveals weaknesses.
Regulators and people?	Regulators are being notified. Credit and dark web monitoring is offered. Notifications began on Tuesday 13 October.	Which regulators, when each was told, which countries' residents are among the 1,500, and any UK count.

Two gaps matter more than the rest. The first is the unit of the 1 per cent, taken up next. The second is the credential: whether it was a password, a token or a key decides which controls could have stopped it, and the record does not say. A third deserves a line. "Rotated secrets found in the repositories" describes a set of secrets that Meta found. It is not a statement that every secret in the code was found, and no count is given.

The 1% is a share of data, not a headcount

Take Meta's two claims at face value and try to join them. If all of the 1 per cent is data about those 1,500 people, and the percentage is by volume, the total taken is 100 times the volume of their data. That volume depends on what was in the repositories, and nothing in the record says. The table shows how far apart the answers are for three assumed sizes. The sizes are assumptions for illustration, not findings.

Illustrative arithmetic (derived): 1,500 people times an assumed size of personal data per person, then times 100. The sizes are assumptions and come from no source.

Assumed personal data per person	Their data, 1,500 people	Total taken if that is 1%
1 kilobyte (a short record)	1.5 megabytes	150 megabytes
100 kilobytes (a document or a spreadsheet's worth)	150 megabytes	15 gigabytes
10 megabytes (an export or an attachment)	15 gigabytes	1.5 terabytes

The same two statements are consistent with totals that differ by a factor of 10,000 (derived: 1.5 terabytes over 150 megabytes). Change the unit and the answer changes again: one repository in a hundred is 1 per cent by count whatever its size. The caveat Meta itself supplies adds another unknown. If the 1 per cent includes the look-alike test data, the real personal-data share is below 1 per cent, and Meta has not said whether the 1,500 counts only people found in real records.

The people count has its own arithmetic. SecurityWeek says most of the 1,500 are employees in the US. "Most" means more than half, so at least 751 are US employees and up to 749 are not (derived). The spokesperson's sentence says most were Meta employees, without the US.

One more word needs separating. Meta says the test data was "synthetic or anonymized". Synthetic data is invented. Anonymised data is derived from real records with identifying details removed. They carry different risks, Meta has not said which it was, and it has not said how any removal was done. There is also a point of reasoning, this briefing's and not Meta's: the indistinguishability that Meta says may confuse the attackers is the same indistinguishability that confuses a company's own scanners and breach triage. Test data that looks real has to be treated as real until someone proves otherwise, and that costs time at exactly the moment a notification clock is running.

A few weeks: 14 to 42 days, and a 72-hour clock that runs to a different person

SecurityWeek's article went up on Tuesday 13 October 2026, the day it says notifications began. Counting back from that date gives the table. The readings are this briefing's, because the article gives no figure. The last column is the gap measured in units of the 72 hours that Article 33 allows between awareness and telling the regulator.

Readings of "a few weeks ago" counted back from Tuesday 13 October 2026 (derived). The phrase is SecurityWeek's and is undefined; the readings are this briefing's, not Meta's.

Reading of a few weeks	Days before 13 October	Detection date (derived)	Times 72 hours
2 weeks	14	Tuesday 29 September	4.7
3 weeks	21	Tuesday 22 September	7.0
4 weeks	28	Tuesday 15 September	9.3
5 weeks	35	Tuesday 8 September	11.7
6 weeks	42	Tuesday 1 September	14.0

What the gap does not show is a breach of any deadline. Article 33 starts its 72 hours when the controller "becomes aware" of a personal data breach, and it runs to the regulator, not to the public. The ICO's guide says individuals must be told "without undue delay" where the risk is high, which is a separate and unquantified test. The guidance the ICO points to on awareness, the Article 29 Working Party's breach notification guidelines, which the ICO says remain relevant, says a controller is aware once it has a reasonable degree of certainty that an incident has led to personal data being compromised. It allows a short period of investigation first, expects that investigation to start as soon as possible, and says the preliminary steps should in most cases finish soon after the initial alert. The same point is made in an earlier briefing on the clock that runs to the regulator.

Meta's own account is a case where finding out whether the 1 per cent was real data would have been hard, since it says a significant portion of what looked like personal data was test data. Whether Meta treated detection, a later day or the notification as the moment of awareness is not stated, and neither is when any regulator was told. Meta also brought in law enforcement. Maine's attorney general's breach page, as read, says an entity pursuing a criminal investigation should consult law enforcement so that notice does not interfere, and then notify within 7 days of clearance. Whether anything like that applied here is not stated.

The honest use of the range is as a planning input, not an accusation. A few weeks separated detection from the first letter, in a case where only a small share of the data was personal. If your own process cannot produce a first regulator notification inside three days of awareness, with the facts you have and the gaps labelled, the process is the finding.

Four friendly names and the systems they describe

Meta's statements use labels that sound like findings. The table asks of each what system it is about and what it leaves open.

Meta's phrases as relayed by SecurityWeek (13 October 2026), what each describes, and what it leaves open. The last column is this briefing's reading.

Meta's phrase	What it describes	What it leaves open
"business data", "in the form of software code"	99% of the data taken, by Meta's count.	Code is not a neutral category. The same repositories held secrets Meta had to rotate and personal data policy barred. Which products and what the code reveals: not stated.
"not a vulnerability in any Meta product"	Products.	The failure described is access with a stolen credential to a repository, not a product flaw. The sentence is true of a different system from the one that failed, and it does not say the access controls worked.
"internal systems were not breached"	Meta's internal systems.	Whether Meta counts the GitHub repositories as internal systems is not stated. The spokesperson's next words are that business data "held in a GitHub repository was improperly accessed".
"synthetic or anonymized test data"	A significant portion of what looked like personal data.	Two different things under one label. The real share, and the method of anonymisation, are not stated.

Nothing in the record shows either of the first two sentences to be false, and neither claims the repositories were secure. A reader who skims them may conclude that nothing important failed. Something did: one employee's credential let an outside group take code and data it should not have had, from repositories that held personal data against policy and secrets Meta later rotated. The same article says Meta hardened its product security because of access to the code. That reads as a recognition (inference) that code in outside hands is a risk to products, and it sits beside "not a vulnerability in any Meta product" without contradicting it: exposure can raise risk without being a flaw. Which products, and which risk, are not stated.

The method is the same for any vendor. Attribute the statement, check what system it is about, and list what it leaves out. GitHub is in the same position about its own documentation, below: several of the controls it describes need a particular plan or licence (Enterprise Cloud for single sign-on, Secret Protection for push protection), so it has a commercial interest in their adoption, and the documentation is read here as documentation, not as an assessment.

What GitHub documents, and what that leaves open

GitHub's pages, read on 14 October 2026, describe the controls a defender would reach for in a case like this. Whether Meta used any of them is not stated. The table is about the controls, not about Meta.

GitHub documentation as read on 14 October 2026, against what the Meta record says. Cells are condensed; wording that matters is quoted.

Control	GitHub's documentation, as read	In the Meta record
Secret scanning	Scans the whole Git history on all branches for hardcoded credentials such as API keys, passwords and tokens. Advice on an alert: rotate the credential first; rewriting history may not be warranted.	Meta "rotated secrets found in the repositories". Whether scanning ran before the intrusion: not stated.
Push protection	Blocks a push containing a detected secret. For repositories it is off by default. By default anyone with write access can bypass it by giving a reason; "It's used in tests" is one, and it creates a closed alert.	Not stated. Meta says it is adding scanning for user data uploaded by mistake.
Personal data in code	The pages read describe detection of credentials, and custom patterns the owner defines for organisation-specific secrets. None describes a built-in check for personal records.	Meta says it implemented controls to stop user data being stored in GitHub.
SAML single sign-on	Needs Enterprise Cloud. Enabled but not enforced, members can still reach the organisation's resources before authenticating. Enforced, members who have not authenticated are removed. Command line and API access use a token or SSH key authorised for SSO.	Whether SSO existed or was enforced: not stated.
Two-factor authentication	An organisation can require it for all members, and can allow only passkeys, security keys, authenticator apps and the mobile app, which excludes SMS.	Not stated.
Personal access tokens	Classic and fine-grained tokens are both enabled by default. Classic tokens have no expiry requirement. An organisation can restrict them or set maximum lifetimes.	The kind of credential: not stated.
IP allow list	By default authorised users can reach resources from any IP address. An allow list also covers tokens and SSH keys, but needs Enterprise Cloud.	Not stated.
Audit log	Events for the last 180 days. Git events such as clone and fetch are not in the web interface; for Enterprise Cloud the page says they are available through the REST API only, with 7-day retention, or by streaming or export.	How long access lasted and what was cloned cannot be read from the record. Whether events were streamed: not stated.

The documentation also shows where a policy stops being a control. Meta says storing user data in GitHub "went against company policy" (SecurityWeek's words). A policy that says do not is not a block. GitHub's own push protection offers a bypass reason, "used in tests", that closes the alert, and the pages read describe credential detection, not personal-record detection. An earlier briefing on working credentials in public GitHub code and another on secret leak rates in commits cover the credential side at scale.

The UK reading: Articles 5, 25, 32, 33 and 34, the NCSC pages and Cyber Essentials

Nothing in the record says a UK resident is among the 1,500, and SecurityWeek says most are employees in the US. This section is about what a UK organisation should take from the case for its own repositories. Everything below is as read from the pages named.

UK sources read on 14 October 2026 and what they say about a repository holding code, secrets and personal data. The last column is this briefing's reading.

Source, as read	What it says	What it means for repositories
UK GDPR Article 5(1)(c) and Article 25(2)	Personal data must be adequate, relevant and limited to what is necessary. Controllers must ensure by default that only data necessary for each purpose is processed, covering the amount collected, the extent of processing, the period of storage and its accessibility.	A repository is a place personal data was not meant to be. Meta says storing it on GitHub went against policy. Minimisation by default needs a mechanism, not a rule.
UK GDPR Article 32 and the ICO security guide	Appropriate technical and organisational measures for the risk, including a process for regularly testing their effectiveness. The ICO's guide lists basic technical controls such as those in Cyber Essentials.	Test that the controls work on your own organisation: confirm that an unauthorised token is refused, and scan for what should not be there.
UK GDPR Articles 33 and 34, and the ICO breach guide	Tell the regulator without undue delay and where feasible within 72 hours of becoming aware, unless a risk is unlikely, with reasons if later. Information may come in phases. Tell individuals without undue delay where the risk is high. Document every breach. The ICO says failing to notify can bring a fine of up to £8.7 million or 2 per cent of global turnover.	Decide in advance who declares awareness. The ICO page expects notification within 72 hours even without all the details.
NCSC secure development guidance (reviewed 2018, published 2019)	Separate secret credentials from source code. Consider key rotation and automatic scanning of repositories for secret keys. Use two-factor authentication to the repository, enforce least privilege with attributable activity, and revoke access swiftly in the event of compromise. It says to consider the development environment compromised.	Covers secrets and access. As read, it does not address personal data or test data in code, and its stated review date is 22 November 2018.
NCSC multi-factor authentication guidance, version 2.0 (September 2024)	A password alone is not strong enough to protect sensitive data in an online service. FIDO2 is ranked first, then challenge-based apps, with message-based methods last. It warns of code interception and prompt fatigue.	Choose phishing-resistant methods where you can. Any MFA beats none, but the order matters.
Cyber Essentials requirements v3.3 (April 2026)	Implement MFA where available; "authentication to cloud services must always use MFA". Remove or disable accounts no longer required. Applies to SaaS. The text has no wording on tokens, secrets, repositories, source code or personal data.	Passing Cyber Essentials does not answer the Meta questions. A token used from the command line is not an interactive MFA login (inference from the GitHub pages).

Two notes on the law. First, legislation.gov.uk now shows "the Commission" where Articles 33 and 34 name the regulator, substituted from 30 September 2026 by regulations under the Data (Use and Access) Act 2025, and the ICO's site title now reads Information Commission's Office. The ICO's guidance pages, as read, still say ICO. The 72-hour wording is unchanged in the text read. Second, no ICO or NCSC page read for this briefing addresses live personal data in test or development environments directly. The principles that apply are minimisation and protection by default. The practical rule that follows is this briefing's, not the regulator's: make test data obviously fake and labelled, so that when a repository is lost, breach triage can exclude it in minutes and an attacker is not the only party guessing.

What to do, in order

Every item is a control that GitHub documents or the NCSC and ICO name, and each was chosen because the Meta record, or the gaps in it, point at it. Nothing here needs to know how the credential was stolen. Defender level only.

The question that exposes the gap

If an outside group used one stolen credential against your repositories tonight, could you tell your regulator within three days how many people's data was in what it copied, rather than what percentage of the copy it was, and which of the secrets in it were still live?

Key facts