A homepage visit now runs PowerShell on your machine

Opening Claim

Gizmodo’s homepage is serving a ClickFix attack. The mechanism is specific: a pasted URL fetches malware through Windows PowerShell. The homepage is not hosting a writeup of this technique. It is demonstrating a readily exploitable vulnerability on a public, internet-facing content surface.

Separate what the page is from what it is doing. A homepage is a content surface. It exists to render text and media inside the browser. In this condition it is also functioning as a delivery surface for shell execution. The payload does not detonate in the browser. It runs in PowerShell, inside the user’s own session, with the user’s own privileges. The browser’s controls do not extend to that location.

Hold the scope to confirmed facts. Confirmed: a ClickFix attack served from the homepage, a paste-driven URL, and a PowerShell fetch of malware. Not confirmed: how the homepage came to serve this, how many visitors were exposed, whether any single visitor completed the paste and executed the payload, and how long the condition has existed. Those are not gaps to be filled with assumed attacker behaviour. They are conditions marked as not confirmed. Accuracy here overrides completeness.

The Original Assumption

The design assumption under this surface is that loading a publisher’s homepage is a passive read. Content renders, scripts run inside the browser sandbox, and nothing reaches the operating system without a further, explicit decision that the browser itself mediates. Under that assumption the browser is the boundary, and the boundary holds because execution stays inside it.

The second assumption is about the clipboard. Paste is treated as a user-controlled, inert action. Copy is treated as benign. The assumption is that content a page places on the clipboard cannot, on its own, become execution. ClickFix targets exactly this. It turns the clipboard into a transport between a web page and a command interpreter, and it turns a paste into the user’s unwitting consent to run a command.

The third assumption is about identity. PowerShell runs as the user. The gap between viewing a website and running a command as yourself was assumed to be wide and to require intent. The real trust boundary was never the browser sandbox. It was the user’s hands and the shell prompt. Once a workflow routes a page’s instruction into PowerShell through a paste, the browser sandbox is no longer the control that matters, because the execution has already left it.

What Changed

The execution context moved out of the browser. This attack does not need to exploit a browser flaw. It uses the user as the transport. The malicious instruction travels from the page, to the clipboard, to PowerShell. That path is logically required by the stated mechanism: if a pasted URL fetches malware through PowerShell, the browser is not the engine running the payload. The user and the shell are.

The enforcement point moved with it. Browser controls, the sandbox and same-origin handling, do not enforce on text pasted into a shell. PowerShell does not validate where pasted text came from or whether a website authored it. The control that could stop this sits at the shell execution boundary, and the facts do not show any control enforced there. URL sanitization at the web layer governs what the page renders. It does not govern what runs in PowerShell after a paste. A control placed on the wrong boundary is not enforcement.

The trust model changed as a result. A trusted publisher’s homepage became an instruction source for the user’s own command interpreter. The user’s privilege became the attacker’s privilege at the moment of the paste, because the fetch runs in the user’s session at the user’s access level. What the payload does after the fetch, beyond fetching malware, is not confirmed. What is confirmed is the boundary that broke: execution crossed from a sandboxed content surface into an unvalidated shell, carried by a single user action.

Mechanism of Failure

The failure is not a single defect. It is a chain of individually permitted actions. The page writes to the clipboard. The clipboard holds the content. The paste delivers it into PowerShell. PowerShell executes the pasted text. Each operation functions as designed. No component is malfunctioning, and the stated facts contain no browser exploit because none is required. The drift lives in the assembly. A sequence of allowed behaviors composes into an outcome that no single component was authorized to produce on its own.

The point of failure is the junction where content becomes command. What is externally observable is narrow and sufficient: content placed by the page ends up executing in the shell. Between those two states there is no validation of where the content originated. The clipboard does not carry or enforce provenance. PowerShell receives a string and runs it. It does not distinguish a string the user typed from a string a website authored. That non-distinction is the mechanism. The shell treats authorship as irrelevant because nothing at that boundary is defined to check it.

The candidate control was placed where the content is harmless and is absent where it executes. URL sanitization governs rendering at the web layer. At the web layer the URL is inert text. It becomes execution only after it crosses into PowerShell, and that crossing is downstream of every web-layer control. A control that acts before the dangerous state exists does not constrain the dangerous state. The facts do not show any control enforced at the shell execution boundary. So the only boundary that could have stopped execution is the one with no enforcement on it. That is the definition of an ineffective control. Present at the web layer, absent where it would have mattered.

Expansion into Parallel Pattern

The pattern is wider than this page. The mechanism is a content surface writing executable instructions to a transport the user trusts, and the user carrying them across a boundary that does not validate origin. Strip the specifics and the shape is the user functioning as transport into an unvalidated execution context. Anywhere that shape exists, the same outcome is available. The pattern is derived from the mechanism itself, not from any property unique to this publisher.

The clipboard is a provenance-stripping transport. Once content is on it, its origin is gone. The receiving boundary sees a string, not a source. Any execution surface that accepts clipboard content without validating origin trusts every writer to the clipboard equally, and a web page is a writer to the clipboard. The plainest instance of the identical mechanism is the copy-from-page, paste-into-terminal install step. A page presents a command. The user copies it. The user pastes it into a shell. The shell runs it at the user’s privilege. That is the same path: page to clipboard to shell to execution, with no origin check at the execution boundary. ClickFix is that workflow turned against the user rather than serving them. The component parts are the same. Only the intent of the authored content differs.

The constant across every instance is identity. The shell runs as the user. The execution inherits the user’s privileges because it occurs in the user’s session. The transport elevates nothing and does not need to. It only needs to move an instruction into a context that already holds the privilege. This is why the browser sandbox is not the relevant control. The sandbox constrains code inside the browser. The mechanism routes the instruction to a context outside it, where the user’s own access is the authorization. Identity is the boundary that was crossed, and in the stated path identity is enforced nowhere.

Hard Closing Truth

The browser was never the boundary that mattered here. The shell execution boundary is. Every control named at the web layer acts before the content can execute and therefore cannot govern execution. URL sanitization does not reach the shell. The sandbox does not reach the shell. The facts show no control enforced where the payload actually runs. A control that does not act at the point of execution is not protecting execution. It is protecting a state that was never the threat.

State what must now be true. The execution boundary must validate provenance, or it must treat all clipboard-delivered input to a shell as untrusted by default. Identity must be the enforced boundary, not the assumed one. The distance between viewing a page and running a command as yourself must require something the page cannot supply on the user’s behalf. If the only thing standing between a web page and code execution in the user’s session is the user’s decision to paste, the design has delegated the security boundary to one manual action. One manual action is not a control.

If a system allows it, it will happen. This path is allowed end to end, and it executed. What is confirmed: a trusted homepage became an instruction source for the user’s command interpreter, carried by a paste, running at the user’s privilege. What is not confirmed stays not confirmed. Scope, visitor count, duration, and post-fetch behavior are all not confirmed, and none of them change the conclusion. The conclusion does not depend on how many were reached. It depends on the boundary that broke. Enforce the boundary that runs the code, or accept that the next content surface will do exactly the same thing.