Summary

Following the fix for CVE-2025-0309, we took another look at the client-side checks to see whether they could be bypassed.

The original fix validated that the enrolment hostname was a subdomain of Netskope-owned domains, including *.goskope.com. However, this could be bypassed by abusing unauthenticated routes on Netskope’s reverse proxy service to reach an attacker-controlled enrolment server, hosted under the *.rproxy.goskope.com domain.

As a result, a local, low-privileged attacker could still force enrolment to a rogue server and exploit the original local privilege escalation path.

Technical Details

The patch for CVE-2025-0309 checks that the enrolment domain sent in the IPC message is:

• a valid domain name (i.e. not a URL)
• a subdomain of various Netskope-owned domains

This allow-list includes anything under *.goskope.com.

This check can be satisfied by proxying the rogue server via Netskope’s reverse proxy service, which allows proxying of specific domains via *.rproxy.goskope.com.

While most domains proxied via rproxy require authentication, some domains are configured for passthrough and allow proxying without authentication.

Examples of domains that allow proxying without authentication are:

• *.azureedge.net.rproxy.goskope.com
• *.azurewebsites.net.rproxy.goskope.com

Therefore, an attacker could host a malicious server using Azure App Service, which provides a hostname under *.azurewebsites.net (for example addon-test.azurewebsites.net). They could then access this through rproxy as addon-test.azurewebsites.net.rproxy.goskope.com, which did not require authentication at the time of testing.

Supplying this hostname via IPC during enrolment would satisfy the *.goskope.com allow-list check and direct the Netskope client to a rogue enrolment server.

The following diagram explains the flow:

Reproduction Steps

To demonstrate exploitation of this issue, we used the Azure App Service to spin up a containerised NachoVPN server.

This provided us with a NachoVPN container running on addon-test.azurewebsites.net:

We can then run the original UpSkope PoC as shown below, providing the enroll command and the App Service hostname appended with rproxy.goskope.com, for example addon-test.azurewebsites.net.rproxy.goskope.com.

This triggers enrolment into the NachoVPN server. After around 30 seconds, a new cmd.exe instance is spawned as SYSTEM.

Netskope’s Response

We reported this bypass to Netskope on 16th September 2025. Netskope advised the following on 19th November 2025:

Netskope will implement a change on Reverse Proxy to restrict the unauthenticated domains on Nov 24, 2025. We will post the updated advisory and share the same with customers. 

As of 24th March 2026, the azureedge.net and azurewebsites.net routes appear to be restricted on Netskope’s rproxy service.

As of publication, we have not identified a public Netskope advisory specific to this bypass. We have observed that some unauthenticated passthrough routes still exist, however we have not validated whether these could be abused to achieve LPE in the same manner.

Timeline

• We reported this issue to Netskope on 2025-09-16
• Netskope confirmed a planned server-side reverse-proxy change on 2025-11-19
• Netskope scheduled reverse-proxy restrictions for unauthenticated domains on 2025-11-24
• We revalidated the previously abused routes are restricted and published this advisory on 2026-03-24