EUVD-2026-48467
GHSA-4vf6-f9c7-q6rp
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Network-accessible login endpoint needs no authentication; AC:L because the Helm default exposed the vulnerable flag; no availability impact from rate-limit bypass alone.
Primary rating from Vendor (huntr_ai).
CVSS VectorVendor: huntr_ai
Lifecycle Timeline
3DescriptionCVE.org
A vulnerability in zenml-io/zenml versions 0.57.0 through 0.94.2 allows an attacker to bypass rate-limiting on the POST /api/v1/login and self password-change endpoints by rotating the X-Forwarded-For header. The rate limiter keys requests by request.client.host, which is derived from the X-Forwarded-For header when Uvicorn is launched with --proxy-headers --forwarded-allow-ips *. This configuration allows clients to control the value of request.client.host, effectively bypassing rate-limiting protections. This vulnerability leaves the affected endpoints open to unthrottled credential guessing attacks.
AnalysisAI
Rate-limiting on ZenML's login and self-password-change endpoints can be completely bypassed in versions 0.57.0 through 0.94.2 by rotating the client-supplied X-Forwarded-For header, enabling unthrottled brute-force credential guessing against any exposed ZenML server. The rate limiter in rate_limit.py keyed on the raw X-Forwarded-For header value rather than the verified peer address, a design that is exploitable whenever Uvicorn is launched with --proxy-headers --forwarded-allow-ips * - which was the Helm chart default. No active exploitation is confirmed in CISA KEV; an upstream fix commit is available but a released patched version is not independently confirmed from available data.
Technical ContextAI
ZenML is a Python MLOps orchestration framework whose server runs as an ASGI application on Uvicorn. The RequestLimiter class in src/zenml/zen_server/rate_limit.py used to extract the client IP for rate-limit keying by reading the raw X_FORWARDED_FOR request header directly, taking precedence over request.client.host. When Uvicorn is started with --proxy-headers --forwarded-allow-ips *, it trusts all upstream X-Forwarded-For values; combined with the rate limiter's direct header read, an attacker who can inject arbitrary X-Forwarded-For values effectively controls the key that enforces per-IP throttling. CWE-290 (Authentication Bypass by Spoofing) is the precise root cause: attacker-controlled input is accepted as a trusted network identity signal, resetting the rate-limit counter on every rotation. The affected CPE is cpe:2.3:a:zenml-io:zenml-io/zenml:*:*:*:*:*:*:*:* spanning versions 0.57.0-0.94.2. The fix in commit 8a2214b removes the X-Forwarded-For branch entirely from _get_ipaddr and makes --proxy-headers opt-in with an explicit trusted-IP list in the Helm chart.
RemediationAI
The upstream fix is available at https://github.com/zenml-io/zenml/commit/8a2214bdd63eb8200ce4719d82c6f0d935e922d1; a released patched version number is not independently confirmed from available data - operators should track the ZenML release changelog for a version that includes this commit. As an immediate workaround, restart Uvicorn with --no-proxy-headers (added as the new Helm default in the fix) to prevent client-controlled X-Forwarded-For from influencing request.client.host - note this will cause ZenML to log the ingress/gateway IP rather than true client IPs in Kubernetes environments. If proxy-header support is required for legitimate reverse-proxy deployments, set forwardedAllowIPs to a strict comma-separated list of trusted upstream proxy IPs or CIDRs rather than *, and ensure the ingress/gateway sanitizes or overwrites incoming X-Forwarded-For headers before forwarding requests. Restricting network access to /api/v1/login and the self password-change endpoint to known IP ranges is an additional control but may impact remote users.
More in Zenml Io Zenml
View allSame weakness CWE-290 – Authentication Bypass by Spoofing
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today