CVE-2026-45568 is a critical (CVSS 9.1 in the NVD record) flaw in the Python SDK of zrok, the software for sharing web services, files and network resources. The ProxyShare route lets a request path replace the configured target host. The fix is zrok 2.0.3.
What's affected
The GitHub advisory lists zrok v0.4.47 through v2.0.2 as affected and 2.0.3 as the fixed version. The NVD record says versions prior to 2.0.3. The advisory itself rates the issue Critical at CVSS 9.9, while the NVD record shows 9.1 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Different scorers, same urgency.
The issue concerns the Python SDK ProxyShare, a Flask proxy route. If you only use the zrok command line tool and never run the Python proxy share, check whether any internal tool does. The advisory describes no workaround, so the remedy is to upgrade.
How to check if you're exposed
Look for the zrok Python package in your environments and in your lock files.
pip list 2>/dev/null | grep -i zrok
pip show zrok
grep -rni "zrok" requirements*.txt pyproject.toml poetry.lock 2>/dev/null
Then search your code for ProxyShare, which tells you whether the vulnerable route is in use.
grep -rn "ProxyShare" .
If the package is present at a version below 2.0.3 and ProxyShare is used, you are exposed. If the package is only a transitive dependency, a dependency scan will show how it got in. The free in-browser scan at gold.safeguard.sh/scan can do that for a manifest.
What to do now
- Inventory every service that imports the zrok Python SDK, including scripts, notebooks and container images.
- Upgrade to 2.0.3 or later and rebuild images, not just running hosts.
- Re-run the lookup above to confirm the installed version after the rebuild.
- Review where ProxyShare runs and what it can reach from the network. A proxy that can talk to cloud metadata services or internal admin pages is the worst case for this class of bug.
- Restrict outbound traffic from the host to the destinations it needs.
- Check proxy logs for requests whose path looks like a full URL rather than a normal path.
- Add a version check to CI so an older zrok pin cannot come back.
Why it matters
The record classifies the weakness as CWE-22, improper limitation of a pathname. In practice it is also a server side request forgery. The route takes the request path and joins it onto the configured target with urllib.parse.urljoin. That function treats an absolute URL as a replacement for the base, so the path wins and the target host is dropped. The server then makes the request and returns the answer.
This is a common trap. A join function that is fine for relative paths becomes an open proxy when it is fed untrusted input. The advisory describes the result as a share that fetches content from a host the attacker chooses and hands the response back.
The record's KEV flag is false and I found no advisory text claiming exploitation. Exposure depends on who can reach the share and what the proxy host can reach.
Try it yourself
Not every vulnerable package is actually used in a way that matters. This demo shows how reachability analysis separates findings you can reach from noise.
Click through it at your own pace, or open it full screen.
Quick check
Is the zrok command line tool affected?
The record and advisory describe the Python SDK ProxyShare route. Affected versions of zrok are listed as v0.4.47 through v2.0.2, so upgrade anyway and read the advisory for scope.
Why does a path replace the host?
urllib.parse.urljoin treats an absolute URL in its second argument as the new address. If the path comes from a request, the caller controls the host.
Sources
Last reviewed: 19 October 2026.
