CVE-2026-92568: MLRun WebhookNotification SSRF Vulnerability

CVE-2026-92568 Overview

CVE-2026-92568 is a Server-Side Request Forgery (SSRF) vulnerability in MLRun through version 1.11.0. The flaw resides in the WebhookNotification handler, which allows authenticated users to instruct the API server to send arbitrary HTTP requests to internal addresses. Attackers update a run with a malicious webhook notification that fires when the run reaches a terminal state. This grants access to internal services, Kubernetes APIs, and cloud metadata endpoints reachable from within the cluster. The weakness maps to CWE-918.

Critical Impact
Authenticated users can pivot from the MLRun API server to internal cluster services, Kubernetes control plane endpoints, and cloud instance metadata services, exposing credentials and internal APIs.

Affected Products

MLRun through version 1.11.0
MLRun API server component (WebhookNotification handler)
Deployments running MLRun inside Kubernetes clusters with reachable metadata endpoints

Discovery Timeline

2026-09-16 - CVE-2026-92568 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92568

Vulnerability Analysis

MLRun is an open-source MLOps orchestration framework. Its notification subsystem supports webhook callbacks that fire when a run completes, fails, or otherwise reaches a terminal state. The WebhookNotification handler accepts a user-supplied URL and issues an outbound HTTP request from the MLRun API server process.

The handler does not validate the destination URL against a deny list of internal or link-local address ranges. Any authenticated user with permission to update a run can attach a webhook notification pointing at addresses such as 169.254.169.254, the Kubernetes API service, or in-cluster services normally protected by network boundaries.

Because the API server holds a privileged network position, requests originate from a trusted source and bypass perimeter controls. Response bodies or side effects reveal information about internal services and can be used to retrieve short-lived cloud credentials from instance metadata endpoints.

Root Cause

The root cause is missing input validation on the webhook target URL inside the notification handler defined in mlrun/utils/notifications/notification/webhook.py. The code performs no host resolution check, no allow-list enforcement, and no filtering of RFC 1918, loopback, or link-local addresses before dispatching the HTTP request. Reference: MLRun webhook notification source.

Attack Vector

An authenticated attacker calls the run update API and sets a notification of type webhook with a url field targeting an internal endpoint. When the run transitions to a terminal state such as completed or error, the API server dispatches the crafted request. Details are documented in the VulnCheck advisory and MLRun issue #10041.

// Vulnerability mechanism (conceptual, no verified PoC published)
// 1. Authenticated user PATCHes a run object
// 2. Notification payload: { "kind": "webhook", "when": ["completed"], "params": { "url": "http://<internal-target>/" } }
// 3. Run reaches terminal state
// 4. MLRun API server issues HTTP request to attacker-chosen internal URL

Detection Methods for CVE-2026-92568

Indicators of Compromise

Outbound HTTP requests from the MLRun API server pod to 169.254.169.254, metadata.google.internal, or Kubernetes API service IPs
Run objects containing notifications entries with webhook kind and URLs targeting private address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8)
Unexpected access log entries on internal services showing MLRun API server as the source
Cloud audit logs recording instance metadata token requests originating from the MLRun workload identity

Detection Strategies

Audit stored run records for notifications.params.url values pointing at internal, loopback, or link-local addresses
Instrument egress logging on the MLRun API server pod and alert on connections to non-public destinations
Correlate run state transitions in MLRun logs with outbound HTTP connections from the API server process

Monitoring Recommendations

Enable Kubernetes NetworkPolicy audit logging for traffic originating from the MLRun namespace
Monitor cloud provider metadata service access logs for calls from cluster nodes hosting MLRun
Track authenticated MLRun API calls that create or modify notifications, especially PATCH requests updating run objects

How to Mitigate CVE-2026-92568

Immediate Actions Required

Restrict MLRun API access to trusted users and reduce the scope of accounts permitted to update runs and notifications
Block egress from the MLRun API server pod to 169.254.169.254, fd00:ec2::254, and cluster-internal control plane endpoints
Require IMDSv2 with hop-limit of 1 on cloud instances hosting MLRun to blunt metadata credential theft
Review existing run records for webhook notifications targeting internal addresses and purge suspicious entries

Patch Information

At the time of NVD publication, MLRun through 1.11.0 is affected. Track the MLRun GitHub repository and issue #10041 for a fixed release. Upgrade to a patched version as soon as maintainers publish one that validates webhook target URLs against internal address ranges.

Workarounds

Deploy a Kubernetes NetworkPolicy denying egress from the MLRun API server pod to RFC 1918, loopback, link-local, and Kubernetes API subnets, allowing only known external webhook receivers
Front outbound webhook traffic with an egress proxy that enforces an allow-list of approved destinations
Disable the webhook notification kind in MLRun configuration if the feature is not required
Rotate any cloud credentials associated with the MLRun service account or node identity if metadata endpoint access cannot be ruled out

bash

# Example NetworkPolicy restricting egress from the MLRun API server
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: mlrun-api-egress-restrict
  namespace: mlrun
spec:
  podSelector:
    matchLabels:
      app: mlrun-api
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.0.0/16
              - 10.0.0.0/8
              - 172.16.0.0/12
              - 192.168.0.0/16
              - 127.0.0.0/8