2026-09-25

A Meta engineer bypassed internal security to download 30,000 private Facebook photos — what scrubbing metadata before upload changes when the threat is an insider

Most advice about photo privacy — including most of this blog — assumes the risk is either a stranger who sees what you posted publicly, or a hacker who breaks into a company's servers from the outside. A case that surfaced in the UK in April 2026 is neither. It's a reminder that "this platform is secure" is a claim about outside attackers, and that the people who already have legitimate access on the inside are a separate risk a file scrubber's timing can still do something about.

What a former Meta engineer is accused of doing

In November 2025, London's Metropolitan Police arrested a man in his 30s, a former Meta engineer, on suspicion of unauthorized access to computer material, after — according to PetaPixel's and Engadget's April 2026 reporting — he wrote a script designed to route around Meta's own internal detection systems and used it to download roughly 30,000 private photos belonging to Facebook users. The Metropolitan Police's Cybercrime Unit opened its investigation after a referral from the FBI in the US. Meta's own statement, quoted by Malwarebytes, says the company "discovered the breach over a year ago" — meaning sometime in 2024 or earlier — fired the employee, notified affected users, and referred the case to law enforcement itself. As of the April 2026 reporting, the former engineer remained on police bail, due to report back in May 2026. No public reporting says what, specifically, he did with the photos, or confirms a motive.

An employee with legitimate access is a different threat than an outside hacker

Nothing about this case involved cracking a password, exploiting a server vulnerability, or any of the things "is this platform secure" usually asks about. The person already had a badge and system access as a Meta employee; the reported failure is that whatever monitoring Meta runs on its own engineers didn't catch a custom workaround for what the company itself now says was over a year. That's not a hypothetical category of risk. Verizon's 2026 Data Breach Investigations Report — covering incidents from November 2024 through October 2025 — found internal actors involved in 12% of breaches (down from 18% the year before), and among those, the leading motive was "convenience" at 60%, ahead of financial gain at 33%. A platform's outward security posture — encryption, penetration tests, bug bounties — says close to nothing about this category, because none of it is about keeping out people who are already inside.

What was actually in the files, and what's confirmed versus inferred

To be precise about what's actually known: no report on this case says whether the embedded metadata of the downloaded photos specifically was part of what was examined or extracted, and NearScrub isn't claiming this incident proves that it was. What is separately on the record, and independently verifiable, is Meta's own Data Policy, which states the company collects "metadata, such as the location of a photo or the date a file was created" from content people upload — a statement about what Meta's systems retain, not about what a friend viewing your feed sees, since platforms are well documented to strip that same metadata from the copies shown to other users. Put those two facts next to each other and the point isn't that this specific case definitely involved GPS tags; it's that a script built to reach into Meta's internal photo storage was reaching into the kind of storage Meta's own policy says can include exactly that information.

What scrubbing before upload changes, and what it can't undo

The mechanical point is a simple one: if a photo's EXIF block is removed on your own device before it's ever sent anywhere, that data was never in the copy that reached Meta's servers in the first place — regardless of which internal system, cache, or table an insider script later reaches, and regardless of how long it takes a company to notice its own employee built a workaround. That doesn't depend on trusting Meta's internal audits or taking its "we caught it and fixed it" statement on faith; it depends on nothing being there to find. That's a meaningfully different guarantee from "the platform strips metadata for other viewers," which several past investigations — and Meta's own Data Policy — show is a claim about the served copy, not about everything the company retains.

What it doesn't change is everything else in this case. Scrubbing a file's metadata does nothing to stop an employee with legitimate credentials from viewing the photo itself — the actual harm in an incident like this — because the image content was never something a metadata tool touches or was ever designed to touch. It does nothing about the platform-generated data tied to your account: who uploaded the photo, when, from where, or any internal tags Meta's own systems compute — none of that lives inside the file NearScrub processes, so removing file metadata has zero effect on it either way. And it does nothing about the roughly year-long gap this case describes between Meta discovering the issue internally and any of this becoming public — that's a detection and disclosure question that belongs entirely to the platform, not to anything a user can do to a file before sending it. An insider case like this is exactly the situation where you can't verify a platform's internal controls from the outside. What you can verify, and control directly, is what was in the file before it left your device.