CVE-2026-64849: MLflow Unauthenticated Webhook SSRF Remediation

MLflow versions before 3.15.0 expose an unauthenticated server-side request forgery path in model-registry webhook delivery. On a default tracking server (mlflow server, no auth plugin, SQL/SQLite backend), the webhook API is reachable without credentials. The synchronous POST /api/2.0/mlflow/webhooks/{id}/test route reflects the upstream response_status and response_body to the caller.

The hostname guard added in MLflow 3.10.0 (_validate_webhook_url) rejects non-public IPs for the original URL only. Delivery still follows HTTP redirects and re-resolves hostnames without pinning the validated address, so a public HTTPS first hop can bounce the server onto loopback, RFC1918, or cloud instance-metadata endpoints. CISA added CVE-2026-64849 to the Known Exploited Vulnerabilities catalog on 2026-08-19 (required action due 2026-09-02). Treat a reachable vulnerable tracking server as an incident candidate, not just a dependency bump.

Do not prove exposure by creating webhooks, calling /test, following redirects, or fetching cloud metadata. Inventory versions, ingress, and auth state; then patch.

When to use it

• A repository deploys, builds, pins, vendors, or documents MLflow before 3.15.0.
• An MLflow tracking server, model registry, or webhook feature is exposed through reverse proxies, Kubernetes ingress, tunnels, shared workbenches, hosted notebooks, or developer containers.
• You need a bounded PR that upgrades MLflow, keeps webhook test and delivery off untrusted networks, and documents credential rotation after exposure.

Inputs

• Python dependency files, lockfiles, Dockerfiles, compose/Helm/K8s/Terraform manifests, gateway/proxy config, environment templates, SBOMs, and runbooks.
• MLflow version evidence, tracking-server launch flags, auth-plugin state, webhook feature enablement, ingress exposure, runtime isolation, logs, and credential rotation owners.
• Available dependency install, API auth tests, gateway policy tests, container build, deployment render, SBOM, and dependency/security scan commands.

Affected versions

• Vulnerable: mlflow < 3.15.0
• Fixed: mlflow 3.15.0+
• Advisory note: GHSA-7gwp-5pfp-969j listed confirmed affected releases through 3.13.0 at disclosure. Do not infer that any release below 3.15.0 is safe; upgrade to the patched release.
• Affected surface: unauthenticated webhook create/update plus POST /api/2.0/mlflow/webhooks/{id}/test on a default tracking server. Event-driven delivery has the same SSRF without reflecting the body.
• Weakness: CWE-918 server-side request forgery. The 3.10.0 public-IP guard is an incomplete control, not a fix.
• CISA KEV: yes; added 2026-08-19 with required action due 2026-09-02.

Indicator-of-exposure

• The repository deploys, builds, vendors, pins, or documents MLflow < 3.15.0.
• A tracking server is reachable beyond a single trusted local user.
• The optional MLflow auth plugin is not loaded, or webhook routes are otherwise unauthenticated.
• Public or unauthenticated traffic can reach /api/2.0/mlflow/webhooks.
• The MLflow process can reach cloud metadata, loopback admin ports, internal HTTP services, or other non-public endpoints.

Quick checks:

rg -n "mlflow|MLFLOW|/api/2.0/mlflow/webhooks|mlflow server|serve-artifacts|tracking" .
python -m pip show mlflow
python -m pip freeze | rg -i "^mlflow=="
docker images | rg -i "mlflow"

Windows:

rg -n "mlflow|MLFLOW|/api/2.0/mlflow/webhooks|mlflow server|serve-artifacts|tracking" .
python -m pip show mlflow
python -m pip freeze | rg -i "^mlflow=="
docker images | rg -i "mlflow"

Do not validate exposure by creating webhooks, posting to /test, sending redirect URLs, reading instance metadata, or dumping environment variables.

Remediation strategy

• Upgrade every controlled MLflow dependency, lockfile, image, Helm chart, compose service, deployment manifest, SBOM, and runbook to mlflow 3.15.0+. The patched release validates the connected peer IP at connection time (SSRFProtectedHTTPAdapter), covering redirect targets and DNS rebinding.
• If rollout is not atomic, deny /api/2.0/mlflow/webhooks at the gateway or stop public ingress until every runtime is patched.
• Do not rely on the 3.10.0 _validate_webhook_url guard, UI hiding, or a "private network" as the only control.
• Enable MLflow authentication for any tracking server that is not a single-user loopback workspace. Keep webhook management off untrusted networks even after the patch.
• Isolate the process: block cloud metadata, avoid host mounts and Docker socket access, restrict egress, and keep secrets out of logs.
• Review application, gateway, and audit logs for unexpected webhook create/test traffic. Rotate cloud, model-provider, package, database, and workflow credentials when the tracking server was reachable by untrusted callers.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-64849, a critical MLflow unauthenticated
webhook SSRF before MLflow 3.15.0. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades MLflow, contains webhook
  exposure during rollout, adds safe regression coverage, refreshes generated
  artifacts, and documents operator cleanup, or
- TRIAGE.md if this repository does not own an affected MLflow runtime or
  cannot make a safe change.

## Rules

- Scope only CVE-2026-64849 and directly related MLflow tracking-server,
  webhook, authentication, ingress, runtime isolation, and credential cleanup.
- Treat tracking-server URLs, webhook URLs, cloud credentials, model artifacts,
  package tokens, and logs as sensitive.
- Do not prove exposure by creating webhooks, calling
  `/api/2.0/mlflow/webhooks/{id}/test`, following redirects, fetching cloud
  metadata, scanning internal hosts, or dumping environment variables.
- Do not leave webhook routes reachable to unauthenticated users as a default
  path.
- Do not treat the 3.10.0 public-IP URL guard as a complete fix.
- Do not auto-merge.

## Steps

1. Inventory every MLflow runtime controlled by this repository:
   `pyproject.toml`, `requirements*.txt`, lockfiles, Dockerfiles, compose
   files, Helm charts, Kubernetes manifests, Terraform, gateway/proxy config,
   environment templates, CI images, SBOMs, generated deployment output, and
   runbooks.
2. Determine every resolved MLflow version. A target is vulnerable if it
   resolves to `mlflow < 3.15.0` or an owned fork that delivers webhooks
   without connection-time peer-IP validation.
3. Search for webhook and exposure surfaces:
   - `/api/2.0/mlflow/webhooks`, webhook test/delivery helpers, and
     `mlflow server` launch commands;
   - optional auth-plugin enablement;
   - reverse-proxy, ingress, tunnel, Codespace, and shared workbench access;
   - cloud metadata reachability and broad egress from the tracking server.
4. If this repository does not deploy or package MLflow, stop with
   `TRIAGE.md` listing files checked, runtime owner if known, observed version
   evidence, and required fixed version `mlflow 3.15.0+`.
5. Upgrade every controlled MLflow package and image to `3.15.0+`.
   Regenerate lockfiles, image digests, SBOMs, deployment render output,
   dependency reports, and documentation as this repository normally does.
6. Add containment for non-atomic rollouts:
   - deny `/api/2.0/mlflow/webhooks` at the gateway until patched;
   - restrict MLflow to authenticated networks or single-user loopback;
   - fail closed if the MLflow version or auth state cannot be determined.
7. Where this repository controls MLflow product code or local patches,
   keep webhook delivery from following unverified redirect targets and
   require authentication before webhook create/test helpers run.
8. Add safe regression tests:
   - dependency policy rejects `mlflow < 3.15.0`;
   - gateway/rendered deployment config denies public unauthenticated webhook
     access during rollout;
   - unauthenticated webhook management is denied when this repository owns
     the server;
   - tests never create attacker-controlled webhook URLs or call `/test`
     against live internals.
9. Harden runtime exposure where this repository controls deployment:
   - remove Docker socket and broad host mounts from MLflow containers;
   - run with a least-privilege service identity;
   - block cloud metadata access and unnecessary outbound egress.
10. Add a PR body section named `CVE-2026-64849 operator actions` that states:
    - MLflow versions before and after;
    - whether webhook routes were reachable beyond loopback or trusted
      networks;
    - whether unauthenticated callers could reach webhook create/test;
    - which logs were reviewed for webhook traffic;
    - which cloud, model provider, package, database, and workflow
      credentials should be rotated or why rotation is not required;
    - any temporary edge block that must remain until deployment completes.
11. Run relevant validation: dependency install, lockfile integrity, unit/API
    auth tests, gateway policy tests, container build, deployment render,
    SBOM refresh, dependency/security scans, and a non-exploit local smoke
    test that proves denial without creating webhooks or calling `/test`.
12. Use PR title:
    `fix(sec): remediate CVE-2026-64849 in MLflow`.

## Stop conditions

- No affected MLflow runtime is controlled by this repository.
- MLflow is present only in prose or externally owned infrastructure; document
  owner, version evidence, exposure, and required fixed version in `TRIAGE.md`.
- A fixed MLflow version cannot be consumed without a broader migration and
  the repository cannot safely block webhook routes at the edge.
- Meaningful verification would require creating webhooks, calling `/test`,
  reaching metadata services, or exposing secrets.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Rollback

Do not restore MLflow below 3.15.0 to a reachable deployment. If the patched release must be withdrawn, keep /api/2.0/mlflow/webhooks denied at the gateway or stop the public service until another fixed release is installed; roll back unrelated configuration separately.

Verification - what the reviewer looks for

• No controlled dependency, image, SBOM, deployment target, or runbook resolves MLflow < 3.15.0.
• Webhook create/test routes are not reachable by unauthenticated callers on shared or public deployments.
• Gateway or reverse-proxy containment is present when patched runtimes cannot roll out atomically.
• Tests prove denial without creating webhooks, calling /test, or fetching internal URLs.
• Operator notes cover KEV urgency, log review, credential rotation, and any temporary edge block.

Output contract

• Reviewer-ready PR upgrading MLflow to 3.15.0+ across dependencies, images, manifests, generated artifacts, SBOMs, and docs.
• Safe regression tests proving unauthenticated webhook management is denied without exercising SSRF.
• TRIAGE.md when MLflow runtime, ingress, rollout, or credential cleanup ownership is outside this repository.

Watch for

• Updating one requirements.txt while a Docker image, Helm values file, compose service, CI image, or managed platform still runs an older MLflow.
• Treating MLflow 3.10.0–3.14.x as patched because a hostname guard exists.
• Testing with live webhook URLs, metadata endpoints, or environment dumps.
• Treating a private network as sufficient protection for shared developer workbenches, hosted notebooks, remote IDEs, or exposed preview deployments.

Related recipes

• Search the CVE Database for CVE-2026-64849
• CVE-2025-62593 Ray dashboard jobs RCE
• CVE-2025-3248 Langflow validate/code
• CVE intelligence intake gate

References

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-64849
• CISA KEV catalog entry: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-64849
• MLflow advisory: https://github.com/mlflow/mlflow/security/advisories/GHSA-7gwp-5pfp-969j
• MLflow 3.15.0 release: https://github.com/mlflow/mlflow/releases/tag/v3.15.0
• Fix PR: https://github.com/mlflow/mlflow/pull/24258
• Fix commit: https://github.com/mlflow/mlflow/commit/ba949522477cbd5915aa55d29b0cfad7d5ddf939
• CVE record: https://www.cve.org/CVERecord?id=CVE-2026-64849