Which versions of zrok Python SDK are affected by CVE-2026-45568?

The zrok Python SDK ProxyShare component (versions 0.4.47-1.1.11) contains a critical server-side request forgery vulnerability allowing unauthenticated attackers to redirect proxied requests to…

How to fix or mitigate CVE-2026-45568?

Within 24 hours: Inventory all zrok SDK deployments and identify ProxyShare usage across production environments. Within 7 days: Implement network segmentation isolating affected systems from metadata endpoints, enforce strict URL validation policies, and disable ProxyShare if not business-critical. Within 30 days: Monitor vendor security advisories for patched releases; deploy application-layer controls restricting proxy targets to whitelisted hosts only; evaluate alternative proxy solutions.

zrok Python SDK CVE-2026-45568

CRITICAL

Path Traversal (CWE-22)

2026-05-19 https://github.com/openziti/zrok

GHSA-jh67-hwqw-m5r7

Path Traversal Python

Lifecycle Timeline

Source Code Evidence Fetched

May 19, 2026 - 16:00 vuln.today

Analysis Generated

May 19, 2026 - 16:00 vuln.today

DescriptionCVE.org

Summary

Alice exposes a Python SDK ProxyShare with a fixed target URL. Bob sends a request to the share with an absolute URL in the path. The Flask handler passes that path to urllib.parse.urljoin, which replaces Alice's configured target host with Bob's host and returns the server-side response to Bob.

Details

The Python SDK proxy route accepts every path under the share:

python

@app.route('/', defaults={'path': ''}, methods=['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'OPTIONS'])
@app.route('/<path:path>', methods=['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'OPTIONS'])
def proxy(path):

It constructs the outbound URL with urljoin and then sends the request:

python

url = urllib.parse.urljoin(self.target, path)
resp = requests.request(
    method=request.method,
    url=url,
    headers={key: value for (key, value) in request.headers
             if key.lower() not in HOP_BY_HOP_HEADERS},
    data=request.get_data(),
    cookies=request.cookies,
    allow_redirects=False,
    stream=True,
    verify=self.verify_ssl
)

When path is http://127.0.0.1:19190/metadata, urljoin(self.target, path) returns http://127.0.0.1:19190/metadata. The proxy sends the request to Bob's chosen URL rather than Alice's target.

AnalysisAI

Server-side request forgery in the zrok Python SDK's ProxyShare component (versions 0.4.47 through 1.1.11) allows remote unauthenticated users to redirect proxied requests to arbitrary hosts by submitting absolute URLs in the request path. Because the Flask handler concatenates user input with the configured target via urllib.parse.urljoin, an attacker (Bob) can replace the share owner's (Alice's) intended target with any host including internal cloud metadata endpoints, and the response is returned to the attacker. No public exploit identified at time of analysis, though the GitHub Security Advisory GHSA-jh67-hwqw-m5r7 documents the technique in detail.

Technical ContextAI

zrok is an open-source secure sharing platform built on OpenZiti, and its Python SDK exposes a ProxyShare class that wraps Flask to forward incoming requests to a fixed target URL. The vulnerability stems from a misuse of urllib.parse.urljoin, whose documented behavior is to discard the base URL's scheme and authority when the second argument is itself an absolute URL - for example, urljoin('https://alice.example/api/', 'http://127.0.0.1:19190/metadata') returns 'http://127.0.0.1:19190/metadata'. Flask's <path:path> converter forwards the raw, unsanitized request path to this join, so attacker-controlled absolute URLs flow directly into requests.request(). Mapped to CWE-22 (Path Traversal) in the advisory, the root cause is more precisely a URL parsing confusion that yields a Server-Side Request Forgery primitive against any host reachable from the proxy server, including loopback and cloud metadata services (e.g., 169.254.169.254, the 127.0.0.1:19190/metadata example in the advisory hints at zrok's own local metadata endpoint).

RemediationAI

No vendor-released patch identified at time of analysis - the advisory's fixed-in field is None and no tagged release in the affected range supersedes 1.1.11. Operators should monitor https://github.com/openziti/zrok/security/advisories/GHSA-jh67-hwqw-m5r7 for an upstream fix, and in the interim apply a local patch that rejects absolute URLs in the incoming path (validate that path does not begin with a scheme like http:// or https:// before passing to urljoin, or use urllib.parse.urlparse on the joined result and verify the host matches self.target's host). As a compensating control, take down or restrict ProxyShare instances that point at sensitive internal targets, place the proxy host on a network segment with no route to cloud metadata services (169.254.169.254) or internal admin endpoints, and require zrok share authentication so anonymous Bobs cannot reach the proxy - note that share authentication does not eliminate the SSRF, only narrows who can trigger it.