> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # Chrome adds ClickFix detection and HTTP prompts to block social engineering - URL: https://f4n6.co.uk/security-feed/chrome-adds-clickfix-detection-and-http-prompts-to-block-social-engineering/ - Published: 2026-10-21T21:59:27.000Z - Updated: 2026-10-21T21:59:27.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary Google has shipped two browser-level changes to Chrome. Safe Browsing's Enhanced Protection mode now detects ClickFix, the technique where a page talks a victim into pasting a command into a terminal, and scrubs personally identifiable information from a copied clipboard payload before sending it to Safe Browsing for a verdict. Chrome also now prompts every user before connecting to a site over unencrypted HTTP, on by default, with the approval remembered for two weeks. No CVE, CVSS score, CISA KEV entry or named threat actor is associated with this item; it is a vendor capability change, not a vulnerability or a campaign. The risk to EMEA financial services is indirect: ClickFix is the delivery mechanism for a large share of infostealer and initial-access activity against staff endpoints, and this advisory tells defenders what the new controls do and do not cover, and where the gaps remain. ## 2\. Regulatory framing No specific DORA/NIS2 article is directly engaged by this item. ## 3\. Technical analysis & attack chain The changes are defensive. The attack chain below is the ClickFix pattern Google is targeting, reconstructed from the source's description of how the technique works; it is not a record of a specific intrusion. 1. A victim is lured to a page that instructs them to copy a command and run it themselves. The source does not name the lures used. 2. The copied command almost always invokes a living-off-the-land binary such as PowerShell. 3. The command pulls the malware down inside the terminal rather than through the browser, so Chrome's download protections and Safe Browsing never see the payload. That third step is the reason the technique works against browser defences: the malicious file never passes through the browser's download path, so there is nothing for download scanning to inspect. **ClickFix clipboard detection.** For users on Enhanced Protection, Chrome now detects when a user is manipulated into copying a suspicious command. When a potential ClickFix script is copied, the clipboard payload is scrubbed of PII and sent to Safe Browsing for analysis. If Safe Browsing returns a dangerous verdict, Chrome shows a warning. Google states the system is designed to be high precision to avoid disrupting legitimate developer activity. The source does not describe what the warning looks like, whether the user can override it, or what the PII scrubbing removes. The detection covers the copy event, not the paste or execution; a user who copies a command that Safe Browsing has not seen, or who is on Standard Protection, gets no warning. **Server-side Gemini scam analysis.** The on-device Gemini scam model launched previously covered tech support scams and was limited to Enhanced Protection users on supported devices. The server-side model is now available to every Enhanced Protection user and adds fake antivirus and fake browser update pages. It reviews signals including the brand on display, the page's purpose, and a scam likelihood score; Safe Browsing combines that with domain reputation and other signals for a final verdict. Page text is analysed only when a site shows strong signs of a scam, and content that leaves the device is handled ephemerally, not logged, stored, or used to train models. The source gives no accuracy figures for the model. **Two-level site warnings.** Safe Browsing site warnings now have two levels, mirroring the model already used for file downloads. A high-confidence verdict still produces the full-page red dangerous site warning. A new suspicious site level covers lower-confidence verdicts and flags pages using deceptive tactics typical of known malicious sites. Google says the separate design lets it display more of these warnings. **HTTP connection prompt.** Chrome now asks for approval before connecting to a site over unencrypted HTTP. Enhanced Protection users had it earlier in the year; it is now on by default for everyone. The prompt appears on the first visit to an HTTP site, and Chrome will not warn again until the user has not visited the site for at least two weeks. Sites that cannot obtain a publicly trusted HTTPS certificate do not trigger warnings by default, including single-label hostnames and local IP addresses; Google's reasoning is that an attacker would need to be on the same local network to tamper with that traffic. Google reports that nearly 95% of desktop Chrome users encounter no HTTP warnings in a given week and under 1% see three or more. **Confidence caveats.** Every claim here is single-sourced to Google via SecurityWeek. The "ten times safer" figure for Enhanced Protection is Google's own metric, defined as the average number of safety warnings each group receives, not an independent measurement of compromise rates. The rollout percentages are Google's early figures. No independent testing of the ClickFix detection's false-positive or false-negative rate is available in the source. ## 4\. Mitigation & containment P1 (within 24h) - Confirm which Chrome users are on Enhanced Protection rather than Standard Protection. The ClickFix clipboard detection and the server-side Gemini model apply only to Enhanced Protection; users on Standard get neither. Decide whether to enforce Enhanced Protection by enterprise policy for staff who handle payments, email and third-party portals, and record the decision. - Do not treat the ClickFix warning as a control. It fires on the copy event and depends on a Safe Browsing verdict. Keep endpoint detection for PowerShell and other living-off-the-land binaries spawning from browser processes, since the source confirms the payload download happens in the terminal and bypasses browser download scanning. P2 (within 72h) - Inventory internal and legacy applications still served over plain HTTP. The new default prompt will appear for staff on first visit and recur after two weeks of non-use, which will generate helpdesk contacts and, more importantly, train users to click through connection warnings. Move these services to HTTPS or document them as approved exceptions. - Check whether any internal hosts rely on single-label hostnames or local IP addresses. These do not trigger the HTTP prompt by default, so staff get no warning on them; that is the intended behaviour and not a gap to close, but it means the prompt gives no coverage for internal-only plaintext services. P3 (within 7 days) - Update user awareness material to describe the new Chrome prompts: the suspicious site interstitial, the HTTP connection prompt, and the ClickFix clipboard warning. Tell staff that a Chrome warning about a copied command means they should not paste it, and that approving an HTTP connection is a decision they are making about their own traffic. - Review proxy and DNS logs for ClickFix-style lures, where a page instructs a user to run a command, as a retrospective check. The source gives no page indicators, domains or command strings, so this is a hunting hypothesis rather than a signature match. ## 5\. Indicators of compromise No indicators of compromise available in the source material. The source describes browser behaviour and vendor capabilities, not artefacts from a specific intrusion, and gives no hashes, domains, IP addresses, file paths or command strings. ## 6\. Detection Insufficient indicators to author detection rules. The source contains no malicious strings, command lines, filenames, registry keys or network indicators to build a YARA or Sigma rule from; the only concrete artefacts are Chrome feature behaviours, which are not threat artefacts. ## 7\. Sources - SecurityWeek, "Google Hardens Chrome Against ClickFix Attacks, Insecure HTTP Connections", https://www.securityweek.com/google-hardens-chrome-against-clickfix-attacks-insecure-http-connections/, 2026-10-21\. Single source for all technical claims; the underlying statements are Google's and are reported, not independently verified. ## 8\. Adverse Trace position This item carries no CVE, no CVSS score and no CISA KEV entry, and we do not assign it a severity as a vulnerability; it is a vendor hardening change and we assess it as a net positive for endpoint defence with material coverage gaps. The ClickFix detection only helps Enhanced Protection users, only fires at the copy step, and depends on Safe Browsing having seen the command, so it reduces but does not remove the technique's effectiveness against staff who are the usual targets of infostealer and initial-access delivery. The HTTP prompt is a usability and hygiene change that will generate helpdesk load in organisations with internal plaintext services. We will track Google's published detail on the ClickFix detection's verdict logic and any independent testing of its false-positive rate, and we will revisit this advisory if a named campaign or CVE is tied to the technique. Clients running Chrome fleets should confirm their Enhanced Protection posture and their living-off-the-land detection coverage now rather than waiting for a ClickFix incident to test it. --- [Read the original source →](https://www.securityweek.com/google-hardens-chrome-against-clickfix-attacks-insecure-http-connections/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*