Zero-click chains broke the user-in-the-loop model

1. Opening position

Malware can land on a device without the user clicking, opening, approving, or interacting with anything. This is not theoretical. It is a documented class of attack referred to as zero-click. The user is not the failure point. The system is.

The operative shift is this: execution no longer requires consent. It requires reachability. If a device exposes a parser, a service, or a protocol handler to untrusted input, the attacker does not need the user. They need the input path. The device receives data and the data executes.

This collapses the entire model of user-driven defence. Awareness training, link hygiene, and download discipline all assume the user is in the loop. In a zero-click chain, the user is not in the loop. The control surface is the code that processes inbound data, and that code runs whether the user is paying attention or not.

2. What actually failed

The externally observable behaviour is consistent across the class: a device receives a crafted input over a normal channel, and code executes on that device without any user action tied to the execution. The channel is one the device is designed to accept. Messaging, media handling, protocol parsing, background sync. The input arrives through a path the system is built to process automatically.

What failed is the boundary between data and execution. Input that was supposed to be parsed as content was instead processed in a way that produced execution. The parser, decoder, or handler accepted attacker-controlled bytes and reached a state where those bytes influenced control flow. The user did not approve this. The user was not asked. The system processed the input because processing the input is its job.

The specific internal sequence inside the parser is not confirmed for any given case unless explicitly disclosed. What is confirmed by the class itself is the externally visible outcome: inbound data, no user interaction, code running. Everything between those two points is implementation detail that varies per vulnerability and per vendor disclosure.

3. Why it failed

The system trusted the input path. Any service that accepts unsolicited input from the network or from another device is operating in a hostile context by default. If that service parses complex formats, decodes media, or interprets protocol fields, it is exposed to attacker-controlled structure. The control point is the parser, and the parser is running before the user is ever involved.

The failure is structural, not behavioural. There is no user action to harden because the user is not in the execution path. The enforcement point is the code that handles the input, the privilege level it runs at, and the isolation around it. If that code has a defect and runs with sufficient privilege to matter, the defect is the attack. There is no second gate.

Whether additional containment existed in any specific incident is not confirmed without explicit disclosure. What is logically necessary is this: execution occurred, which means whatever boundaries existed between inbound data and code execution were not sufficient to stop it. A control that does not stop the behaviour is not effective for that behaviour. The presence of a control is not the same as the enforcement of a control.

The mechanism is the conversion of data into execution inside a process that was designed to handle untrusted input automatically. The parser is the failure surface. When a parser reaches a state where attacker-controlled bytes influence control flow, the data path has become the execution path. This is not a user-facing failure. It is a process-internal failure exposed by an externally reachable input channel. The reachability of that channel, not the sophistication of the payload, is what determines whether the failure is exploitable.

The drift compounds with privilege. If the process that handles inbound data has access to the file system, the keychain, the microphone, the network stack, or other sensitive subsystems, the defect in the parser inherits that access. The blast radius of a parser flaw is bounded by the privilege of the process that contains it, not by the intent of the data. Containment is not a property of the input. It is a property of the host process and the isolation around it. If the host process is privileged, the parser is privileged, and a defect in the parser is a privileged defect.

The structural drift is that input handlers accumulate parsing surface over time. Formats grow. Codecs are added. Protocol fields are extended. Each addition is a new path that must be exercised under hostile input. The exposure is not static. It expands with every feature that increases what the device will accept and process without user involvement. Whether each addition was reviewed against hostile input for any specific product is not confirmed without explicit vendor disclosure. What is logically necessary is that surface growth without matching review growth produces unenforced trust boundaries.

The same mechanism appears anywhere an automated handler accepts untrusted input and produces internal state changes before a user decision. Mail clients that pre-render inbound messages. Messaging applications that decode inbound media before display. Background services that process push payloads. Protocol stacks that parse fields before authentication. Each of these is an input path that runs before the user is involved. Each carries the same structural condition: data arrives, code runs, no consent occurs.

The pattern extends to machine-to-machine paths with the same property. Any service exposed to the network that accepts requests, parses them, and acts on them before validating the source is operating under the same condition. Authentication enforced later in the flow does not remove the parser exposure earlier in the flow. Code that runs before authentication is code that runs on attacker-controlled input. The trust boundary is set by what the process touches before it decides whether the input is allowed, not by what it touches after.

This is the same mechanism, not a similar one. The user is not in the loop. The parser is the boundary. The privilege of the host process is the blast radius. Any system that meets those three conditions carries the same exposure regardless of form factor. Phone, workstation, server, router, embedded controller. The class is defined by the structure of the input path and the privilege of the process that owns it, not by the category of the device.

User behaviour is not a control for this class. Awareness, hygiene, and link discipline operate on decisions the user makes. In a zero-click chain there is no decision. Defences that depend on user action do not apply, and presenting them as relevant for this class is misdirection. The enforcement point is the code that handles the input, the privilege it runs at, and the isolation around it. Treating the user as a control where the user is not in the path is a design error, not a training gap.

What must be true: input-handling code must be treated as a privileged trust boundary. Its surface must be minimised, its process must be isolated from the rest of the system, it must run at the lowest privilege the function requires, and vendor fixes for it must be applied without delay. The patch cycle is the control. Delay in applying a vendor fix is delay in closing the only boundary that matters for this class. Where a fix has not shipped, the remaining controls are reducing exposure by disabling or restricting the affected input path, where the platform supports that.

Identity is the boundary for user-driven attacks. For input-driven attacks, the boundary is the parser and the process that contains it. The operator position is that any device exposed to unsolicited input is running attacker-reachable code continuously, and the durable defence is reducing what that code can do when it fails. Controls that do not stop the behaviour are not controls. The presence of a vendor patch is not enforcement. The application of that patch is. Anything else is a statement of intent, not a state of the system.