Netskope Client CVE-2026-12254

Exploitation requires a specific sequence: a device running Netskope Client (versions prior to R142) must first associate with an attacker-operated rogue access point that presents a Captive Portal, and then switch to a different network that already has active internet connectivity - at which point the Captive Portal context fails to close, leaving it available for abuse. Limiting factors: the attacker must control nearby Wi-Fi infrastructure (rogue AP) implying physical/adjacent proximity, the victim must actively connect to the malicious AP and then roam (user interaction), and only unpatched clients below R142 are affected; upgrading to R142 removes the condition. No special target-side configuration is otherwise required.

This is a moderate-severity session-management flaw (CWE-613, Insufficient Session Expiration), CVSS 6.4, affecting the Netskope Client agent prior to R142. No EPSS score, CISA KEV listing, SSVC decision, or POC was provided, so there is no public evidence of active exploitation - the signal set points to 'no public exploit identified at time of analysis.' The strongest risk indicator is the vendor's own CVSS 4.0 vector showing high subsequent-system impact (SC:H/SI:H/SA:H) with zero vulnerable-system impact (VC:N/VI:N/VA:N), consistent with a security-control bypass that endangers the protected data path rather than the client itself. IMPORTANT CONFLICT: the vendor vector lists AV:N (network), but the description explicitly requires a rogue access point and a user physically connecting to a captive-portal AP then switching networks - this implies adjacent/proximity-based attack (AV:A) plus user interaction (UI:A), which materially lowers real-world reach. Taken together, this is a targeted, opportunistic bypass requiring attacker-controlled Wi-Fi infrastructure and victim action, not a widescale remote threat - a genuine but situational priority for high-risk/mobile-workforce environments, not an emergency patch for the general fleet. Verify the network-vector claim with Netskope given the proximity requirement in the description.

An attacker stands up a rogue access point presenting a captive portal near a target (airport, café, lobby). A victim running Netskope Client connects to it, then roams to a network that already has internet connectivity, but the captive-portal web context fails to close - leaving an attacker-influenced channel that can serve malicious sites or exfiltrate data outside Netskope's inspection. The attack needs attacker-controlled Wi-Fi proximity and user interaction, and no public exploit code has been identified at time of analysis.