A commonly referenced placeholder domain in technical documentation has become a vector for ClickFix attacks targeting Windows systems. The third-party.com domain, long treated as a generic example hostname for representing external APIs and services in code samples and specifications, is currently serving a fraudulent Cloudflare security verification page designed to manipulate users into executing malicious commands.
Manifold Security identified the malicious activity while reviewing public AI skills and MCP server documentation that referenced the domain. The fake verification page mimics a Cloudflare "Performing security verification" CAPTCHA screen with a "Verify you are human" prompt. Once clicked, the page copies a malicious PowerShell command to the Windows Clipboard and instructs users to press Windows key + R, paste using Ctrl+V, and press Enter.
The PowerShell command reconstructs a payload URL pointing to elxxvvx[.]xyz/f, downloads a script from that address, and executes it. This approach, known as ClickFix, leverages fake errors and verification prompts to convince victims to manually run attacker-supplied commands. The technique bypasses traditional security measures since malware executes through user action rather than direct download or email attachment mechanisms.
During testing, the elxxvvx[.]xyz domain no longer resolved, breaking the current attack chain. However, a Hybrid Analysis report from May 2, 2026, documented the site distributing a PowerShell script configured to download a 134MB zip archive from https://elxxvvx[.]xyz/update2.zip. The script saved the archive as update26.zip, extracted it, and attempted to launch an executable named draw.io.exe. The archive is no longer available, preventing analysis of the final payload.
According to Manifold's Ax Sharma, the attack specifically targets Windows users. "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," Sharma explains. "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."
A placeholder without reserved status
The choice of third-party.com as the attack host highlights a critical distinction in domain reservation practices. Unlike example.com, example.net, and example.org—which IANA reserves exclusively for documentation purposes—third-party.com is a standard registered domain whose content is controlled by its owner.
Developer documentation across major projects has used third-party.com as a generic example hostname for years. The W3C Geolocation specification demonstrates granting geolocation permissions to external iframes using the domain as a placeholder. The W3C Compute Pressure specification similarly employs it when showing how to enable APIs for remote content. Chromium's Telemetry Extension API documentation uses third-party.com as an example website permitted to communicate with Chrome extensions.
Some examples extend further, incorporating the domain into code that would execute actual network requests if copied directly. A PrivacyCG proposal on GitHub uses the domain as the destination for a JavaScript fetch() request from a service worker. A 2015 Stack Overflow question documented a developer who had applied an asynchronous loading example containing https://third-party.com/resource.js to their website before discovering unexpected behavior after publication.
A public code search reveals the domain appearing in skills, MCP-server documentation, and over 1,500 files across 1,700+ repositories from organizations including Chromium, Sanity, and Vercel. According to Manifold, "third-party[.]com has been a generic documentation placeholder for years, the same role example.com plays. Since at least June 2026 it's been serving the ClickFix lure."
These documentation references do not indicate compromise of associated projects. However, applications or test code that copied such placeholder URLs could now cause browsers or automated tools to contact the actual third-party.com domain and potentially encounter the ClickFix attack.
Domain history and ongoing risk
The third-party.com domain was first registered in 1996, predating the current malicious campaign. BleepingComputer has not determined when or how control of the site changed hands. No evidence suggests the domain was originally registered for malicious purposes.
Currently, no reports indicate that references to third-party.com in documentation have resulted in ClickFix attacks being executed on developer devices or within applications and webpages. However, with the domain remaining active and under attacker control, it could be repurposed with a new live payload domain for future attacks at any time.