Was the CrowdStrike outage a cyberattack?

No. It was a defect in a content configuration update that CrowdStrike released as part of normal operations. CrowdStrike's root cause analysis, supported by a third-party review, confirmed that the out-of-bounds read was not exploitable by a threat actor. Criminals did exploit the confusion afterwards, registering lookalike domains and distributing fake recovery tools, which is a separate and predictable follow-on.

What actually caused the crash?

In February 2024, CrowdStrike introduced a sensor capability for visibility into abuse of Windows interprocess communication mechanisms, which pre-defined a set of fields for Rapid Response Content to populate. On 19 July 2024 an update was delivered where, in CrowdStrike's words, the sensor expected 20 input fields while the update provided 21. The mismatch resulted in an out-of-bounds memory read, which caused a system crash.

How many machines were affected and for how long?

Hosts running sensor version 7.11 and above that were online between 04:09 UTC and 05:27 UTC on 19 July 2024 and received the update were affected. Microsoft estimated 8.5 million Windows devices. The defective content was reverted at 05:27 UTC, 78 minutes after release, and CrowdStrike reported that roughly 99% of Windows sensors were back online by 8:00 pm EDT on 29 July.

Why was recovery so slow if the fix took 78 minutes?

Because the affected machines could not boot. A host in a bugcheck loop is not running an agent, is not reachable on the network, and cannot pull a corrected file. The published remediation involved booting into safe mode or the recovery environment and deleting the offending file, which for many organisations meant physically touching each machine, and encrypted disks added a step because recovery keys were needed first.

Does this mean EDR is a bad idea?

It means EDR carries an availability risk that has to be managed alongside the security benefit it provides. An agent with kernel-level visibility is what detects the techniques that matter, and the same privilege is why a defect in it takes the machine down. The response is to manage the deployment, meaning staged rollout, control over update timing, tested recovery, rather than to remove the control.

What should organisations have changed after it?

Three practical things. Know which vendors can push code or content to all your endpoints at once, and treat that list as concentration risk. Ask each of them what staging and rollback controls you can apply. And test a recovery path that assumes the machines cannot boot and cannot reach the network, including where your disk encryption recovery keys live.

The 2024 CrowdStrike Outage: Channel File 291 Explained

Airlines stopped flying. Hospitals moved to paper. Broadcasters went off air. Payment terminals in supermarkets stopped taking cards. For most people watching on 19 July 2024, this looked like the largest cyberattack in history.

It was a bad file. A content update to a security product crashed the Windows machines it reached, and the reason the effect was global is that the product is installed on a great many of them and runs with kernel privileges because that is what the job requires.

This page covers the mechanism as CrowdStrike documented it, why recovery took far longer than the fix, and the question the incident should leave behind, which is about supplier concentration rather than about one vendor.

Timeline

Time (UTC), 19 July 2024 unless noted	Event
February 2024	A sensor capability ships for visibility into abuse of Windows interprocess communication mechanisms, pre-defining a set of fields for Rapid Response Content
5 March 2024	The first Rapid Response Content for Channel File 291 goes to production after a successful stress test
8 to 24 April 2024	Three further Rapid Response updates deploy and perform as expected
04:09	A Rapid Response Content update is released
04:09 to 05:27	Hosts on sensor 7.11 and above that are online and receive the update crash
05:27	The defective content is reverted
20 July	Microsoft publishes an estimate of 8.5 million affected Windows devices
29 July, 8:00 pm EDT	CrowdStrike reports roughly 99% of Windows sensors back online
6 August 2024	The external root cause analysis is published

The gap that defines the incident is between 05:27 UTC on 19 July, when the bad content stopped being served, and the days of manual work that followed.

The mechanism

Falcon separates two kinds of update, and the distinction is the centre of this case.

Sensor Content is the agent itself, meaning code, shipped with the sensor version and adopted on a schedule the customer influences.

Rapid Response Content is behavioural configuration that tells the existing sensor what to look for. It exists to be fast: a new technique appears, and detection reaches customers in minutes rather than in a release cycle. It was not subject to the same staged rollout as sensor versions, because speed is the point of it.

In February 2024, a new capability shipped in the sensor for visibility into abuse of Windows interprocess communication mechanisms. That capability defined a set of fields that Rapid Response Content would populate.

On 19 July, an update was delivered that evolved that capability. In CrowdStrike's own words in the executive summary of the root cause analysis: "The sensor expected 20 input fields, while the update provided 21 input fields. In this instance, the mismatch resulted in an out-of-bounds memory read, causing a system crash."

The Content Interpreter in the sensor read past the end of the data it had. The sensor runs in kernel mode, so a fault there is not a crashed application. It is a bugcheck, the blue screen, and then a reboot into the same file and the same crash.

Two details from the analysis matter for anyone drawing lessons.

The gap survived multiple layers of testing. The parameter mismatch was not caught in sensor release testing, in stress testing of the template type, or in the several successful field deployments between March and April. Part of the reason is that the earlier instances used wildcard matching for the 21st input, so the path that failed on 19 July was never exercised with real content in it.

The bug was not exploitable. CrowdStrike's analysis, with a third-party review, concluded that a threat actor could not use it. That distinction matters because the visible symptoms of this event and of a destructive attack are identical, and organisations spent the first hours unable to tell which they were in.

Why recovery took days

The corrected content was in place 78 minutes after release. Machines that had already crashed did not benefit, and this is the part worth internalising.

A crashed host cannot be fixed remotely. It is not running the agent, has no network stack, and cannot pull a corrected file. Every automated remediation channel an organisation owns assumes a booting machine.

The published fix was manual. Boot into safe mode or the recovery environment, delete the offending file, reboot. That is a few minutes per machine and it requires access to the machine.

Disk encryption added a step. Recovering a machine into safe mode meant supplying a recovery key first, and organisations discovered where those keys lived, which for some was a system that was itself down.

Scale multiplied everything. Thousands of endpoints, servers in data centres, virtual machines, kiosks and terminals in physical locations. Some hosts recovered by rebooting repeatedly and receiving the fix in a window before the crash, which turned into an unofficial and unreliable remedy.

The general principle: the cost of a bad change is set by whether the affected system can still receive a good one. Anything that breaks boot, breaks the network stack, or breaks the management agent converts a software rollback into a physical visit, and that is a different order of magnitude in time and money.

The second-order events

Two consequences worth recording.

Criminals moved immediately. Lookalike domains, fake recovery tools carrying malware, and phishing and phone calls impersonating support to organisations known to be affected. This is the reliable pattern after any large public disruption, and it is the same playbook described in Tech Support Scams Explained applied at enterprise scale.

The legal and regulatory consequences ran long. Airlines were among the most visibly affected and litigation followed, and the incident became a standing reference in discussions of concentration risk in critical software.

What changed

CrowdStrike published a preliminary review, then a full external root cause analysis, and committed to changes in how Rapid Response Content is built, validated and deployed. The direction was staged deployment for content rather than only for sensor versions, more validation of content against what the sensor expects, and more customer control over update timing.

Microsoft used the incident to discuss reducing the need for security products to run in the Windows kernel, which is the deeper structural question. Kernel-level access is what gives an agent tamper resistance and visibility into techniques that user-mode code cannot see. It is also why a defect in that agent takes the operating system with it.

The question to take from it

The useful lesson generalises to any vendor whose software runs everywhere and updates itself. They all have this shape.

Which suppliers can change code or content on all of your endpoints at once? Security agents, management agents, backup agents, VPN clients, browser policy, driver update tooling. The list is usually longer than expected and nobody owns it as a risk.
What staging can you apply to each of them? Ask the vendor what control exists over update timing and rings, and note where the answer is none.
What is your recovery plan when the machines cannot boot? Not the plan for restoring data, which is 3-2-1 Backup Strategy. The plan for touching several thousand endpoints, including where recovery keys are held and who is authorised to use them.
How would you tell an outage from an attack in the first hour? They look the same from the help desk, and the response differs completely.

The verdict

A content update carrying one more field than the sensor was built to read crashed 8.5 million machines in 78 minutes, and the fix that took 78 minutes took ten days to finish applying because the broken machines could not be reached.

The security lesson runs against the usual grain. The controls that protect an estate are themselves privileged software running everywhere, and their failure modes belong in the risk register beside the threats they exist to stop. That is an argument for managing the deployment carefully rather than for removing the agent.