A documentation placeholder domain now serves a ClickFix lure to Windows users
On September 24, 2026, Manifold Security revealed that third-party.com, a documentation placeholder used as an example for years, had been registered by a third party and now serves a ClickFix lure to Windows browsers. Audit your repositories and stop letting a non-reserved domain stand in as an example.
June 2026. The domain third-party.com starts serving a ClickFix lure to Windows browsers while showing a harmless page to everyone else. September 24, 2026. Manifold Security documents the takeover in a report by Ax Sharma and Cody Nash. September 24, 2026. VirusTotal and Google Safe Browsing flag the domain as malicious. Why it matters: a documentation placeholder is a promise that nobody will ever answer. DNS does not honor that promise.
An example that answers, for real
third-party.com played for years the role example.com plays in code samples: a domain you type without thinking, because you are sure it leads nowhere. The difference between the two is decisive. example.com is IANA-reserved: nobody can register it, by construction. third-party.com is not. Anyone could buy it, and someone did.
The consequence is mechanical. Every piece of documentation, every test, every AI agent skill that hard-coded the domain now points, literally, at attacker infrastructure. Ax Sharma, head of research at Manifold Security, describes the pivot: “third-party.com has been a generic documentation placeholder for years, the same role example.com plays. Unlike example.com, third-party.com is not IANA-reserved. Anyone could register it, and someone did. Every doc, test, and skill that hard-coded it now points readers at attacker infrastructure.”
What the Windows victim sees
The trap follows the ClickFix playbook, the most widespread phishing technique of the year. The page shows a fake Cloudflare security check that pretends to verify the browser, then poisons the victim’s clipboard and instructs them to open the Windows Run dialog and paste a command. The pasted command downloads and executes a remote PowerShell payload.
The ruse is targeted. A macOS visitor sees an error: “macOS is not supported. This website requires a Windows PC to access.” The domain operator filters victims by User-Agent header: the target is the Windows machine, while macOS gets a benign decoy so it neither panics nor reports anything.
The clipboard trick has a name: pastejacking. The page silently overwrites the clipboard with a malicious script, so the victim believes they are pasting a harmless check while actually pasting an order. It is a hijacking of trust: the user executes the payload themselves, outside any software vulnerability. No antivirus can intercept a command the victim willingly inflicts on themselves.
The lure itself is well understood by now. The page runs a small script that overwrites the clipboard, so that when the victim opens Run and pastes, they are actually pasting a one-line loader that fetches and executes a PowerShell script. Because the command runs with the user’s own privileges, it bypasses every browser sandbox and every EDR that looks for exploit payloads rather than user-initiated commands.
A placeholder is not an example
The real story is not the lure but what made it possible: the confusion between “example domain” and “reserved domain.” Developers got into the habit of using plausible domains — yourcompany.com, myapp.com, vendor.com — to illustrate an address in documentation. Those domains look like examples, but they are registrable, which means they are squattable.
Manifold Security counted 1,700 public repositories that reference third-party.com, including AI agent skills and MCP server documentation that cite the domain as an example endpoint. The research then widened the net: thirteen more non-reserved placeholder domains were identified, including yoursite.com and your-domain.com, which already serve scams to macOS visitors — a fake “MacOS Security Center” announcing four viruses and selling a counterfeit McAfee renewal at 55% off, and a fake ZDF article pushing an investment scheme.
The killer detail: these domains pass every static check. A file scanner, a repository analyzer, a code review sees nothing but a harmless string. “You can scan the skill, read the file, resolve the domain from your analysis box, and conclude it is fine, and be completely wrong about what a Windows user’s agent receives when it follows the same link,” Manifold Security warns. The malicious content only exists at request time, and only for the caller that matters. A file scan cannot see what a website decides to send.
AI agents follow links too
The takeover bites hardest because it reaches the AI agent layer. Skills and MCP server documentation cite example domains as endpoints, and an agent executing a task can end up resolving that domain for real. Manifold Security is blunt about it: a file scan concludes everything is fine, but it cannot see what a site decides to send at request time. The malicious content exists only for the caller that matters.
The consequence goes beyond plain phishing. Documentation that points at a squatted domain becomes a prompt injection vector: an agent that reads an example endpoint and follows it can receive, in return, instructions meant to redirect it — not just a payload. The boundary between “harmless example” and “attacker infrastructure” has moved to DNS, a layer almost no one watches day to day.
The mechanics are worth stating plainly, because they are the root cause. The IANA maintains a short list of reserved second-level domains — example.com, example.net, example.org — that exist precisely so documentation has a guaranteed-dead endpoint. Everything else is fair game. A placeholder like third-party.com was never protected by any registry rule; it was protected only by the assumption that nobody would bother. Once a single person bothered, every reference to it flipped from dead to live overnight, and no one who had written it was notified.
The same trap, at wider scale
Manifold Security identified thirteen non-reserved placeholder domains beyond third-party.com, and two are already active. yoursite.com shows a fake “MacOS Security Center” announcing four viruses and selling a counterfeit McAfee renewal at 55% off, while your-domain.com serves a fake ZDF news item pushing an investment scheme. The full list — yourdomain.com, your-site.com, yourapp.com, myapp.com, acme.com, company.com, vendor.com, foo.com — passes every static check.
The phenomenon is not isolated. An abandoned CDN domain was recently re-registered, and thousands of sites still call it without knowing. Each time the scenario is the same: a domain name thought dead comes alive in the wrong hands, and the code that referenced it becomes an entry point. That is the textbook definition of a supply chain problem at the DNS layer.
Verdict
If you maintain documentation, code samples, skills, or tests, replace every placeholder domain with a reserved one — example.com, example.org, example.net. Those are the only domains that cannot be registered, and therefore the only ones that cannot become an entry point. If you have already hard-coded a plausible domain, audit your repositories now: a grep -R "your.*\.com" across your READMEs and config files is a start, then treat every non-reserved domain as squattable by construction. If you manage a Windows fleet, the risk is indirect but real: a user following a documentation link from a non-isolated machine can paste a command — remind them that the Run dialog never has to execute anything pasted. The fix is not a patch, it is a convention: an example must be reserved, or it becomes an entry point.