Clarissa Hana
The domain, commonly employed by developers as a stand-in for arbitrary external websites, APIs, or services—akin to the IANA-reserved example.com—has become a potent vector for cyber threats. Unlike example.com, example.net, and example.org, which are specifically protected by the Internet Assigned Numbers Authority (IANA) for documentation purposes and cannot be registered, third-party.com is a fully registered domain whose content is controllable by its owner. This crucial distinction has allowed threat actors to repurpose it for malicious ends.
The Anatomy of the ClickFix Attack
The exploitation of third-party.com was first brought to light by Manifold Security, who discovered the malicious activity while scrutinizing public AI skills and MCP server documentation that referenced the compromised domain. BleepingComputer has since independently verified the attack, confirming that visitors to third-party.com are presented with a convincing, albeit fake, Cloudflare "Performing security verification" screen. This page features a "Verify you are human" prompt.
Upon clicking the verification checkbox, the website executes a deceptive maneuver: it copies a malicious PowerShell command into the user’s Windows Clipboard. Subsequently, the page instructs the unsuspecting user to press the Windows key + R, paste the copied command using Ctrl+V, and then press Enter. This manual execution step is the hallmark of a ClickFix attack, a technique designed to bypass traditional security measures by leveraging user interaction.
Once executed, the PowerShell command reconstructs a payload URL, elxxvvx[.]xyz/f. It then proceeds to download and execute a PowerShell script from this address. The ClickFix methodology is particularly insidious because it disguises malware distribution as a user-initiated action. By requiring the victim to manually paste and run a command, attackers can often circumvent detection mechanisms that monitor direct file downloads or email attachments. This can allow malware to be installed without triggering immediate alerts from endpoint security solutions.
Payload Evolution and Detection
At the time of BleepingComputer’s initial investigation, the elxxvvx[.]xyz domain was no longer resolving, indicating a temporary disruption in the current attack chain. However, a Hybrid Analysis report dated May 2, 2026, provides crucial insight into the campaign’s past activities. This report details a PowerShell script distributed by the site that was configured to download a substantial 134MB ZIP archive from https://elxxvvx[.]xyz/update2.zip.
The script would save this archive as update26.zip, extract its contents, and then attempt to launch an executable named draw.io.exe. Due to the unavailability of the update2.zip archive, the precise nature and function of this payload remain undetermined. However, the substantial size of the archive suggests it could contain a variety of malicious software, from information stealers to ransomware.
Targeted Exploitation and Platform Specificity
A significant aspect of this attack is its deliberate targeting of Windows users. According to Ax Sharma of Manifold Security, visitors to the malicious site using macOS or Linux operating systems encounter a different, non-malicious outcome. Instead of the clipboard poisoning and payload execution, these users are presented with an error message stating, "macOS is not supported. This website requires a Windows PC to access."
Sharma elaborates on this strategic approach: "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." This platform-specific targeting is a sophisticated defense against automated security scanning and casual reconnaissance, making the attack more elusive. By ensuring that only Windows users are exposed to the malicious payload, attackers minimize the chances of detection by security tools that may not emulate specific user agents or operating systems.
A Placeholder’s Perilous Transformation
The choice of third-party.com as the attack vector is particularly noteworthy due to its widespread and long-standing use as a generic placeholder in developer documentation across the web. For years, technical writers and developers have incorporated this domain into examples, specifications, and code snippets to represent any external entity without using a real, potentially active, domain.
For instance, the World Wide Web Consortium (W3C) Geolocation specification has historically used third-party.com in examples demonstrating how to grant geolocation permissions to an external iframe. Similarly, the W3C Compute Pressure specification has employed the domain when illustrating how websites can enable the API for remote content. The Chromium project’s documentation for its Telemetry Extension API also lists third-party.com as an example website permitted to communicate with a Chrome extension.
Furthermore, online repositories and discussions reveal instances where developers have copied these placeholder URLs directly into their code, sometimes even for network requests. A 2015 Stack Overflow question highlights a developer who inadvertently applied an asynchronous loading example containing https://third-party.com/resource.js to their live website, only to discover unexpected behavior post-publication.
While these instances do not imply that the associated projects or documentation are inherently compromised, they create a significant risk. Applications, test code, or even live websites that have incorporated these placeholder URLs could inadvertently direct browsers or automated tools to contact the actual third-party.com domain, thereby triggering the ClickFix attack.
The Absence of IANA Protection
The vulnerability of third-party.com stems from its lack of the specific protections afforded to domains like example.com. The IANA explicitly reserves example.com and its subdomains for use in documentation and examples, preventing their registration or transfer. This ensures that these domains cannot be hijacked or misused. third-party.com, however, has no such safeguards. It is a registered domain, and its control has evidently changed hands at some point, enabling its repurposing for malicious ClickFix attacks.
Manifold Security’s analysis underscores the widespread nature of this practice: "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."
Despite its current malicious use, the third-party.com domain was initially registered in 1996, long before the current malicious campaign. The exact timeline and method by which control of the domain shifted to its current operators remain undetermined. There is currently no evidence to suggest that the domain was initially registered with malicious intent.
Broader Implications and Future Threats
As of the latest reports, there have been no confirmed instances of these references to third-party.com directly resulting in ClickFix attacks being executed on developers’ devices or within their applications and webpages. However, the ongoing availability of the domain presents a persistent threat. Attackers could easily pivot to a new, active payload domain, re-engaging the campaign and potentially targeting a wider audience.
The incident serves as a stark reminder of the evolving threat landscape and the critical importance of vigilant security practices within the software development lifecycle. Developers and security professionals are urged to:
- Review and Sanitize Code: Conduct thorough code audits to identify and replace any instances of placeholder domains, particularly
third-party.com, with safe, non-functional alternatives or properly configured test environments. - Understand Domain Registration: Recognize the difference between IANA-reserved domains for documentation and standard registered domains. Avoid using the latter in production or sensitive code examples.
- Educate Development Teams: Foster awareness among developers about the risks associated with using generic placeholders in code, especially in publicly accessible repositories or documentation.
- Implement Robust Security Solutions: Ensure that endpoint security solutions are up-to-date and capable of detecting and mitigating fileless malware and command-line execution-based attacks.
- Monitor for Emerging Threats: Stay informed about new attack vectors and techniques, such as ClickFix, to proactively adapt security strategies.
The hijacking of a seemingly innocuous documentation placeholder like third-party.com highlights a clever and concerning tactic by cybercriminals. It leverages the trust and widespread adoption of certain coding practices to create a highly deceptive and potentially damaging attack vector. The cybersecurity community will continue to monitor the situation and adapt defenses against such sophisticated social engineering and technical exploitation methods.
