Only 2 of 40+ ClickFix incidents are confirmed custom GPT lures

Two of at least 40

Huntress's report of 28 September 2026 counts at least 40 incidents that trace back to one fake verification page hosted on Google Sites, and says it confirmed that two of them came through a custom GPT on chatgpt.com. Two of at least 40 is a confirmed share of at most 5 per cent (derived: 2 divided by 40). The headlines say that custom ChatGPTs push ClickFix attacks. The record says a small confirmed share did, and that in some of the incidents the route began with a sponsored Google result for the search term "chatgpt".

What that does not establish. It does not establish how many people were infected: the number Huntress gives is incidents in its own customer base, and SecurityWeek restated it as at least 40 users infected. It does not attribute the campaign to anyone. It does not show that OpenAI's platform hosted anything beyond the lure: on Huntress's account the custom GPT page carried one prepared message and a link, and the command sat on a Google Sites page. It does not say how many ads ran, who bought them, or whether any are live. And it does not tell us whether the second custom GPT, still active when Huntress published, is up now.

What the record fixes and what it leaves open

Huntress is the only primary source for the campaign. BleepingComputer, SecurityWeek, Help Net Security and Security Affairs all rest on its report; none of the four quotes OpenAI or Google. The table separates what Huntress states from what it does not.

Huntress report, 28 September 2026, read in full on 30 September. "Not stated" means the report is silent, not that the answer is no.

Question	On the record	Not stated
How many incidents?	At least 40 tied to one Google Sites page, from the Huntress SOC. Two confirmed as coming through a custom GPT.	How many of the other 38 or more came from ads, other GPTs or elsewhere. How many people. Anything outside Huntress customers.
Which custom GPTs?	Two, both titled "Plus 5.6". The first was taken down as of 25 September. The second was found on 27 September and was still active at publication.	Who built them, on what kind of account, when they were created, how long each was reachable, whether the second is down now.
What about the ads?	Victims searched Google for "chatgpt" in some incidents. The first GPT's landing address carried Google Ads click parameters, which Huntress reads as a paid click.	Number of ads, the advertiser, the ad text and display address, run dates, any Google action. No ad evidence is given for the second GPT.
Where did each piece sit?	The GPT page and its reply on chatgpt.com. The fake check and command on sites.google.com. The installer on a server addressed by number, over plain HTTP.	Whether the GPT's configuration held anything beyond the one message. Whether the Google Sites page is down.
Who did it?	"Threat actors". The operators ship a maintained framework, in Huntress's words, rather than a one-off build.	Any named group, country or motive.

Where the trust boundary was crossed

Huntress describes five hops. A person searches Google for "chatgpt" and clicks a sponsored result. The landing address is a custom GPT page on chatgpt.com, titled "Plus 5.6" and attributed to a "community builder". Whatever the person types, the GPT answers with one prepared "Service Availability Notice" that offers an upgrade to Plus or a "backup domain". The backup domain is a Google Sites page that imitates a Cloudflare check and asks the person to paste a command. The command runs PowerShell, which fetches an installer, which starts a legitimately signed application that loads a remote access trojan.

Five-step chain from a sponsored Google result to a remote access trojan. Under each step: who hosts it, who wrote it, the label the reader sees, and what could have seen it. The third-party review columns say not stated. The fourth step, the command the person runs, is highlighted as the boundary that mattered. — Drawn from the Huntress report of 28 September 2026, text and Figures 1 to 3. Where the report is silent the diagram says not stated.

Every hop but the last asked the person to read; the last asked them to run something. That is the boundary that mattered: the moment reading became running. Everything before it was a label.

First, chatgpt.com hosted the lure. BleepingComputer writes that in both attacks the malicious instructions are hosted on the legitimate ChatGPT.com domain. That is accurate for the shared-conversation attacks Huntress described earlier, and it reads as if it covers this one as well. In this campaign, on Huntress's account, the ChatGPT page held a message and a link, and the command was on the Google Sites page. A defender scoping a block or a hunt needs that difference. What the report cannot tell us is whether the GPT's configuration held anything more.

Second, the boundary that matters in your estate is not between the internet and OpenAI. It is between a web page and the Run dialog or a terminal window. Microsoft describes ClickFix as a technique that gives the user instructions to copy, paste and run commands in the Run dialog, Windows Terminal or PowerShell, and notes that because it relies on human action it can get past conventional automated tools. Our earlier briefings on the technique cover a documentation placeholder domain that now serves a lure, a lure panel whose 79 completions did not show that anything ran and three filters that each hand a scanner a clean page. This one adds an AI vendor's domain to the chain.

Four labels, none of them a control

A label tells you where something is hosted or who signed it. It does not tell you who wrote it or what it will do. The lure used four, and the table sets each against what it actually established.

Labels the person could see, from Huntress's text and screenshots. Assessment of what each does and does not establish is ours.

Label the person saw	What it establishes	What it does not establish
A sponsored result for "chatgpt"	That someone paid for placement at the top of the results.	Who paid, what the ad claimed, or anything about the destination's author.
The chatgpt.com address, in the ChatGPT page layout	That the page is served from OpenAI's site.	That OpenAI wrote it. The page said "By community builder", which Huntress calls a tip-off only to someone who knows what a custom GPT is.
A page naming chatgpt.com and Cloudflare, with a tick box	Only that the page is on Google's Sites service: the address bar read sites.google.com.	That Cloudflare, OpenAI or Google had any hand in the text.
A valid signature on the host application	That the executable is the vendor's genuine file, as Huntress says of the Canon and Stardock hosts.	That it runs from where the vendor installs it, or that the library beside it is genuine. Huntress annotates both hosts "do not block globally".

The lure title did the same work. "Plus 5.6" borrows the name of a subscription tier that OpenAI's own help pages list (Free, Go, Plus, Pro) and adds a version-style number, and the prepared reply offered the upgrade to Plus as option one. The pretext is an upsell prompt, which is a message people already expect from the product.

This is not an OpenAI problem alone. Huntress has reported the same shape on other vendors' domains:

July 2026: a victim searched Google for how to install Claude on a Mac, clicked a sponsored result and landed on a shared conversation on claude.ai badged as shared by Apple Support (Huntress, 17 August 2026).
July 2026: a malicious Claude Artifact on claude.ai, reached by searching Bing for the Claude desktop app, redirected to an external domain that delivered a different remote access trojan. Huntress says Anthropic removed it by 22 July, and that incidents tied to the same redirect domain continued into August (a piece BleepingComputer ran on 11 September, labelled sponsored by Huntress).
December 2025: search-promoted shared ChatGPT and Grok conversations that gave ClickFix-style advice (Huntress).

In each, the platform was not breached. The platform's domain was used to carry a stranger's content, and the domain was the only reassurance on offer. Our briefing on a fake Claude Max giveaway makes the same point about a brand as a pretext.

The dates, and what the gaps show

Every interval below is our arithmetic from dates in the Huntress report, OpenAI's help pages and the BleepingComputer page metadata. Where Huntress gives only a date, the diagram marks the position as approximate.

Timeline from 22 to 30 September 2026 drawn to scale by hour. Huntress's delivery-server activity runs from 22 September 16:41 UTC to 27 September 20:58 UTC, 5 days 4 hours 17 minutes. The first custom GPT was down as of 25 September, a second was found 27 September, Huntress published 28 September, BleepingComputer on 29 September, and this article on 30 September. Date-only events are hollow markers. — Drawn from Huntress Figure 19 and text, BleepingComputer page metadata, and OpenAI's Help Center. Date-only events are placed at midday UTC.

Intervals derived from the sources. Not stated means the sources give no date.

Interval	Length (derived)	What it does and does not show
First to last row of Huntress's delivery-server timeline	22 Sep 16:41 to 27 Sep 20:58 UTC: 5 days 4 h 17 min	The window of activity in the rows shown. Not the campaign's start or end, and not how long any GPT was reachable.
Earliest server activity to the first GPT being down	22 Sep to "as of" 25 Sep: up to 3 days	The first GPT was gone no more than about three days after the earliest server activity Huntress saw. When the GPT was created, when the first ad ran and when OpenAI was told are not stated.
First GPT down to second GPT found	"As of" 25 Sep to 27 Sep: at least 2 days	A replacement was found at least two days after the first was removed. Its creation date is not stated.
First GPT down to Huntress publishing	"As of" 25 Sep to 28 Sep: at least 3 days	The first GPT was removed before the report appeared. The second was not, at publication.
Report to news story	28 Sep to 29 Sep, 16:59 EDT (21:59 BST)	BleepingComputer's page metadata gives the time. Huntress's page gives the date only.
Now to OpenAI's stated retirement of GPT pages	30 Sep to 11 Dec 2026: 72 days. To 11 Feb 2027: 134 days	11 December is the standard date. 11 February 2027 applies to Enterprise workspaces with an approved deferral. OpenAI says dates are subject to change.

Two dates in the report do not sit together. Its delivery timeline shows the Canon-signed package reaching 31 hosts at 15:23 UTC on 23 September. The text says the malicious libraries in the package Huntress analysed were compiled at 22:46 UTC on 24 September, a day before Huntress first saw the samples. A compile timestamp is written by whoever builds the file, so it is weak evidence of a date, and the report does not reconcile the two. Nothing here rests on either. What rests on the timeline is only the ordering: server activity from 22 September, the first GPT gone by 25 September, a second found on 27 September.

One more derived check. The four timeline rows that carry a host count add to 39 hosts (6 + 1 + 31 + 1), against a headline of at least 40 incidents. Hosts and incidents are different units and the report does not reconcile them, so read 39 as a sanity check on scale, not a count of victims. The largest single row, 31 hosts, is the one the report does not tie to a custom GPT.

What OpenAI's help pages and Google's ad policy say

OpenAI, as read at 11:30 BST on 30 September. The Custom GPT retirement FAQ says custom GPTs are scheduled to retire on 11 December 2026 and that at the applicable retirement date "custom GPTs and their GPT pages become inaccessible". The Sharing and publishing page, marked updated the day before, says: "Personal ChatGPT accounts, including Free, Go, Plus, and Pro, cannot create or publish new GPTs." It adds that existing GPTs remain usable and can still be edited, and that in Business, Enterprise and Edu workspaces creation depends on workspace settings. A post on OpenAI's developer forum dated 16 August 2026 complains that creation had already been removed for personal accounts, so the restriction is older than the page edit (a user report, not an OpenAI statement). OpenAI also says public sharing and store publishing may be checked automatically against policy requirements.

The question that opens. Huntress calls the GPTs attacker-created and does not say what kind of account built them or when. Against OpenAI's page there are at least three readings: an older GPT was edited and renamed, which the page permits; the GPT was built in a managed workspace, where creation continues; or something the page does not describe. The report supports none of these over the others. It matters, because it decides whether a control OpenAI describes was bypassed or was never in the path. That is inference, and OpenAI has not commented in anything I could read.

Google. Google's Malicious software policy applies to "your ads and any software that your site or app hosts or links to", and says an account found in violation is suspended "upon detection and without prior warning". Here the destination was OpenAI's page, not the advertiser's site, and the link to the next hop appeared in a reply the GPT gives after a visitor types something; Huntress says any interaction produced the same message. That is an inference, not a statement from either company: an automated review of the destination may have seen an ordinary chat page. What Google's review saw, whether it acted on an account, and how many ads ran are not stated in anything I could read. Our briefing on 852 of 1,235 Meta ads that led to toll fraud apps covers what an ad takedown does and does not remove.

What retirement does and does not do. Retirement on the standard date, 72 days away, ends this vehicle. It does not end the pattern, because the pattern needs only a vendor's domain that lets a stranger publish a page, and the reports above found five such features across three products. Retiring a feature is not a control for the next one. If your staff are about to be asked to trust more agent behaviour, as in OpenAI's dots launch and its Critical cyber rating, the habit of trusting a familiar address is the first thing to test.

Who is telling us this, and what they sell

Huntress sells managed endpoint detection and response, identity, SIEM and security awareness training, and the report page carries an invitation to book a demo. Its telemetry is its own customers, which its site puts at more than 277,000 organisations, so "at least 40" is a floor on what one vendor saw, not a measure of what happened. Huntress documents its method in detail: it says every stage was decoded from samples recovered from affected hosts and the decryption reimplemented. That is a description of method, not an accusation, and anyone holding the samples could check it. The counts and the "two of at least 40" are Huntress's alone.

Two commercial points sit next to the report. BleepingComputer's news story of 29 September is written by a named reporter and is not marked as sponsored, but on 11 September the same site ran a piece labelled "Sponsored by Huntress Labs" on the same theme of attackers abusing AI platforms. Neither fact suggests the news story is anything other than editorial. It is context a reader is entitled to. Separately, one browser-security vendor's detection data, published 23 September, says four in five ClickFix payloads it intercepted in 2026 were reached from search engines. That vendor sells browser controls, so treat it as one commercial data set.

Three drifts between the report and the coverage are worth naming. SecurityWeek writes that at least 40 users were infected; Huntress counts incidents. Help Net Security says the operators created another GPT and pushed it to Google Search users, and SecurityWeek says victims reached the GPT as a sponsored result; Huntress shows the click parameters on the first GPT's address only and describes the ad route as present in some incidents. BleepingComputer's line on where the instructions are hosted is described above. Each is small, and each is the kind of change that lands in a risk register as a fact.

What to harden and hunt, in the order worth doing

This is defender guidance only: behaviours to hunt and controls to set, with no commands and no payload detail. Microsoft's guidance on the ClickFix family (its TerminalFix post of 28 August 2026 and its 2025 analysis) and Huntress's own detection notes overlap on most of it.

Take this with you

Order of work

Take away the paste path first. Where staff do not need the Run dialog, disable it: Microsoft names the Group Policy setting Remove Run menu from Start Menu. Set Windows Terminal to warn when pasted text contains several lines, which Microsoft also recommends.
Add application control. Use AppLocker or App Control for Windows so standard users cannot start PowerShell freely, and add an App Control rule that stops native binaries being launched from Run. Turn on PowerShell script block logging, and use Constrained Language Mode where you can.
Do not treat a publisher signature as a pass. Huntress found validly signed Canon and Stardock applications used as hosts and says not to block them globally. Control by location and parent process as well as by publisher, and expect the signed host to change: Huntress found a third installer on the same server and says name-based detections will miss the next swap.
Hunt on behaviour, not names. Look for PowerShell starting the Windows installer quietly on a package with a random name in a temp folder; a signed executable started by the installer from a product folder under the user's local Programs directory that matches nothing you deploy; and a Run value and scheduled task that share one name and reappear after deletion. Check Run dialog history in the RunMRU registry key, which Microsoft documents as a trace.
Watch for hosts written as a bare number in download requests. Huntress says the staging host was written that way, which some filters looking for dotted addresses do not match. Review whether your web filter normalises it.
Give people a way in that is not a search. Publish the exact addresses of the AI tools you sanction, pin them in managed browsers or a launcher, and say in policy that AI tools are reached from those, never from a sponsored result.
Teach the rule, not the brand. No genuine verification step asks a person to paste text into a Run box or a terminal. A chat reply that sends someone to a backup domain is a reason to stop and ask.
Prepare the response order. Huntress says the implant recreates its Run value and scheduled task within minutes, so stop the process first and then remove both. In at least one incident Defender quarantined the installer after it had already run and persistence continued, so a file alert is not the end of the case. Assume remote desktop, camera and microphone capture and file search were possible on the host, and rotate credentials that were reachable from it.
Report fast. Tell the platform vendor about AI-hosted lures, and report the ad to Google. Huntress says these campaigns often live for hours or days, so the window is the target.

One item is our own suggestion rather than a source's advice: if your proxy logs referrers, a click from a chatgpt.com custom GPT page straight to a sites.google.com page is rare in most estates and may be worth a short-lived alert. We have not tested it, and it is only useful where TLS is inspected.

The question that exposes the gap

On Huntress's account, every address and signature a person could check on the way to this infection was genuine as far as it went: a real ad, a page on OpenAI's real domain, a second page on Google's real service, and a host executable with a real signature. What was false was the story each told, including a check that named Cloudflare, and no label carries that.

So the question for your estate is not whether your staff can spot a fake ChatGPT. It is this: if every address and signature the person could check was genuine, which control of yours would have seen the command?

Key facts

Source: Huntress blog, published 28 September 2026; BleepingComputer news story 29 September 2026, 16:59 EDT (21:59 BST).
Incidents: at least 40 tied to one Google Sites page; 2 confirmed as coming through a custom GPT, a confirmed share of at most 5 per cent (derived).
Custom GPTs: two, both titled "Plus 5.6". The first was down as of 25 September; the second was found 27 September and was active at Huntress's publication. Current status: unverified.
Ads: the first GPT's landing address carried Google Ads click parameters. Number of ads, advertiser and dates: not stated.
Chain: sponsored result, chatgpt.com custom GPT page, Google Sites page with a fake Cloudflare check, a PowerShell command run by the person, an installer, a signed host application, a remote access trojan.
Capabilities listed by Huntress: remote desktop, audio and camera capture, file search, host reconnaissance, running further payloads.
Where the command sat: on the Google Sites page, not on chatgpt.com, on Huntress's account.
Attribution: none. Victim counts beyond Huntress customers: none.
OpenAI, read 30 September 2026: custom GPTs scheduled to retire 11 December 2026 (72 days), 11 February 2027 for approved Enterprise deferrals (134 days); personal accounts cannot create or publish new GPTs.
Same pattern elsewhere: Huntress reports it on claude.ai (July 2026) and on shared ChatGPT and Grok conversations (December 2025).
Commercial context: Huntress sells detection and response; BleepingComputer ran a Huntress-sponsored piece on 11 September 2026. No OpenAI or Google statement appears in the coverage read.

Two of at least 40 ClickFix incidents came through a custom GPT, and the chatgpt.com address proved nothing