Fairlife: the ransomware attack that stopped production
The Anubis attack on Coca-Cola's Fairlife halted US production, and entry came through a third party. An analysis of an OT incident and SEC disclosure.
- AUTHOR
- Karol Rapacz / CEO of Breachroad · OSCP · PNPT
- PUBLISHED
- 25 July 2026
- READING TIME
- 14 min read
- TOPIC
- Threats and Incidents
On 16 July 2026, Coca-Cola filed a Form 8-K with the US Securities and Exchange Commission, disclosing a security incident at its subsidiary Fairlife — a dairy brand worth roughly $4 billion. The filing contained a sentence that reads like a line from any manufacturer’s risk register: attackers gained access to a portion of the systems, including production-related systems, and US production was temporarily suspended. Canadian operations continued.
Four days later the Anubis ransomware group listed Coca-Cola and Fairlife on its leak site, and on 21–22 July publicly claimed the attack, stating it had encrypted the Nutanix environment and exfiltrated 1 TB of data.
This incident is worth analysing not because it’s exceptional, but because it’s a model case: it demonstrates three things at once — entry through a third party, the jump of impact from IT to production, and how a public company communicates an incident while it still knows almost nothing.
Entry through a third party
The most important technical detail in Coca-Cola’s disclosure: access to Fairlife’s IT environment came through a third party. That means the first link wasn’t an employee clicking an attachment or an unpatched VPN appliance, but a trusted relationship with an external entity.
This class of entry is particularly hard to detect, because the traffic arrives through a channel that is itself legitimate: an integrator’s account, a machine vendor’s service access, a logistics partner’s VPN connection, an account in a maintenance system. To monitoring it looks like normal work — until it starts doing unusual things.
In production environments the problem is sharper, because vendors typically require remote access to machines under warranty or SLA terms. The result is a set of accounts and tunnels that:
- rarely enter the standard identity-management process,
- often hold broader permissions than the task requires,
- get shared between the vendor’s technicians,
- almost never have phishing-resistant MFA,
- survive for years, including after the contract ends.
That is precisely the risk surface described in our piece on third-party risk management, and at European scale in the analysis of rising ransomware against manufacturing.
Why production stopped
A common misconception is worth clearing up. Halting production does not necessarily mean ransomware encrypted the PLCs or HMI panels on the line. In practice two other scenarios dominate — both leading to the same outcome:
1. Precautionary shutdown. The response team sees an IT compromise and cannot, at that moment, prove the production network is clean. Since food and human safety are at stake, the decision is obvious: isolate and stop. That’s not a failure — it’s a continuity plan working.
2. Loss of production-adjacent systems. A modern plant doesn’t run on “machines alone”. It needs MES (manufacturing execution), ERP (orders, materials), WMS (warehouse), labelling, quality and batch-tracing systems. Taking that layer down stops the line as effectively as encrypting a controller — because you cannot legally produce and release a batch without documentation.
Anubis’s claim of encrypting the Nutanix environment fits this neatly: it’s a hyperconverged platform typically hosting the virtual machines that run plant systems. Hitting the virtualisation layer is economical for an attacker — one move immobilises dozens of servers. The same logic drives attacks on hypervisor hosts, where compromising a single management component produces a mass effect.
So when planning resilience, the question isn’t “do we have backups” but “how long can the line run without MES/ERP, and can we produce in a degraded mode?”
Double extortion and time pressure
The sequence of events — the 8-K filing (16 July), then the leak-site listing (20 July) and public claim (21–22 July) — is textbook double extortion. The attacker doesn’t monetise encryption alone; they monetise the threat of publication of stolen data.
A claimed 1 TB means that even flawless restoration from backups doesn’t close the matter. Backups solve availability. They don’t solve confidentiality. That’s why modern ransomware defence emphasises detecting exfiltration — before encryption happens. In a typical chain, data theft takes hours or days and leaves traces: unusual outbound volumes, archiving of large directories, connections to file-storage services, service accounts working at night.
A methodological note: a criminal group’s claims are not evidence. The “1 TB” volume and data scope come from the attacker and may be inflated for negotiating leverage. Treat them as a hypothesis to verify with your own telemetry, not as established fact — a standard we try to hold in every incident analysis.
Communicating when you still know nothing
The line in Coca-Cola’s statement — that the full scope, nature and impacts of the incident are not yet known — is sometimes read as evasive. In reality it’s the only honest formulation days after detection. Establishing exactly which data left an organisation takes weeks, often months (we covered this with the Conduent breach, where the victim count grew from 10 to 62 million).
The practical lesson for security teams: prepare communications in advance. During an incident there’s no time to work out who approves wording, what can be said without harming the investigation, and how a statement reads when you know 20% of the picture. Rehearsing that is cheap — which is exactly what tabletop exercises and an incident response plan are for.
A practical checklist for manufacturers
IT/OT segmentation with a real test. Not a statement in documentation, but a check: can you reach the control network from an accountant’s laptop? Is inter-zone traffic limited to specific protocols and hosts? The offensive version of that question is covered in internal network segmentation testing.
Inventory of vendor access. Who, to what, with which rights and since when. Every service access: named, time-bound (enabled on request), behind MFA, fully logged. Shared “service” accounts are today’s leading candidate for an attacker’s first step.
Protect the virtualisation layer. Treat hypervisor management consoles as your most critical systems: a separate admin zone, MFA, no reachability from the user network, dedicated admin accounts. Compromising that layer means losing every machine at once.
Attacker-resistant backups. Immutable or offline, outside the production domain, with regular full-system restore testing — not a single-file restore. We set out the rules in the 3-2-1 strategy.
Detect exfiltration, not just encryption. Alert on unusual outbound traffic, mass reads from file shares, directory archiving and new remote-access tools. If you detect the attack only when the ransom note appears, you’ve lost the entire window in which the chain could have been broken — more in security monitoring for SMEs.
A “production without IT” scenario. Define how the plant operates in degraded mode: paper work orders, manual labelling, a batch-release procedure. That’s the difference between downtime measured in hours and downtime measured in weeks.
Frequently asked questions (FAQ)
Did ransomware encrypt machines on the line? What’s publicly confirmed is a production halt and access to production-related systems; the group claims it encrypted the virtualisation environment. There’s no basis to assert that line controllers were encrypted — in practice the production-adjacent layer fails first, or production is stopped precautionarily.
We’re a smaller plant — does this apply to us? Yes, and the “through a third party” vector arguably raises the risk: smaller firms usually have more remote service access and fewer resources to control it. They’re also targeted as a route to a larger partner.
Does paying the ransom solve the problem? It doesn’t solve confidentiality — the data has already left, and the only “safeguard” is a criminal’s promise. Payment also doesn’t discharge disclosure obligations or restore customer trust. That business decision should follow a plan, not panic on day three of an incident.
Where do we start on a limited budget? With the three best effort-to-cost items: inventorying and restricting vendor access, tested offline backups, and real IT/OT segmentation. Get in touch if you want help sequencing that for your situation.
Summary
The Fairlife incident shows the complete modern chain: entry via a trusted third party → compromise of the virtualisation layer → production halt → double extortion and leak-site pressure. None of these elements is new; what’s new is the consistency with which attackers combine them and target sectors where downtime costs the most. Resilience is built before the incident: vendor access control, segmentation, virtualisation hardening, tested restores and a ready degraded-mode plan. If you want to know how far an attacker starting from a vendor’s service account would get in your network — let’s verify it with a controlled test.
Sources and further reading: BleepingComputer, SecurityWeek, SEC EDGAR — 8-K filings, CISA — StopRansomware.


