Developers have long used third-party.com as a generic placeholder in documentation, test scripts, and sample APIs. Starting in mid-2026, that apparently harmless domain has been transformed into live malware infrastructure, serving a ClickFix lure to Windows users while showing benign content to others. Security researchers discovered the domain has become a malicious point of entry across over 1,700 public repositories.
Placeholder Becomes Attack Surface
Usually, placeholder domains like example.com are officially reserved by IANA, so they can’t be registered or controlled by third parties. But third-party.com was never reserved. That meant anyone could register it—and someone eventually did. That registration has turned countless documentation and code snippets into live pointers straight to attacker-controlled assets.
Manifold Security’s research shows that, since at least June 2026, the domain has been delivering a ClickFix social engineering attack. When Windows users visit the page, they see a fake “Cloudflare check,” which secretly poisons the clipboard and instructs them to paste and run a command in the Windows Run dialog. That command pulls down and executes a remote PowerShell payload. macOS users get a different treatment: a message claiming the site requires Windows, with instructions to try again from a Windows device.
Widespread Exposure, Hidden Danger
A GitHub scan revealed over 1,700 public repositories have hard-coded links to third-party.com—often appearing as example endpoints in agent skills, server docs, and tests. Because developers assumed the domain was safe (as a placeholder), many never considered the risk that it could be live and malicious. What a static file review sees in these cases doesn’t reveal the live payload—only what’s delivered to visitors determines the danger.
Manifold Security also identified 13 other non-reserved placeholder-style domains now being abused. Two of those—yoursite.com and your-domain.com—are actively delivering scareware or investment fraud pages when visited from macOS browsers, while showing innocuous “parking” pages to other visitors. Other domains are similarly listed (like foo.com, company.com, vendor.com, etc.), many present in thousands of files and agent skills.
Prevention and Mitigation
To avoid this kind of risk, teams dealing with documentation, samples, or test code should audit whether their placeholder domains are truly safe. Any non-IANA-reserved domain that looks plausible to a developer should be assumed squattable and potentially abused. It’s strongly advised to use only reserved placeholder domains such as example.com, example.org, and example.net, which remain safe because they cannot be registered.
This episode also underscores why static analysis alone isn’t enough: what a homepage or static file shows isn’t what the users behind browser requests may receive. Risk appears only when the site is live and behavior depends on the type of visitor.
IT teams and security engineers should survey public and internal repos for any non-reserved placeholder domains, replace them where possible, and incorporate checks into CI/CD pipelines. Also, domain registration monitoring and threat hunting for suspicious placeholder domains can reveal abuse early.
What this means: developers shouldn’t treat any placeholder domain as inherently safe. What looks like an example now could be compromised and multiplied in production code, giving attackers a hidden channel into PowerShell tricks, clipboard poisoning, or worse. The community should take this as a warning to tighten documentation hygiene and update old sample code before its hazards become active threats.
