CVE-2026-64849 — MLflow Unauthenticated SSRF, Cloud Credential Theft via Webhook Redirect / DNS-Rebind Bypass

CVE-2026-64849 (CVSS 3.1: 9.3 Critical, GHSA-7gwp-5pfp-969j) is an unauthenticated Server-Side Request Forgery in MLflow's model-registry webhook delivery mechanism, affecting all MLflow versions before 3.15.0. MLflow is a Linux Foundation-backed, open-source AI/ML engineering platform with 27,000+ GitHub stars and 60M+ monthly downloads. The default MLflow Tracking Server ships with no authentication at all, and exposes an unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint that synchronously delivers a webhook test request and returns the upstream response_status and response_body verbatim to the caller — a full-read SSRF primitive by design.

MLflow already validates webhook URLs via _validate_webhook_url() (added in 3.10.0), which resolves the hostname and rejects any URL that resolves to a non-public IP. Two independent bypasses defeat this guard: (1) the validated URL is fetched with default HTTP-redirect-following behavior, so a webhook pointed at an attacker-controlled server that responds with a 302/307/308 redirect to http://169.254.169.254/... is never re-validated at the new Location; and (2) per the original GitHub vulnerability report, the validation function resolves the hostname via socket.getaddrinfo() and then discards the resolved IP — the subsequent delivery request (session.post(webhook.url)) independently re-resolves the same hostname, so a DNS-rebinding attacker can return a public IP at validation time and a private/link-local IP at delivery time (a classic TOCTOU gap). Both mechanisms let an attacker make the MLflow server itself issue a request to the cloud instance-metadata service and read the reflected response.

watchTowr's Attacker Eye global honeypot network observed indiscriminate scanning for exposed MLflow instances within hours of CVE assignment on 2026-08-17. Public reporting attributes confirmed follow-on impact to attackers who successfully exfiltrated cloud credentials: cloud-resource enumeration, cryptominer deployment, and creation of new IAM users/roles for persistence. CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2026-08-19 with a Federal Civilian Executive Branch remediation deadline of 2026-09-02 under BOD 26-04.

Defender reality check: this is a credential-theft bug, not a malware family — there is no file hash, dropped binary, or C2 domain to hunt for. The single most reliable Falcon-native detection signal is the outbound network connection the MLflow server process itself makes to the cloud metadata address once SSRF succeeds (Section 8, Q1/Q2). Everything downstream of that moment — the attacker's actual use of the stolen credentials against the cloud provider's API — happens entirely in the cloud control plane and is invisible to Falcon endpoint telemetry without CloudTrail/GCP Audit Logs/Azure Activity Log ingestion. This pack is built and framed around that reality: the highest-leverage move available to a defender is not detection at all, it's enforcing IMDSv2 (Section 12), which can neutralize the credential-theft payoff even if the SSRF itself is never patched or caught.

Ten sources were fetched and saved verbatim to the pack's sources directory during the research stage. No prompt-injection or agent-directed instructions were found in any fetched content.

Contradictions & gaps

• "Unauthenticated" needs one caveat: the original GitHub issue (#24179) describes webhook creation as requiring an "authenticated MLflow user," since the webhook-creation handler lacks a permission decorator. All press and CISA KEV framing this as "unauthenticated" is nonetheless accurate in the vast majority of real-world deployments, because the default MLflow Tracking Server ships with no authentication layer enabled at all — so any network-reachable caller is already an implicit, unrestricted "authenticated" user. Both framings describe the same real-world exposure.
• Two distinct bypass mechanisms are both real and both cited: the GitHub Advisory emphasizes unvalidated HTTP redirects (302/307/308); the original GitHub issue and fix PR emphasize DNS-rebinding TOCTOU. This pack treats both as in-scope, since the shipped fix (connect-time peer-IP validation) closes both simultaneously and press coverage does not always distinguish them.
• The original watchTowr X/Twitter post could not be fetched directly (HTTP 402/paywall) — its quotes are corroborated identically across three independent outlets (thehackernews, securityweek, and secondary aggregators), so confidence in the quoted material remains high despite not reaching the primary post itself.
• No file hashes, C2 domains, or malicious IPs have been published for this CVE's exploitation — expected for a network-protocol-level credential-theft bug rather than a malware family. This pack does not fabricate any.

Hunt brief

Attack chain

This is a network-protocol-level SSRF/credential-theft bug, not a malware family. There are no atomic file hashes, C2 domains, or attacker-controlled IPs published in any fetched source, and none are fabricated here. Every row below is either a well-known, non-secret, universally-documented cloud infrastructure address/path, or a behavioral indicator.

NO NATIVE VISIBILITY = occurs entirely off the MLflow host (application layer, or the cloud control plane) — invisible to Falcon endpoint telemetry under any circumstance without additional log ingestion. PARTIAL = the resulting network connection is visible; its HTTP-level semantics are not. NATIVE FALCON COVERAGE = genuine native Falcon endpoint telemetry, no forwarding required — this is deliberately the single technique this CVE's exploitation cannot avoid touching a host Falcon can see.

These are manual/scripted checks against MLflow itself and its cloud environment — not CQL. Run these regardless of whether Falcon telemetry shows anything, since several attack-chain steps (2, 3, 6) are only visible here.

1. Webhook configuration audit

Enumerate every configured webhook via the MLflow REST API (GET /api/2.0/mlflow/webhooks) or directly against the backend store's webhooks table. Flag any webhook URL whose domain is not on an explicit allowlist of known-good internal/SaaS integration endpoints (Slack, PagerDuty, internal CI, etc.). Any unexpected external domain indicates attack-chain Step 2 has already occurred.

2. Version / patch audit

mlflow --version
# Expect: 3.15.0 or later. Anything below is vulnerable today regardless of network exposure.

3. Exposure audit

From outside the corporate network, confirm whether the MLflow Tracking Server's port (commonly 5000 for mlflow server/mlflow ui — confirm your deployment's actual configured port) is reachable from the internet at all. Given watchTowr's honeypot data showing scanning began within hours of disclosure, treat any confirmed-exposed, unpatched instance as compromised-until-proven-otherwise and proceed directly to Section 14 (Containment Runbook).

4. Webhook delivery log review

If MLflow's webhook delivery logs/audit trail are retained, review delivery history for any deliveries that returned HTTP 3xx redirects, or response bodies containing strings such as AccessKeyId, SecretAccessKey, Token, iam/security-credentials, or GCP/Azure metadata-response markers. Any hit indicates the reflection step (attack-chain Step 6) actually completed — not just an attempt.

5. SSRF-guard environment variable audit

# Confirm these are NOT loosened anywhere in your deployment (env vars, container specs, Helm values):
MLFLOW_WEBHOOK_ALLOW_PRIVATE_IPS   # must be false/unset in production -- true fully disables the SSRF guard
MLFLOW_WEBHOOK_ALLOWED_SCHEMES     # default ["https"]; confirm not loosened to allow http or other schemes

All IOCs for this threat are behavioral, not atomic (Section 4) — every query below hunts for the network/process side-effects of exploitation, not a hash or C2 domain. None of these queries require special log forwarding; they run against native Falcon endpoint sensor telemetry.

// HUNT: CVE-2026-64849 - T1552.005 Unsecured Credentials: Cloud Instance Metadata API
// CONF: high  FP: medium  COST: low | REQUIRES: NetworkConnectIP4 (native Falcon sensor telemetry)
// HYPOTHESIS: Successful SSRF exploitation (of this CVE or any other SSRF bug on the host) makes a local process connect outbound to the cloud instance-metadata service to read IAM credentials or role/config data.
// LOOKBACK: 14d
// FALSE POSITIVES: legitimate AWS SDK (boto3)/cloud-init/instance-agent credential-refresh calls to IMDS from the SAME host for unrelated, benign applications; container orchestration agents (kubelet, ECS agent) also legitimately call metadata endpoints.
// TUNING: exclude your environment's known/allowlisted instance-agent and SDK processes (cloud-init, amazon-ssm-agent, ecs-agent, kubelet) by ImageFileName once baselined; prioritize hits where the connecting process is the MLflow server itself (see Q2).

#event_simpleName = NetworkConnectIP4
| in(RemoteAddressIP4, values=["169.254.169.254", "169.254.170.2"])
| rename(field=ContextProcessId_decimal, as=TargetProcessId_decimal)
| join(query={#event_simpleName = ProcessRollup2}, field=[aid, TargetProcessId_decimal], include=[ImageFileName, CommandLine, UserName])
| table([@timestamp, ComputerName, UserName, ImageFileName, CommandLine, RemoteAddressIP4, RemotePort, aid])
| sort(@timestamp, order=desc)

// HUNT: CVE-2026-64849 - T1552.005 Unsecured Credentials: Cloud Instance Metadata API (MLflow-specific)
// CONF: high  FP: low  COST: low | REQUIRES: NetworkConnectIP4 + ProcessRollup2 join (native Falcon sensor telemetry)
// HYPOTHESIS: The MLflow Tracking Server process, identifiable by "mlflow" in its command line, connects to the cloud metadata address as a direct result of the webhook-delivery SSRF bypass.
// LOOKBACK: 14d
// FALSE POSITIVES: low. If your MLflow deployment's own artifact store (S3/GCS/Azure Blob) relies on the SAME instance role and the app-level SDK independently calls IMDS for its own credential refresh, expect occasional benign hits from this exact process -- distinguish via the delivery-log audit in Section 7.4.
// TUNING: none required for most environments; if benign hits appear, correlate timing against Section 7's webhook delivery log to confirm whether a /webhooks/*/test call immediately preceded the connection.

#event_simpleName = NetworkConnectIP4
| in(RemoteAddressIP4, values=["169.254.169.254", "169.254.170.2"])
| rename(field=ContextProcessId_decimal, as=TargetProcessId_decimal)
| join(query={#event_simpleName = ProcessRollup2}, field=[aid, TargetProcessId_decimal], include=[ImageFileName, CommandLine, UserName])
| CommandLine = /mlflow/i
| table([@timestamp, ComputerName, UserName, ImageFileName, CommandLine, RemoteAddressIP4, RemotePort, aid])
| sort(@timestamp, order=desc)

// HUNT: CVE-2026-64849 - T1071.001 Application Layer Protocol (DNS-rebinding staging for the webhook SSRF bypass)
// CONF: medium  FP: medium  COST: medium | REQUIRES: DnsRequest (native Falcon sensor telemetry)
// HYPOTHESIS: A DNS-rebinding attack requires the same domain to be re-queried and re-resolved between webhook validation and webhook delivery -- an unusually high query count for one domain in a short window from one host is consistent with this staging, though not by itself conclusive.
// LOOKBACK: 7d
// FALSE POSITIVES: medium-high standalone. Legitimate short-TTL DNS records (CDNs, load balancers, some SaaS integrations, DNS-based health checks) also re-resolve frequently; this alone does not confirm rebinding.
// TUNING: do NOT alert on this standalone. Escalate only when a hit here for a given ComputerName is followed within minutes by a Q1 or Q2 hit on the SAME host -- that combination (repeat DNS lookup immediately followed by an IMDS connection) is the confirming pattern for the DNS-rebind bypass variant specifically.

#event_simpleName = DnsRequest
| !DomainName = /\.(internal|corp|local|arpa)$/i
| groupBy([ComputerName, DomainName], function=[count(as=QueryCount), collect(@timestamp, limit=20)], limit=1000)
| test(QueryCount >= 5)
| sort(QueryCount, order=desc)

// HUNT: CVE-2026-64849 - T1190 Exploit Public-Facing Application (reconnaissance / exploitation traffic reaching the exposed endpoint)
// CONF: medium  FP: medium  COST: medium | REQUIRES: NetworkReceiveAcceptIP4 (native Falcon sensor telemetry); REPLACE the port below with your deployment's actual configured MLflow port if not the common default 5000
// HYPOTHESIS: Legitimate MLflow clients (CI/CD runners, data-science workstations, internal load balancers) originate from known internal ranges; connections from outside those ranges to the tracking-server port are consistent with the scanning/exploitation activity reported by watchTowr.
// LOOKBACK: 7d
// FALSE POSITIVES: legitimate remote data-science users, VPN-sourced traffic that doesn't fall in the excluded CIDRs below, or a reverse proxy/load balancer whose own IP is the only address this query will ever see.
// REQUIRED TUNING: replace the three documentation-only RFC1918 exclusions below with your actual internal CIDR ranges (including any VPN/remote-access ranges you consider "internal") before relying on this operationally.

#event_simpleName = NetworkReceiveAcceptIP4
| LocalPort = 5000
| !cidr(RemoteAddressIP4, subnet="10.0.0.0/8")
| !cidr(RemoteAddressIP4, subnet="172.16.0.0/12")
| !cidr(RemoteAddressIP4, subnet="192.168.0.0/16")
| table([@timestamp, ComputerName, RemoteAddressIP4, LocalPort, aid])
| sort(@timestamp, order=desc)

// HUNT: CVE-2026-64849 - defense-in-depth enrichment (no ATT&CK technique directly maps -- this CVE grants credential theft, not code execution)
// CONF: low  FP: high  COST: low | REQUIRES: ProcessRollup2 parent-child telemetry (native Falcon sensor)
// HYPOTHESIS: This CVE does not grant remote code execution. Any child process spawned by the MLflow server process is therefore NOT explained by this CVE and warrants investigation as a potentially unrelated finding (misconfiguration, a different vulnerability, or legitimate but unbaselined automation).
// LOOKBACK: 14d
// FALSE POSITIVES: very high standalone -- legitimate MLflow child processes include pip/conda package installs, git operations, and model-serving subprocesses during normal operation.
// TUNING: baseline your environment's normal MLflow child-process set before treating any hit as suspicious; only escalate a hit that also correlates with a Q1/Q2/Q3 hit on the same host and time window.

#event_simpleName = ProcessRollup2
| CommandLine = /mlflow/i
| rename(field=TargetProcessId_decimal, as=ParentProcessId_decimal)
| join(query={#event_simpleName = ProcessRollup2}, field=[aid, ParentProcessId_decimal], include=[FileName, CommandLine, UserName])
| table([@timestamp, ComputerName, UserName, FileName, CommandLine, aid])
| sort(@timestamp, order=desc)

Coverage honesty: Q1 and Q2 are the only queries here that directly observe the CVE's core impact (credential theft via metadata access) and are the recommended operational priority. Q3 and Q4 are staging/reconnaissance signals with meaningfully higher false-positive rates — use them for correlation and enrichment, not standalone alerting. None of these queries can see the actual exploitation HTTP request itself (Section 6); that visibility gap is structural, not a tuning problem.

Q2 (MLflow process → cloud metadata connection) is the strongest candidate for promotion to a Custom IOA: it is the single behavior that most directly and unambiguously represents this CVE's actual impact, with low expected false-positive volume in most environments.

Custom IOA Rule: MLflow Process Connecting to Cloud Instance-Metadata Service

Detection logic: process command line matches an MLflow server process (contains mlflow) AND destination IP is in {169.254.169.254, 169.254.170.2}.

Description: the MLflow Tracking Server process has no legitimate operational reason to connect to the cloud instance-metadata service as part of normal webhook or model-registry activity. A connection matching this pattern is the direct, host-visible signature of successful CVE-2026-64849 exploitation.

FP tuning notes: if your MLflow deployment's artifact store (S3/GCS/Azure Blob) legitimately relies on the same instance role and the application's own SDK independently refreshes credentials via IMDS, expect occasional benign hits from this exact process. Distinguish by correlating with the webhook delivery-log audit (Section 7.4) — genuine SSRF-driven calls correlate with an inbound POST to /webhooks/*/test immediately beforehand, while legitimate SDK credential refresh does not.

Recommended validation: run in Detect mode for at least 14 days; cross-reference every hit against Section 7's webhook configuration audit and delivery-log review before considering any escalation toward blocking.

No atomic file hashes, C2 domains, or malicious IPs have been publicly attributed to CVE-2026-64849 exploitation as of the most recent source (2026-08-22) — expected for a network-protocol-level credential-theft bug, not an established malware family. The grouped blocks below ship the actionable, non-fabricated content for this threat: known infrastructure addresses (detect-only, never block), vulnerable endpoint paths, config/audit strings, and patch metadata.

169.254.169.254   # AWS EC2 / GCP / generic link-local IMDS
169.254.170.2     # AWS ECS/Fargate task metadata (v3/v4)
# Azure IMDS path (same base address, requires "Metadata: true" header -- see Section 12):
# GET http://169.254.169.254/metadata/instance
#
# These are universal, non-secret, legitimate cloud infrastructure addresses.
# NEVER add them to a Prevent/Block IOC list -- every cloud host needs to reach
# its own metadata service. Use only as detection pivots (Q1/Q2), paired with
# process-context filtering to avoid false positives on legitimate SDK traffic.

POST /api/2.0/mlflow/webhooks              # webhook creation
POST /api/2.0/mlflow/webhooks/{id}/test     # unauthenticated test-delivery;
                                             # the full-read SSRF primitive
GET  http://169.254.169.254/latest/meta-data/iam/security-credentials/
                                             # AWS IMDS role-name enumeration
GET  http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>
                                             # AWS IMDS credential retrieval

MLFLOW_WEBHOOK_ALLOW_PRIVATE_IPS   # must be false/unset in prod -- true disables the SSRF guard entirely
MLFLOW_WEBHOOK_ALLOWED_SCHEMES     # default ["https"]; confirm not loosened

Vulnerable code: mlflow/utils/validation.py:889-936  (_validate_webhook_url)
Vulnerable code: mlflow/webhooks/delivery.py:153,189  (_send_webhook_request)
Fix commit:      ba949522477cbd5915aa55d29b0cfad7d5ddf939  (PR #24258)

Vulnerable:      MLflow < 3.15.0
Fixed:           MLflow >= 3.15.0
GHSA:            GHSA-7gwp-5pfp-969j
CVSS 3.1:        9.3 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N)
CISA KEV added:  2026-08-19
CISA KEV due:    2026-09-02  (BOD 26-04)

JSON block

{
  "cve": "CVE-2026-64849",
  "atomic_iocs": [],
  "atomic_iocs_note": "No atomic file hashes, C2 domains, or malicious IP addresses have been publicly attributed to CVE-2026-64849 exploitation as of 2026-08-22. This is a network-protocol-level credential-theft vulnerability, not a malware family with distributable artifacts.",
  "known_infrastructure_addresses": [
    {"type": "ipv4", "value": "169.254.169.254", "role": "cloud-instance-metadata-service", "note": "Universal, non-secret, legitimate cloud infrastructure address. Never add to a Prevent/Block IOC list. Detection pivot only (Q1/Q2)."},
    {"type": "ipv4", "value": "169.254.170.2", "role": "aws-ecs-fargate-task-metadata", "note": "Same caveat as above; relevant to containerized MLflow deployments."}
  ],
  "vulnerable_endpoints": [
    "POST /api/2.0/mlflow/webhooks",
    "POST /api/2.0/mlflow/webhooks/{id}/test"
  ],
  "vulnerable_code": [
    {"file": "mlflow/utils/validation.py", "lines": "889-936", "function": "_validate_webhook_url"},
    {"file": "mlflow/webhooks/delivery.py", "lines": "153,189", "function": "_send_webhook_request"}
  ],
  "fix_commit": "ba949522477cbd5915aa55d29b0cfad7d5ddf939",
  "fix_pr": "https://github.com/mlflow/mlflow/pull/24258",
  "vulnerable_versions": "< 3.15.0",
  "fixed_version": "3.15.0",
  "ghsa": "GHSA-7gwp-5pfp-969j",
  "cvss_31_vector": "AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N",
  "cvss_31_score": 9.3,
  "cisa_kev_date_added": "2026-08-19",
  "cisa_kev_due_date": "2026-09-02"
}

Why IMDSv2 matters more than usual here: unlike most SSRF findings where patching the application is the whole story, this CVE's actual payoff (temporary IAM credentials) is entirely defeated by IMDSv2 token enforcement even if the underlying webhook bug is never fixed. Treat IMDSv2 enforcement as independently mandatory, not merely a defense-in-depth nicety.

Playbook A: Emergency Patch + IMDSv2 Enforcement

Estimated deploy time: 20-40 minutes per host (excluding change-management approval) — Prerequisites: admin access to MLflow hosts and cloud console/CLI; a maintenance window or rolling-restart capability — Reboot required: No (application restart only for the MLflow patch; the IMDSv2 metadata-options change is live on AWS with no instance reboot needed) — Rollback: pip install mlflow==<previous pinned version> reverts the patch but re-exposes the CVE, so document but discourage; for IMDSv2, aws ec2 modify-instance-metadata-options --instance-id <id> --http-tokens optional re-permits IMDSv1 as a temporary bridge only, with a tracked follow-up ticket to re-enforce.

Step 1 — Inventory

Enumerate every MLflow Tracking Server instance and its exact version (Section 7.2).

Step 2 — Patch a canary instance first

pip install --upgrade "mlflow>=3.15.0"
# or, for a container deployment, bump the base image tag and redeploy

Step 3 — Restart

Restart the mlflow server process or redeploy the container.

Step 4 — Verify the patch

# Version check
mlflow --version
# Expect: 3.15.0 or later

# Confirm no unexpected webhooks remain configured (Section 7.1)
curl -s -H "Authorization: Bearer <token>" http://<host>:5000/api/2.0/mlflow/webhooks | jq .

# Functional confirmation: attempt a benign webhook test against a URL you control
# that redirects to an internal address you are authorized to test with. Pre-patch
# this would succeed and reflect the internal response; post-patch it should be
# BLOCKED by the new SSRFProtectedHTTPAdapter.

Step 5 — Enforce IMDSv2 on every affected cloud host

aws ec2 modify-instance-metadata-options \
  --instance-id <id> \
  --http-tokens required \
  --http-put-response-hop-limit 1

# Verify
aws ec2 describe-instances --instance-ids <id> \
  --query "Reservations[].Instances[].MetadataOptions"
# Expect: HttpTokens: required, HttpPutResponseHopLimit: 1

Step 6 — Roll out

Repeat Steps 2-5 across all remaining instances from the Step 1 inventory, sequencing internet-exposed instances first.

Playbook B: Egress Lockdown for MLflow Hosts

Estimated deploy time: 30-60 minutes plus a validation window — Prerequisites: documented knowledge of MLflow's legitimate outbound dependencies (artifact store endpoint, package registries, internal auth provider) — Reboot required: No (security-group/firewall change only) — Rollback: revert the security-group/firewall rule set to the prior permissive baseline via a tracked change ticket; note that reverting re-opens the SSRF blast radius, so treat any rollback as temporary.

Step 1 — Enumerate legitimate destinations

List every destination the MLflow host legitimately needs to reach outbound.

Step 2 — Apply an explicit-allowlist egress policy

# Example: host-level default-deny with explicit allow (nftables)
nft add rule inet filter output ip daddr <artifact-store-cidr> accept
nft add rule inet filter output ip daddr 169.254.169.254 accept   # required for the host's OWN legitimate IMDSv2 calls
nft add rule inet filter output policy drop
# Equivalent: AWS security group egress rules restricted to the same destination set

Step 3 — Validate

Confirm the host can still reach its artifact store and any package registries it needs. Confirm an arbitrary non-allowlisted domain now fails to connect from the host.

Step 4 — Monitor before treating as baseline

Watch Q1/Q2/Q4 (Section 8) for a period after rollout to catch any unexpected blocked-traffic regressions before treating this as the new permanent baseline.

Coverage summary: 1 of 7 mapped techniques has good native coverage (the credential-theft moment itself — also the core of this CVE); 2 have partial coverage; 4 are full gaps, all occurring entirely in the cloud control plane and requiring CloudTrail/GCP Audit Logs/Azure Activity Log ingestion (via Falcon Cloud Security or a SIEM) that is not assumed present.

Priority gap: the initial exploitation HTTP request (T1190) and all post-theft cloud-plane abuse (T1526/T1136.003/T1098.001/T1496) are structurally invisible to Falcon endpoint telemetry alone. This pack's genuine, reliable coverage is narrow and specific — the moment of credential theft itself (T1552.005) — which is fortunately also the single highest-leverage moment to preempt entirely: IMDSv2 enforcement (Section 12) defeats the credential-theft payoff regardless of whether detection ever fires.

Validation gates: see Section 11 for telemetry-readiness and baseline requirements before relying on any query above operationally.