The discovery that third-party.com, a domain widely used for years as a generic placeholder in developer documentation and code examples, is now serving a ClickFix attack targeting Windows users highlights an unusual but important software-security risk.

The problem is not that the affected documentation itself was compromised.

The problem is that developers treated a normal, registrable Internet domain as though it were a permanently harmless placeholder.

That assumption eventually stopped being true.

Security researchers at Manifold discovered that Windows visitors to third-party.com were being shown a fake Cloudflare verification page designed to convince them to execute a malicious PowerShell command.

Meanwhile, macOS and Linux visitors received a harmless-looking error instead.

This conditional behavior makes the campaign particularly interesting because the malicious content is shown only to the operating system it is designed to infect.

The attack begins with a fake Cloudflare verification

When a Windows user visits the domain, the page displays what appears to be a Cloudflare security check.

The visitor is asked to click a verification checkbox and then follow instructions involving:

Windows Key + R → Ctrl+V → Enter

Behind the scenes, JavaScript has already placed a PowerShell command into the user's clipboard.

When the victim follows the instructions, they paste and execute the attacker's command themselves.

The command retrieves another PowerShell script from attacker-controlled infrastructure and executes it.

This technique is known as ClickFix.

Instead of exploiting a browser vulnerability, the attacker convinces the user to execute the malicious command manually.

That distinction makes the attack particularly effective against traditional security assumptions.

The victim becomes part of the execution chain

ClickFix attacks are successful because the malicious action appears to be part of a legitimate verification process.

The victim is not asked to download an obvious .exe file.

They are not presented with a conventional malicious attachment.

Instead, they are told they need to perform a routine-looking troubleshooting or verification action.

The sequence effectively becomes:

fake verification → clipboard poisoning → user opens Run → malicious command pasted → PowerShell downloads payload → malware executes

The attacker uses legitimate Windows functionality to perform much of the installation.

This demonstrates why security awareness training needs to evolve beyond:

“Do not click suspicious links.”

A much more useful rule is:

A legitimate website should never require you to open the Windows Run dialog, PowerShell, Terminal, or Command Prompt and paste a command simply to prove that you are human.

The second-stage infrastructure was already associated with malware delivery

BleepingComputer found that the PowerShell command reconstructed and contacted:

elxxvvx[.]xyz

At the time of testing, that second-stage domain was no longer resolving, so the current attack chain could not complete.

However, historical analysis from May 2026 showed the infrastructure previously serving a PowerShell script that attempted to download a roughly 134 MB ZIP archive named:

update2.zip

The script extracted the archive and attempted to execute:

draw.io.exe

Because the archive was no longer available, researchers could not determine the final malware payload.

That uncertainty should be preserved.

The evidence clearly establishes malicious delivery behavior, but the final malware family has not been confirmed.

Windows users receive the weapon, while scanners may see nothing

One of the more sophisticated aspects of the campaign is its operating-system filtering.

Windows user agents receive the malicious ClickFix code.

macOS and Linux visitors receive a similar-looking page stating that the operating system is unsupported.

They do not receive the clipboard-poisoning code or malicious PowerShell command.

This creates a significant detection problem.

A reputation service or automated security scanner running from a Linux server may visit the exact same domain and see nothing malicious.

A Windows user visits a few seconds later and receives the attack.

Manifold observed that the domain had previously been added to a malware blocklist and later removed, which researchers believe is consistent with this type of selective delivery.

The lesson is important:

A domain reputation check tells you what the site showed the scanner, not necessarily what it will show the intended victim.

The deeper problem is the domain itself

The most unusual part of this campaign is why third-party.com receives traffic in the first place.

Developers have historically used it as a generic example for an external site, API, or service.

It appears conceptually similar to:

example.com

But there is one crucial difference.

example.com, example.net, and example.org are specifically reserved by IANA for documentation and examples.

They cannot simply be registered by an unrelated party and converted into malicious infrastructure.

third-party.com has no such protection.

It is an ordinary registered domain.

Its operator controls what the domain returns.

That technical difference turns what looks like an innocent documentation choice into a long-term security dependency.

Thousands of repositories contain references to the domain

Manifold's public-code search found third-party.com referenced across more than 1,500 files in over 1,700 repositories.

Researchers identified references associated with projects and documentation from organizations such as:

  • Chromium;
  • Sanity; and
  • Vercel.

The domain has also appeared in:

  • AI agent skills;
  • MCP server documentation;
  • developer guides;
  • test fixtures;
  • OAuth examples;
  • iframe examples; and
  • sample JavaScript code.

This does not mean those projects have been compromised.

In most cases, the authors simply used the domain as an illustrative placeholder.

The vulnerability lies in the assumption that the placeholder would remain harmless forever.

Static documentation can become dynamic attack infrastructure

This incident illustrates an unusual kind of supply-chain problem.

Normally, software supply-chain security focuses on dependencies that change:

  • a package receives a malicious update;
  • a maintainer account is compromised;
  • a JavaScript library changes ownership;
  • a container image is poisoned.

Here, nothing in the referring documentation needed to change.

The URL remained exactly the same.

What changed was the content being served at the destination.

The dependency effectively became:

static reference → mutable remote infrastructure

That is a dangerous combination.

A README written five years ago can still point at today's attacker-controlled server.

Code examples make the problem worse

References in documentation are concerning enough.

The risk becomes greater when sample code performs actual network requests.

For example, documentation might contain something conceptually similar to:

fetch("https://third-party.com/api")

or:

<script src="https://third-party.com/widget.js"></script>

Developers frequently copy sample code into applications and modify it later.

Sometimes the placeholder survives.

A historical Stack Overflow post cited in the research describes a developer who copied an example using third-party.com/resource.js into a real site before discovering that it behaved unexpectedly.

This demonstrates why example domains should be deliberately non-dangerous.

A placeholder should fail safely when copied accidentally.

It should not make a network request to infrastructure controlled by an unknown third party.

AI agents make stale documentation references even more consequential

The emergence of AI agents and MCP servers adds another dimension.

Humans may recognize that a URL in documentation is merely an example.

An automated agent may not.

An agent reading:

https://third-party.com/widget.js

may attempt to fetch it because the documentation appears to instruct it to do so.

That means URLs embedded in AI skills, instructions, documentation, or MCP configuration can behave like latent external dependencies.

A domain that was harmless when the skill was written can become malicious later.

The skill itself remains unchanged.

This creates a particularly interesting security problem for agentic systems:

static instructions may cause dynamic network behavior long after the instructions were reviewed.

This resembles domain-expiration and dependency-takeover attacks

The underlying security pattern is familiar even if the manifestation is unusual.

Organizations have previously been compromised when:

  • expired domains referenced by JavaScript were re-registered;
  • abandoned CDN domains changed ownership;
  • expired DNS names were taken over;
  • dependencies pointed to infrastructure no longer controlled by the original developer.

The security mistake is the same:

Trust was attached permanently to a resource whose ownership was temporary.

Any externally controlled URL embedded permanently into software, configuration, or documentation should therefore be treated as a dependency.

There is no evidence the original domain registration was malicious

It is important not to overstate the attribution.

The domain was first registered in 1996, decades before the current campaign.

BleepingComputer has not determined exactly when its infrastructure or control changed, nor is there evidence that the domain was originally registered for malicious purposes.

What is established is that the domain is currently capable of serving malicious ClickFix content to Windows visitors.

That distinction matters because the security issue is not necessarily malicious intent dating back decades.

It is the failure to recognize that ownership and content of an ordinary domain can change over time.

Developers should use reserved domains for examples

The simplest preventative lesson is also the clearest.

When documentation needs an illustrative domain, developers should use names specifically reserved for that purpose, including:

example.com

example.net

example.org

or the reserved .example namespace.

IANA explicitly maintains these domains so they can safely appear in documentation without later becoming someone else's commercial or malicious infrastructure.

A realistic-looking domain that nobody on the project actually controls should not be used simply because it “looks like a placeholder.”

Existing documentation should be audited

Organizations should search their:

  • source repositories;
  • README files;
  • API documentation;
  • test suites;
  • AI skills;
  • MCP server configurations;
  • tutorials;
  • sample applications;
  • CI/CD configuration; and
  • internal knowledge bases

for third-party.com and similar unreserved placeholders.

The review should not stop with this one domain.

Other examples worth examining include arbitrary names such as:

yourcompany.com

mycompany.com

your-api.com

or other realistic domains used as examples but not owned by the organization.

The important question is:

Could this supposedly fictional hostname actually resolve to someone else's server?

Do not solve the alert by allowlisting the domain

One particularly dangerous response would be to add the domain to an allowlist simply because security scanners repeatedly encounter it in legitimate documentation.

That turns an annoying detection problem into a security bypass.

A live Internet domain outside the organization's control should not become permanently trusted merely because developers frequently use it in examples.

Reputation and allowlisting need to reflect current control and behavior.

Security scanners should test multiple environments

The conditional-delivery behavior also suggests an improvement for security scanning.

A single Linux-based crawler may not see what a Windows endpoint receives.

Security platforms evaluating suspicious websites should consider variation across:

  • operating-system user agents;
  • browser types;
  • geographic locations;
  • residential versus datacenter IP ranges; and
  • different request sequences.

Threat actors increasingly use conditional delivery to prevent scanners from observing malicious content.

Security testing needs to assume that the server may actively choose what evidence to reveal.

ClickFix should be treated as a behavior, not merely a domain IOC

Blocking third-party.com and the identified secondary infrastructure is reasonable as an immediate precaution where it does not break required workflows.

But defenders should focus on the broader behavioral pattern.

Useful endpoint detections include:

  • browser activity followed by Win+R;
  • PowerShell launched immediately after browser interaction;
  • PowerShell using Invoke-RestMethod;
  • PowerShell using Invoke-Expression;
  • clipboard-derived commands;
  • suspicious child processes launched shortly after PowerShell;
  • large archives downloaded into temporary directories; and
  • executables launched from freshly extracted archives.

The domain used today can change tomorrow.

The ClickFix workflow remains recognizable.

The bigger lesson for software supply-chain security

This incident expands the traditional definition of a dependency.

A dependency does not necessarily have to appear in:

package.json

requirements.txt

or a container manifest.

A hardcoded URL in documentation can also become a dependency if humans, applications, or AI agents eventually follow it.

The chain here is remarkably simple:

developer writes harmless example → example uses real registrable domain → documentation spreads for years → domain behavior changes → old documentation now points toward attacker infrastructure

Nobody needs to compromise the documentation repository.

Nobody needs to alter the code example.

Nobody needs to publish a malicious package update.

The trust relationship decays entirely outside the project.

The broader cybersecurity lesson

The third-party.com ClickFix campaign demonstrates why developers should never use arbitrary real-world domains as permanent placeholders.

The domain looked generic.

The references looked harmless.

The documentation did not change.

But the security properties of the destination did.

The issue becomes even more significant as AI agents increasingly consume documentation and act on URLs automatically.

Humans may understand that a hostname is illustrative.

Machines may simply follow it.

A placeholder should be intentionally incapable of becoming hostile.

That is precisely why reserved documentation domains exist.

The lesson is almost painfully simple:

If a URL is meant to represent nowhere, make sure it cannot someday belong to someone.

Otherwise yesterday's harmless code example can quietly become tomorrow's malware-delivery path, while every repository containing it remains byte-for-byte identical.

The "third-party.com" domain, commonly used as a placeholder in developer documentation and code examples, is serving a fake Cloudflare verification page that attempts to trick Windows users into executing PowerShell commands. [...]

Source: Placeholder domain used in dev docs now serves ClickFix attacks via Bleeping Computer — published 23 Sep 2026.