CVE-2026-92568 in MLRun
Summary
by MITRE • 09/17/2026
MLRun through 1.11.0 contains a server-side request forgery vulnerability in the WebhookNotification handler that allows authenticated users to make the API server send arbitrary HTTP requests to internal addresses. Attackers can update a run with a malicious webhook notification that executes when the run reaches a terminal state, enabling requests to internal services, Kubernetes APIs, or cloud metadata endpoints from within the cluster.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in MLRun versions through 1.11.0 represents a critical server-side request forgery flaw located specifically within the WebhookNotification handler component of the application architecture. This security defect allows authenticated users to manipulate the API server into initiating arbitrary HTTP requests directed at internal network addresses that are typically inaccessible from external networks or untrusted zones. The core technical issue stems from insufficient validation and sanitization of user-supplied input when configuring webhook notifications, which permits attackers to inject malicious URLs targeting sensitive internal infrastructure components rather than legitimate external endpoints intended for notification delivery.
From an operational perspective, this vulnerability enables a sophisticated attack vector where adversaries can leverage the privileged context of the API server to probe or interact with internal services that reside within the same cluster environment. By updating a machine learning run configuration with a malicious webhook payload, attackers ensure that their crafted HTTP requests are executed automatically when the associated run reaches a terminal state such as completion or failure. This timing mechanism ensures reliable execution without requiring continuous active sessions, effectively turning standard ML workflow events into triggers for unauthorized network reconnaissance and exploitation attempts against internal assets including Kubernetes APIs, service meshes, and cloud metadata endpoints like AWS EC2 instance metadata or Azure managed identity services.
The impact of this vulnerability is severe as it facilitates lateral movement within the cluster environment by allowing attackers to access sensitive data stored in cloud provider metadata services which often contain authentication tokens and configuration details necessary for further compromise. Additionally, direct interaction with Kubernetes APIs can lead to unauthorized manipulation of cluster resources, potential privilege escalation, or disruption of critical workloads. This aligns closely with CWE-918 Server-Side Request Forgery as it involves the server making requests on behalf of a user-controlled input without proper restrictions, and maps directly to MITRE ATT&CK techniques such as T1071 Application Layer Protocol for command and control communication via HTTP/HTTPS and potentially T1534 Internal Spearphishing if used to exfiltrate data through internal services.
Mitigation strategies must prioritize immediate patching of the MLRun installation to version 1.12.0 or later where this validation logic has been corrected. In environments where upgrading is not immediately feasible, network segmentation policies should be enforced to restrict outbound HTTP traffic from the API server pods to only whitelisted external domains using egress filtering rules at the container runtime or service mesh level. Furthermore, implementing strict input validation on webhook URL fields during run configuration updates can provide an additional layer of defense by rejecting any URLs that resolve to private IP ranges such as 10.x.x.x, 172.16-31.x.x, and 192.168.x.x before they are processed by the notification handler.