CISA Adds One Known Exploited Vulnerability to Catalog (CVE-2026-64849)
CISA added CVE-2026-64849, a Server-Side Request Forgery (SSRF) vulnerability affecting MLflow Server, to its Known Exploited Vulnerabilities Catalog after confirming evidence of active exploitation. The article provides no technical detail on the exploitation method, affected versions, or observed attacker infrastructure, and instead focuses on remediation obligations under Binding Operational Directive 26-04 for Federal Civilian Executive Branch agencies.
- cveCVE-2026-64849A Server-Side Request Forgery vulnerability in MLflow Server that CISA confirms is being actively exploited in the wild.
Detection / HunterAnthropic
What Happened
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has confirmed that attackers are actively exploiting a security flaw in MLflow, a software platform used to manage machine learning projects. This affects any organization, including U.S. federal agencies, that runs MLflow Server and exposes it to the internet. It matters because the flaw allows attackers to trick the server into making unauthorized requests, which can be a stepping stone to further compromise, and federal agencies are now required to fix it on a strict timeline. Organizations using MLflow Server should check whether they are affected, apply available patches, and consider whether systems may already be compromised.
Key Takeaways
- CISA added CVE-2026-64849, a Server-Side Request Forgery vulnerability in MLflow Server, to its Known Exploited Vulnerabilities Catalog based on evidence of active exploitation.
- The article does not describe the exploitation technique, threat actor, or observed indicators of compromise.
- Federal Civilian Executive Branch agencies are required under Binding Operational Directive 26-04 to remediate this vulnerability on a prioritized timeline if it grants total control of an asset post-exploitation.
- BOD 26-04 also requires agencies to check whether systems were compromised before a patch was applied, indicating that patching alone may not be sufficient remediation.
Affected Systems
- MLflow Server
Vulnerabilities (CVEs)
| CVE | Product | Severity | Description |
|---|---|---|---|
| CVE-2026-64849 | MLflow Server | A Server-Side Request Forgery vulnerability in MLflow Server that CISA confirms is being actively exploited in the wild. |
Attack Chain
- Exposure: MLflow Server instance is exposed to untrusted network access.
- Exploitation: Attacker sends crafted requests to trigger the Server-Side Request Forgery vulnerability (CVE-2026-64849).
- Impact: Attacker leverages SSRF to reach internal resources or services not otherwise accessible, potentially leading to further compromise.
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
The article does not provide any detection rules, signatures, or queries. It only announces the addition of the CVE to CISA's Known Exploited Vulnerabilities Catalog and references BOD 26-04 remediation requirements.
Detection Engineering Assessment
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | The article provides no detail on exploitation behavior, payloads, or post-exploitation activity, so endpoint detection and response value cannot be assessed from this source. |
| Network Visibility | Medium | SSRF exploitation typically generates anomalous outbound or internal requests from the application server that could be visible in network or web server logs, though the article gives no specific request patterns. |
| Detection Difficulty | Hard | Without published exploitation details, payload examples, or indicators, defenders cannot build targeted detections and must rely on generic SSRF detection patterns and patch verification. |
Required Log Sources
- MLflow Server access/application logs
- Web server or reverse proxy logs
- Network flow logs for internal-facing traffic from the MLflow host
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for MLflow Server instances making unexpected outbound requests to internal metadata services or unusual internal/external hosts, which could indicate SSRF exploitation attempts (T1190). | Application logs from MLflow Server, network flow logs, proxy logs | Exploitation | Medium, since MLflow may legitimately make outbound calls to artifact stores or tracking backends |
| Consider reviewing MLflow Server request logs for parameters that accept URLs or hostnames, checking for attempts to reach internal-only or link-local addresses (e.g., cloud metadata endpoints), consistent with SSRF exploitation (T1190). | Web application logs, WAF logs | Initial Access | Low to Medium depending on normal application usage patterns |
Control Gaps
- Standard endpoint antivirus and signature-based network IDS are unlikely to detect SSRF exploitation without specific signatures, since the article provides none.
- Patch management alone may not detect prior compromise; BOD 26-04 notes agencies must separately verify whether exploitation occurred before patching.
Key Behavioral Indicators
- MLflow Server process making outbound network connections to internal-only or metadata service addresses that are not part of normal application behavior
- Unexpected internal network scanning or enumeration originating from a host running MLflow Server
False Positive Assessment
Low, since this is an official CISA KEV Catalog notification rather than a heuristic or behavioral detection, though the article itself contains no technical indicators to trigger false positives.
Recommendations
Immediate Mitigation
- Verify against your organization's incident response runbook and team escalation paths before acting. Identify any internet-facing or internally exposed MLflow Server instances and confirm patch status against CVE-2026-64849.
- If a fixed version is available from the MLflow vendor/project, consider applying it as soon as feasible, prioritizing internet-facing instances.
- Consider reviewing MLflow Server logs for signs of prior exploitation before and after patching, in line with BOD 26-04 expectations for verifying compromise.
Infrastructure Hardening
- Evaluate whether MLflow Server instances need to be publicly exposed, and restrict access via network segmentation or allow-listing where possible.
- Consider placing MLflow Server behind a web application firewall or reverse proxy that can filter suspicious request patterns, if supported by your architecture.
- Evaluate egress filtering on hosts running MLflow Server to limit the impact of potential SSRF by restricting outbound connections to only necessary destinations.
User Protection
- If your EDR supports it, consider monitoring hosts running MLflow Server for anomalous outbound connections or process behavior consistent with exploitation.
- Consider ensuring MLflow Server runs with least-privilege service accounts to limit the impact of any successful compromise.
Security Awareness
- Consider briefing teams responsible for machine learning infrastructure on the risks of exposing internal tooling like MLflow Server to untrusted networks.
- Consider incorporating KEV Catalog monitoring into existing vulnerability management awareness programs so relevant teams are notified promptly of newly added CVEs.
