The Flink Data Breach — and Why It Wasn’t the First

The Nisura Team ·

In late September 2026, the Berlin-based rapid-grocery company Flink told its customers something no one wants to read in their inbox: an unauthorised party had accessed one of its internal systems and taken personal data. Within days the story took an unusually cruel turn — the attackers stopped waiting on the company and started emailing customers directly.

We quantify exactly this kind of event in euros. So rather than pile on, we want to draw out what the Flink case actually teaches European companies — and why the most important word in it is “again.”

What happened

According to Flink’s own customer notification and reporting by heise online, Der Spiegel, Tagesspiegel and Cybernews, an unauthorised party used compromised login credentials to reach an internal system and exfiltrate customer and employee data. A previously little-known extortion group calling itself “LPG Group” claimed responsibility, asserting it held data on roughly one million customers and 13,000 employees — figures Flink has not officially confirmed.

The exposed data was master data: names, delivery addresses, email addresses, phone numbers, and delivery instructions (floor, doorbell name). Flink states that passwords, bank details and payment-card data were not affected.

Flink later specified the target: as it told heise, the attackers reached one of its internal “Order Hub” ordering systems — the per-city warehouse back-ends behind its sub-30-minute delivery — and only one hub was breached before Flink identified it and blocked the access. What it has not disclosed is how the credential was compromised — phishing, an infostealer, password reuse, or a missing second factor. So the proximate vector is clear (a valid login into a “supposedly internal” system), but the root cause is not.

When Flink refused the initial ransom — reported at 100 ETH (~€230,000) — the group escalated to what analysts call “triple extortion”: it emailed individual customers and staff, each spoofing a Flink-like sender and addressing recipients by their correct name, demanding roughly 0.005 ETH (~€10–11.50) apiece to delete their record, threatening to sell the full dataset on the dark web. In the Netherlands alone, Flink says at least 10,000 such emails went out (NL Times). Flink blocked the access, brought in external forensics, notified German and Dutch authorities, filed a criminal complaint, and told customers not to pay.

It wasn’t the first time

Here is the part that turns an incident into a pattern. This is not Flink’s first data-security failure.

In March 2021, the research collective Zerforschung, working with public broadcaster rbb, found that Flink’s app exposed customer data through a poorly-secured API — no password required. Within about half an hour, researchers could pull the records of more than 4,000 customers: names, addresses, phone numbers, email addresses, order details, and the last four digits of credit cards (reported by heise online, Der Spiegel and Business Insider). Flink closed the hole quickly and informed the Berlin data-protection authority.

Two incidents, five years apart, with the same throughline: customer personal data reachable more easily than it should be. In 2021 it was an unauthenticated API; in 2026 it was a compromised credential. Different doors — same house, left unlocked.

Why a second time?

Flink hasn’t published a root cause for 2026, so this is analysis, not their explanation — but the context is hard to ignore. Flink is a hypergrowth story that then went into hard reverse: founded in 2020, it ballooned to roughly 21,000 staff and a multi-billion valuation, then cut deeply — headcount fell to a few thousand and it was reportedly raising fresh cash to keep going. Back in 2021, t3n already noted that in Flink’s fast growth, “the security of customer data fell by the wayside.”

Both breaches sit on the same fault line — access control to customer data. Rapid scaling builds systems fast and documents access poorly; rapid downsizing leaves stale accounts, thin security teams and off-boarding gaps — exactly the conditions in which a valid credential walks into a “supposedly internal” system unnoticed. None of that is unique to Flink; it’s what security debt looks like when growth and cost-cutting both outrun governance. The lesson isn’t “Flink is careless” — it’s that the access paths to customer data are the first thing to erode under business pressure, and the last thing anyone re-checks.

Why it matters (beyond Flink)

1. The entry point was invisible to a vulnerability scanner. No exploit, no unpatched CVE — just a valid login in the wrong hands. This credential vector is the path most external risk tools never see, and it is frequently the dominant one, especially for SaaS-heavy and platform businesses. Multi-factor authentication and disciplined credential off-boarding are not hygiene niceties; they are the control that would most likely have changed this outcome.

2. This is a regulatory event, not just a PR one. Personal data of EU residents was exfiltrated — squarely a GDPR Article 33/34 breach-notification matter, and a test of the “state of the art” security that Article 32 requires. For an in-scope essential or important entity, the same facts speak directly to NIS2 Article 21(2)(e) — vulnerability handling and the security of the systems you operate. A repeat incident makes the “appropriate, state-of-the-art measures” question much harder to answer favourably.

3. The loss is quantifiable — and so is the exposure before it happens. Notification cost, forensics, regulatory liability, and the harder-to-model trust damage of your customers being personally extorted: these are numbers, not vibes. The point of cyber-risk quantification is to put a euro figure on that exposure while it is still preventable, so the spend on MFA, offboarding and monitoring can be weighed against the loss it avoids — not against the headline.

What could it cost? Our CRQ engine, applied to Flink

Flink reported roughly €560M revenue for 2023 (~€600M gross in 2024). Feed that into our engine and the first number is the statutory ceiling: €22.4M — 4% of turnover under GDPR — if Flink sits outside NIS2, or €7.84M (1.4%) if it’s treated as a NIS2 “important” food-distribution entity. Which regime governs is itself a live question — and the 2021 repeat is a legal aggravator that pushes any actual fine toward the upper end.

Crucially, this is a data breach, not a ransomware outage. Berlin’s bill was dominated by downtime; Flink kept delivering, so the engine’s outage terms — idle labour and business interruption, worth roughly €7.6M in a comparable ransomware scenario — largely fall away. What remains is regulatory, response, and civil-claims exposure:

Modelled incident cost — Nisura engine

A data breach, not an outage: the engine’s downtime terms fall away. Bar length = total cost; segments = the mix. Scale to €30M.

Low
≈ €2M
Central
≈ €10M
High
≈ €28M
Regulatory fine (GDPR / NIS2)Incident response + forensicsNotification + Art. 82 claimsCustomer churn / trust

Two honest caveats. First, real GDPR fines usually land well below the ceiling — the €20M+ “High” bar is the aggravated worst case, not a prediction. Second, even the floor is a seven-figure event: forensics, notifying on the order of a million people, and defending GDPR Art. 82 compensation claims cost money whatever the regulator decides. The figures are a modelled range on public inputs — you’d refine them with Flink’s exact turnover, affected-record count and control posture.

The honest takeaway

We won’t pretend a single control would have made Flink invulnerable — no one is. But a second breach in five years, both centring on customer data being too easy to reach, is the kind of pattern that regulators, customers and boards read as a governance signal, not bad luck. For everyone else, the Flink case is a cheap lesson bought with someone else’s incident: know where your customer data can be reached, quantify what a breach would cost you in euros, and spend against that number.

See how that euro figure is built in Beyond heatmaps: Expected Annual Loss, or run your own exposure in the CRQ simulator.

Sources

Frequently asked questions

What happened in the Flink data breach of 2026?

In late September 2026 the Berlin-based rapid-grocery company Flink notified customers that an unauthorised party had used compromised login credentials to access an internal system and exfiltrate personal data — names, delivery addresses, email addresses, phone numbers and delivery instructions. Flink states passwords, bank details and payment-card data were not affected. An extortion group calling itself “LPG Group” claimed it stole data on roughly one million customers and 13,000 employees; Flink has not officially confirmed those figures.

Was this Flink’s first data breach?

No. It was at least Flink’s second data-security incident. In March 2021 the research collective Zerforschung, working with public broadcaster rbb, found that the Flink app exposed the data of more than 4,000 customers through a poorly-secured API with no password required — including names, addresses, phone numbers, email addresses and the last four digits of credit cards. Flink closed that hole quickly and informed the Berlin data-protection authority. Two incidents five years apart share the same throughline: customer data reachable more easily than it should be.

What did the extortionists demand?

After Flink refused an initial ransom reported at 100 ETH (~€230,000), the “LPG Group” escalated to “triple extortion” — emailing individual customers and employees directly, addressing them by name from a Flink-like sender address, and demanding roughly 0.005 ETH (~€10–11.50) each to delete their record, with a threat to sell the full dataset on the dark web. In the Netherlands alone at least 10,000 such emails were reported. Flink and consumer authorities advise recipients not to pay.

What are the GDPR and NIS2 implications?

Exfiltration of EU residents’ personal data is a GDPR Article 33/34 breach-notification event and a test of the “state of the art” security measures Article 32 requires. For an in-scope NIS2 essential or important entity, the same facts bear directly on NIS2 Article 21(2)(e) — vulnerability handling and the security of the systems the entity operates. A repeat incident makes demonstrating “appropriate, state-of-the-art measures” materially harder.

How could the breach have been prevented?

The entry point was a compromised valid login — the credential vector — not an unpatched software flaw, so a vulnerability scanner would not have seen it. The controls that most directly address it are multi-factor authentication on all access, disciplined off-boarding of former employees’ credentials, and least-privilege access to internal systems holding customer data. Quantifying the euro exposure of such a breach in advance lets a company weigh that control spend against the loss it avoids.