Beneficiary Data Is Nuclear Fuel: What the WFP Gaza breach reveals about the protocol the sector never wrote

By Thomas Byrnes
• • 8

AI disclosure: This piece predates MarketImpact's per-article disclosure standard, introduced June 2026. During this period AI tools assisted with research synthesis, multilingual data collection, and supported drafting under our verification discipline; all analysis, conclusions, and editorial judgement are the author's own. How we use and verify AI:marketimpact.org/how-we-use-ai.

On 14 May, someone accessed the World Food Programme's self-registration application for Palestine. The data of roughly 600,000 households in Gaza was exposed: names, ID numbers, mobile numbers, and location data. Recipients learned about it through a Telegram message on 31 May, seventeen days after WFP detected the intrusion. The New Humanitarian, which broke the story on 2 June, called it possibly the largest known breach of humanitarian beneficiary data to date. The previous record was the 2022 ICRC breach, which exposed around 515,000 people. This one may have exposed more individuals in a single incident than that breach did in total, in a context where the people exposed are living through a war.

The instinct will be to treat this as a cybersecurity story. Who got in, how, and whether the firewalls were good enough. I think that is the wrong frame, and it will lead the sector to the wrong fix.

To be clear about what this was not. The breach was isolated to the self-registration application used in Palestine. It did not touch SCOPE, WFP's global beneficiary system. WFP shut the platform down quickly, contained the intrusion, and is investigating. No party has claimed responsibility, and I'm not going to speculate about attribution. Whoever it was and however they got in, the structural lesson is the same. The question that matters is not how someone got access. It is why there was so much to take.

The nuclear fuel problem

Beneficiary personal data in a conflict zone is like nuclear fuel, an analogy I first used writing about AI identity matching in Yemen in 2024, and one others have applied to personal data generally since at least the late 2000s.

It enables things nothing else can. Household-level cash delivery at scale. Deduplication across agencies. Correcting exclusion errors so the right families get assistance. WFP's self-registration portal, known as the People Portal, is genuinely good humanitarian technology. It cut registration red tape and response times for a population that could not afford either.

But like nuclear fuel, the data is hazardous from the moment it is created, and it stays hazardous long after it has done its job. A registration record from 2024 can still get someone killed in 2026. Names linked to ID numbers linked to phone numbers linked to locations, held on a population in an active conflict, is one of the most dangerous datasets anywhere. For a family in Gaza, this is not an abstract privacy harm. A name tied to a phone number tied to a location, in the hands of any party to a conflict, is targeting information. People handed over that data because it was the price of eating. They had no real choice about the collection and no visibility of the retention. The duty of care that creates is not discharged by a consent checkbox.

The nuclear industry understood this about its own material decades ago, which is why it has waste management protocols. Spent fuel does not sit next to the reactor. It is catalogued, moved, contained, and tracked, because everyone accepts that the material remains dangerous after its useful life ends.

The humanitarian sector has no equivalent. We have data protection policies, responsible data frameworks, and privacy impact assessments, and most of them say the right things about retention and deletion. What almost no agency has is the operational machinery to act on them. A retention schedule in a policy document is not a protocol. The question that decided the scale of this breach is the one nobody is resourced or accountable for answering in practice: when does data actually come off the live system?

Two million registrations, one live system

More than 2 million people had registered through the People Portal. The breach exposed 600,000 households. Stop and ask the question nobody asks until after an incident: how many of those records needed to be in an internet-facing application on 14 May?

Some did. Current caseloads need live data. And Gaza is an unusual case. With WFP assisting around 1.6 million people a month there, a far higher share of that register may be legitimately live than in most contexts. But registration systems accumulate. Historical registrations, people who moved, duplicate entries, households assisted under programmes that have closed. Data collected for a specific operational purpose stays in active, networked systems long after the purpose is served, because no protocol exists that says it should leave, and nobody owns the decision to remove it.

That's an organisational failure, not a technical one. Nobody wrote the rule that says on day X this data comes off the live system. So it never does. The live database becomes an archive by default, and the archive sits on the internet.

The principle should be simple. Collect what you need. Use it for the minimum time required. Then move raw records to a secure offline archive, and keep only the minimum dataset for current operations in the live system. Everything else is waste that needs managing, not an asset that needs keeping.

The audit objection

The standard reply is that agencies cannot delete or archive data because donors require it. Audits sometimes reach back years, and auditors want documentation. This is true, and it's not an argument for keeping records in a web application.

The audit requirement is for the data to exist, not for it to be internet-facing. Records can sit encrypted on offline storage in a safe, catalogued and retrievable, handed over when the auditor arrives. That satisfies every accountability obligation while removing the data from the attack surface entirely. An attacker cannot exfiltrate what is not connected. Neither, for that matter, can anyone with legitimate system access who decides to abuse it. Cold storage is the one control that works regardless of how a breach happens.

There is a genuine problem underneath the objection, which is that donors and auditors often cannot tell agencies which data they actually need retained and for how long. That ambiguity pushes agencies towards keeping everything live forever, which is the most dangerous possible default. Donors who want to reduce risk for the people their funding reaches could fix this with one move: publish clear retention requirements, and make documented data decommissioning a compliance expectation rather than a liability.

The barrier to exploitation is collapsing

Everything above was true before this year. What has changed is the cost of exploitation.

Anthropic, the company behind Claude, is currently running a programme called Project Glasswing, in which a restricted frontier model is used to find security flaws in critical software before attackers do. In the first weeks, the model found more than ten thousand high or critical severity vulnerabilities across some of the most widely used software in the world. The model is so capable that Anthropic will not release it publicly, and the company has said other developers will reach this level soon, possibly without the same restraint.

Read that against a web application holding two million registration records in a war zone. The tools to find and exploit vulnerabilities in systems like that are ceasing to be the preserve of state intelligence services. The cost of analysing 600,000 household records for patterns is dropping to the price of a prompt. The cost of producing convincing fraudulent documents from stolen identity data is dropping to intent rather than skill.

None of these risks are new. What's collapsing is the barrier to acting on them. Every record sitting in a live system that does not need to be there is exposure the sector is choosing to carry into an environment where that choice gets more expensive by the quarter.

What good would look like

None of this requires new technology. It requires a protocol and an owner.

Every dataset containing beneficiary personal information should have a defined operational lifespan set at collection, a named person responsible for decommissioning it, and a default destination, which is encrypted offline storage for the audit period and deletion after that. Live systems should hold current caseloads only.

Agencies should be able to answer, at any moment: of all the records in your internet-facing systems right now, how many serve a current operational purpose? If the answer is unknown, that's the finding.

WFP will harden the People Portal and the platform will come back, as it should, because the people of Gaza need it. But every agency running a registration system, a distribution database, or a feedback platform in a conflict zone should be asking the waste management question this week, not waiting for their own incident to ask it for them.

The sector treats beneficiary data as an asset. In a conflict zone it is a liability that happens to be necessary for a limited time. The sooner we manage it that way, the fewer people we expose to risks they never signed up for when they registered for food.

Tom

Thomas Byrnes is the founder of MarketImpact, a practitioner-led consultancy working on humanitarian crisis analysis, AI adoption, and digital systems.


Sources: The New Humanitarian, "Data of 600,000 Gaza households exposed in WFP cyber-attack" (2 June 2026); Anthropic, "Project Glasswing: An initial update" (May 2026); ICRC statements on the 2022 Restoring Family Links breach.

Enjoyed this article?

This post is from Aid and Dev Dispatches, a LinkedIn newsletter with expert analysis on humanitarian reform, AI adoption, crisis economics, and the politics of aid. Join 9,000+ subscribers.

Subscribe on LinkedIn

About the Author

Thomas Byrnes is a Humanitarian & Digital Social Protection Expert and CEO of MarketImpact.