ZERO-CLICK THREAT: New Phishing Kit Automates 'ClickFix' Attack, Blowing Past Your Security Measures    

Part 1: The Executive Briefing — The Evolution from Social Engineering to Zero-Click

In our **previous analysis of the "ClickFix" attack**, we detailed how a low-risk Self-XSS could be weaponized through social engineering. Today, we are revealing a critical and dangerous evolution of this threat. A new phishing kit, now being sold on dark web forums, automates the entire ClickFix attack, turning it into a **"zero-click"** compromise. This is a paradigm shift. An authenticated user on a vulnerable website can now be fully compromised simply by visiting a malicious webpage, with no other interaction required.

Part 2: Technical Deep Dive — A Masterclass on Cross-Site WebSocket Hijacking (CSWSH)

The "zero-click" capability is achieved by chaining the original Self-XSS vulnerability with a second, distinct flaw: **Cross-Site WebSocket Hijacking (CSWSH)**.

WebSockets 101

WebSockets provide a persistent, two-way communication channel between a user's browser and a server. They are the foundation of the modern, real-time web.

The CSWSH Vulnerability (CVE-2025-22114)

A CSWSH vulnerability occurs when a server's WebSocket endpoint fails to validate the **`Origin`** header during the initial connection handshake. The `Origin` header tells the server where the connection request is coming from. If the server doesn't check this, it will accept a WebSocket connection from *any* website on the internet, including a malicious one.

The "Zero-Click" Kill Chain

1. An attacker finds a website with both a Self-XSS vulnerability and a CSWSH vulnerability.
2. They create a malicious "lure" webpage.
3. They trick a victim, who is already logged into the vulnerable target site, into visiting this lure page.
4. JavaScript on the lure page silently opens a WebSocket connection to the vulnerable site's WebSocket endpoint. The victim's browser automatically includes their session cookie with this request, so the connection is fully authenticated.
5. The attacker, via their lure page, now has a direct, authenticated communication channel to the vulnerable application, acting as the victim.
6. The attacker sends a malicious message over this WebSocket connection that triggers the Self-XSS flaw, forcing the victim's own browser to execute the final payload. A full account takeover is achieved without any further clicks.

Part 3: The Defender's Playbook — A Guide to Hardening Modern Web Applications

1. Fix the Root Causes: XSS and CSWSH

The only true fix is to patch both vulnerabilities. Developers must:

• **Prevent XSS:** Implement a robust strategy of context-aware output encoding and a strong Content Security Policy (CSP).
• **Prevent CSWSH:** This is critical. On your WebSocket server, **you must validate the `Origin` header** of every incoming connection handshake. If the origin is not on your allow-list of trusted domains, the connection must be rejected.

2. Hunt for Post-Compromise Behavior

Because this attack is difficult to detect before it succeeds, the focus for SOC teams must be on detecting the *impact* of the successful XSS. A modern **EDR/XDR** platform that can provide visibility into browser process behavior is your essential safety net.

Part 4: The Strategic Takeaway — The New Attack Surface of the Real-Time Web

For CISOs, this evolution is a critical warning. The technologies that power the modern, real-time, and collaborative web—like WebSockets—are creating a new and often poorly understood attack surface. Your application security program must evolve beyond testing for classic vulnerabilities and must now include a deep understanding of the security risks of these modern protocols.

A mature **DevSecOps** program is essential. Your developers must be trained in secure coding for these new technologies, and your security testing (both automated and manual) must be updated to include specific test cases for flaws like CSWSH.