Ahold Delhaize Cyberattack, October 2026: Retail Resilience Lessons

On 11 and 12 October 2026, Ahold Delhaize took websites, apps and other systems offline after suspicious activity in its network. Online shopping stopped at Albert Heijn, Delhaize and five US chains; stores stayed open. The company blames malicious actors and has no evidence of data theft. Retailers should map what their stores need from central systems.

This post sticks to what the company and the cited reporting say. The attacker, the entry point and the full scope are still unknown. The useful part for everyone else is the shape of the disruption: a precautionary shutdown at the centre reached shelf labels, distribution centres, loyalty schemes and webshops on two continents.

What happened

Ahold Delhaize is a Dutch grocery group. According to its own boilerplate it runs 17 brands and more than 9,500 stores serving over 77 million customers a week in Europe, the United States and Indonesia. The table follows the company's three press releases, with outside reporting where it adds detail.

The CEO, Frans Muller, defended the shutdown in the 19 October release: "The investigation to date confirms this was the right decision."

What is known and what is not

Here is how the claims sort out on 21 October.

Where sources disagree

Attack type. Cor Molenaar of Erasmus University suggested a denial of service attack (OODAloop; HackingPassion). Pim Takkenberg told Nieuwsuur someone was likely inside the systems (HackingPassion). NOS's anonymous sources describe attack traffic that staff cut off. The company has not said. Treat all three as opinions.

Cost. The €10 million figure is an expert estimate reported by NL Times, citing ANP, and excludes IT specialists (IBTimes). Retail expert Erik Hemmes put missed Albert Heijn revenue at about €21 million by 14 October (HackingPassion). Ahold Delhaize has given no figure; its third quarter results are due 4 November, per HackingPassion.

Police report date. The company's release is dated 19 October and says the report was filed that day. Mass Market Retailers, writing on 20 October, dates it 20 October. We follow the company.

Albert Heijn deliveries. Reuters reported deliveries would not restart before Thursday. The company's release says from Friday 23 October.

Shelf labels. HackingPassion says labels showed correct prices again on 13 October. We could not confirm this elsewhere.

Not to be confused with 2024

Ahold Delhaize USA had a separate incident in November 2024. According to its filing with Maine's Attorney General, reported by BleepingComputer, files from internal US business systems were taken, affecting 2,242,521 people, largely via employment records. The INC Ransom group claimed it in April 2025; the company declined to confirm that. Nothing published links the two incidents.

Who was affected

Stop & Shop offered 10% off in store, up to $10 (Boston Globe). Albert Heijn said it would make up missed personal discounts and savings stamps, mostly automatically (IBTimes).

Why take everything offline

Ahold Delhaize says it took systems offline to help protect them. When you cannot yet tell how far an intruder reached, every connected system is a possible path. Disconnecting buys time to look, at the cost of the business those systems run.

The NOS account, if accurate, is the case for acting fast: staff saw suspicious traffic and switched systems off while it was happening. The cost side is just as visible. Online sales are about 10% of Albert Heijn's business, per Reuters. US webshops were dark for more than a week. Distribution and shelf pricing were disrupted too.

Public bodies faced the same trade over PHP2Shell, covered in why governments took websites offline over PHP2Shell. Going dark is a valid response. It is far cheaper when you have decided in advance what goes dark, in what order, and what keeps running.

How a central outage reaches the shop floor

Electronic shelf labels. Labels take prices from a central pricing system. When that feed stopped, they kept showing the previous week's promotions while tills charged current prices (NOS). The labels did not fail; they held their last state.

Distribution. According to Distrifood's editor Daan Heijnk, quoted by Brussels Times, Albert Heijn stores hold little stock and rely on same-day supply. When systems went down, distribution centres had goods but no way to decide where to send them. Belgian stores switched to an alternative supply path from other Dutch centres and saw only limited gaps, according to Albert Heijn Belgium.

Loyalty. Personal discounts, points and fuel rewards stopped in both regions (NOS; Boston Globe). They sit on the same customer platforms as the webshop.

Third-party services. Boston Globe notes that shoppers were pointed to third-party delivery apps, which add fees and tips. According to HackingPassion, citing the Philadelphia Inquirer, Uber Eats said it might apply digital coupons automatically while the brands' apps were down. Partners kept part of the online channel alive, but only as far as their integrations did not depend on the systems that were off.

None of these designs is wrong. Same-day supply and central pricing are efficient, but efficiency creates dependencies, and an incident plan has to list them.

What to do now

These steps apply to any retailer or any business with stores, a webshop and a central IT estate.

1. Map store dependencies on central systems. For each store function (tills, card payments, pricing, shelf labels, ordering, pharmacy, staff rotas, loyalty), write down which central service it calls and what happens when that service disappears. Test from a store network, not the head office:

   # From a store VLAN: what central services can this segment reach?
   for h in pricing.internal.example erp.internal.example loyalty.internal.example; do
     nc -zv -w 3 "$h" 443
   done
   
   # Which path does store traffic take to the data centre?
   traceroute -n erp.internal.example
   

   Anything a store reaches but does not need is a path you may have to cut.

2. Decide what your shelf labels do when the feed stops. Ask your label vendor whether a local controller can push a fallback state, and how long a full price refresh takes per store. Put the answer, the customer notice and the till rule in your runbook.

3. Prepare the phishing warning before you need it. Albert Heijn warned customers to watch for fake messages and fake staff using its name (IBTimes). Aura's Tom Clayton told the Boston Globe to expect fake reset requests and refund offers. Check that your domains are hard to spoof:

   # Is DMARC enforcing, or only monitoring?
   dig +short TXT _dmarc.example.com
   
   # Which third parties may send mail as you?
   dig +short TXT example.com | grep -i spf
   

   A DMARC policy of p=none only reports. p=quarantine or p=reject is what stops spoofed mail reaching inboxes at most providers.

4. Write the restore order down. A phased restart needs an order, for example identity, then distribution, then pricing, then customer platforms. For each step, list what it needs and who signs off. Rehearse it yearly.

5. Test a restore, timed. Pick one customer-facing service and restore it into a clean environment:

   # Is last night's database dump readable?
   pg_restore --list nightly.dump | head
   
   # Restore into a scratch database and time it
   time pg_restore --dbname=restore_test --no-owner nightly.dump
   

6. Know what software runs your webshop and apps, so you know what goes back in when you rebuild:

   safeguard scan --dir ./storefront
   safeguard scan --image registry.example.com/checkout-api:2026.10
   ls ./output
   

7. Check internet-facing systems against known exploited vulnerabilities. The entry point here is unknown, but edge devices and remote access tools are frequent targets. Pull the CISA KEV feed and compare it to your inventory of firewalls, VPNs and gateways:

   curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
     | jq -r '.vulnerabilities[] | select(.dateAdded >= "2026-09-01") | [.cveID, .vendorProject, .product] | @tsv'
   

   Our post on edge device zero days in October 2026 covers this month's list.

8. List the partners who keep selling when you cannot. Delivery apps, payment providers, pharmacy networks: note which of your systems each calls and whether it works when your webshop is off.

What would have helped

None of this says what Ahold Delhaize did or did not have in place; we do not know. These are practices that reduce damage when any retailer faces an intrusion of this kind.

Practices any team can use

Segmentation that matches the business. Separate store networks, distribution, corporate IT and customer platforms so you can cut one without cutting all. The goal is a choice smaller than "everything off". If isolating the webshop does not also stop distribution centres, you can protect one while the other keeps feeding stores.

A tested store offline mode. Tills that sell on cached prices, labels that hold a known state, and a local process for stock orders. Drill a full trading day without head office.

Distribution that can run on reduced data. The Belgian stores' alternative supply path limited shortages there, according to Brussels Times. A degraded mode that ships the usual order for each store, based on last week's volumes, beats shipping nothing.

Third-party maps and contracts. Know which partners call your systems and what they need. Agree in advance how they behave during your outage: pause, take orders offline, or fall back to fixed menus.

Restore plans with an order and owners. A controlled re-launch is safer than a big bang. Plan which systems come back first, how you check each one is clean before reconnecting it, and who approves each step. Keep backups and build pipelines outside the systems you may need to isolate. Our IDCF Cloud ransomware post covers backup independence in more detail.

Notification readiness. Ahold Delhaize says it told the Dutch NCSC within 24 hours. Know your own deadlines and contacts per country, including police, regulators and data protection authorities, before day one.

Customer comms that include fraud warnings. Publish where official messages come from and what you will never ask for. Repeat it during recovery, when compensation messages make phishing more convincing.

Where Safeguard fits

Limits first. Safeguard does not detect or stop a network intrusion like this one. It does not watch network traffic, segment stores, run backups or restores, or warn customers. It would not have kept these webshops online. Here is what it does in the parts it touches.

Software inventory and SBOMs. Safeguard generates SBOMs for repositories, container images and existing SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with JSON results under ./output). After an incident, that is the list of what should be in each rebuilt service. The platform shows which projects contain a given component and version, which helps when you need to find every service that uses one library. See SBOM incident response: finding affected products fast.

Patch prioritisation. Components are matched against vulnerability databases, with reachability analysis and known exploitation signals, so the storefront, checkout and app backends get fixed in order of real risk. Policies and gates can block or flag a re-launched service that still carries a known exploited flaw.

Approvals for changes during recovery. The Safeguard CLI's assistant can edit code and run commands with your approval, under /permissions modes (Ask, Accept edits, Plan, Auto or Strict). Autonomous fix PRs exist but are off by default. The desktop and phone apps can send work to a computer running the CLI and ask you to approve each command. During a phased re-launch, that means each change waits for a named person to say yes.

Third-party records. Safeguard's Third-Party Risk Manager lets you onboard vendors, request SBOMs from them and track supplier risk with policies and gates. That gives your partner map a home. It would not warn you that a partner, or you, was about to be attacked.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. That makes it relevant to the open source inside your webshop and apps. It does not cover network appliances or store hardware, and we have no indication that this incident involved a package flaw.

Gold Open Source (gold.safeguard.sh) is free and needs no login. It gives searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) offers hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or above, Sigstore-signed, with evidence pages. An artifact loses its badge if it regresses.

The habit that matters after any incident is to rebuild from patched, signed components from a curated source, rather than restoring whatever ran before.

Common mistakes

• Treating "stores are open" as "stores are fine". Here stores stayed open while pricing, supply and loyalty were disrupted.
• Restoring without an order. Bringing everything back at once can reconnect an intruder. Phase it and verify each step.
• Repeating early cost or attack type claims as fact. Every number and theory in the first week came from outside experts or anonymous sources.
• Forgetting the phishing wave. Outages and compensation offers make fake messages more believable. Warn early and repeat.
• Confusing incidents. The 2024 data theft and the 2026 outage are separate events in public reporting.

FAQ

What happened at Ahold Delhaize in October 2026?

It detected suspicious activity around 11 October and took systems offline as a precaution, including most brands' websites and apps in Europe and the US. On 19 October it said malicious actors were responsible.

Was customer data stolen?

The company says it has no evidence at this moment that sensitive customer, associate or partner data was taken, and that the investigation is ongoing. That could change, so check its newsroom for updates.

Who was behind the attack?

Not disclosed. We found no public claim by any group as of 21 October. Ahold's Europe CEO denied rumours of a hostage-style ransom demand, according to Brussels Times.

Why were shelf prices wrong?

Electronic shelf labels get prices from a central system. With that system offline, labels kept showing the previous week's promotions while tills charged current prices, according to NOS.

Is this linked to the French supermarket attacks?

Reuters reports that the Dutch NCSC sees no reason to believe the incident is directly linked to attacks in other countries, including the French incident in which store refrigeration was affected.

Is this the same as the 2024 Ahold Delhaize breach?

No. The 2024 incident was a theft of files from US business systems affecting about 2.2 million people. Nothing published links the two.

Would Safeguard have prevented this?

No. Safeguard does not detect or stop network intrusions. It helps you know what software you run, patch the riskiest parts first, and approve each change during recovery.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos show this incident. Each shows a real flow that would apply during a phased re-launch.

The first demo is a CLI session that fixes a lodash CVE: it reads the finding, asks before each command, updates the dependency and runs the tests. Before bringing a storefront or checkout service back online, you would run the same scan against its repository and ask the assistant to patch what is exposed, approving each step.

Click through it at your own pace, or open it full screen.

The second demo is a desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then approve or deny each command and file edit until the upgrade is done and tests pass. In a recovery, an engineer on a clean, rebuilt machine would work the same way, and the approvals form a record of what changed before each system reconnects.

Click through it at your own pace, or open it full screen.

The third demo is an Android session that sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. Incident leads are rarely at a desk during a week like this one; the same approval can come from wherever they are.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI docs. For the rest of this month's incidents, see October 2026 security incidents and what would have helped.

Quick check

Sources

• Ahold Delhaize: takes precautionary measures following cybersecurity incident (12 Oct 2026, PDF)
• Ahold Delhaize: update on cybersecurity incident (13 Oct 2026, PDF)
• Ahold Delhaize: update on status of cybersecurity incident (19 Oct 2026, PDF)
• NOS: no deliveries and wrong store prices after Albert Heijn incident (Dutch)
• The Record: Ahold Delhaize confirms malicious actions behind cyber outages
• KSL (Reuters): Ahold Delhaize reports cybersecurity incident to Dutch police
• Brussels Times: how a mysterious cyber incident paralysed a Dutch supermarket chain
• IBTimes UK: at least 11 days without deliveries
• OODAloop: Albert Heijn damage likely tops €10 million
• HackingPassion: Ahold Delhaize shut down Albert Heijn and five US chains
• Mass Market Retailers: Ahold Delhaize issues update on status of cybersecurity incident
• Boston Globe: Stop & Shop's online services have returned after cyberattack
• WRAL: Food Lion restores app, website after cybersecurity incident
• The Banner: Giant and Food Lion back online after weeklong incident
• BleepingComputer: Ahold Delhaize says 2024 data breach affects 2.2 million people

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.