What Happened
The Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-64849, a server-side request forgery vulnerability in MLflow, to its Known Exploited Vulnerabilities (KEV) Catalog. This addition signals that threat actors are actively exploiting this flaw. Server-side request forgery vulnerabilities allow attackers to manipulate server-side applications to make unauthorized requests, potentially accessing internal systems and sensitive data.
The inclusion of this vulnerability in the KEV Catalog triggers specific remediation timelines under Binding Operational Directive 26-04 for federal civilian agencies. However, the real issue isn't just the vulnerability itself. It's what this addition reveals about how most organizations still approach patch management.
Timeline
While CISA doesn't publish the initial exploitation date for KEV entries, the sequence is crucial:
- Vulnerability discovered in MLflow, an open-source platform for managing machine learning workflows.
- CVE-2026-64849 assigned.
- Evidence of active exploitation detected.
- CISA adds vulnerability to KEV Catalog.
- Federal agencies now have a defined remediation window under BOD 26-04.
For federal civilian agencies, BOD 26-04 mandates rapid remediation of KEV vulnerabilities on publicly exposed assets that grant total control post-exploitation. The directive also requires agencies to investigate whether systems were compromised before patching.
Which Controls Failed or Were Missing
Three control failures typically precede a KEV-listed vulnerability becoming an incident at your organization:
Asset Inventory and Exposure Mapping. You can't patch what you don't know you're running. Organizations that discovered they were running vulnerable MLflow instances only after the KEV addition lacked current asset inventories and visibility into which assets were publicly exposed.
Risk-Based Patch Prioritization. Many teams still patch based on vendor-defined severity scores or compliance-driven cycles. This approach doesn't account for active exploitation. If you're waiting for your next patch cycle to address a vulnerability already being exploited, your patch management process is ineffective.
Threat Intelligence Integration. The gap between "vulnerability published" and "added to KEV Catalog" represents lost time. Organizations with mature vulnerability management programs don't wait for CISA to confirm exploitation. They monitor exploit code repositories, threat actor forums, and security vendor feeds to identify in-the-wild exploitation early.
What the Relevant Standard Requires
Binding Operational Directive 26-04 establishes a risk-based framework that federal agencies must follow. It's worth examining even if you're not a federal civilian agency. The directive does three things traditional patch management policies don't:
Prioritizes Based on Exploitation, Not Just Severity. A critical-severity vulnerability that's not being exploited is treated differently than a medium-severity flaw with active exploit code. BOD 26-04 requires agencies to focus on vulnerabilities in the KEV Catalog that appear on publicly exposed assets granting total control post-exploitation.
Defines What "Rapid Remediation" Means. The directive establishes specific timelines tied to risk levels. You're patching based on exposure, exploitability, and impact.
Requires Compromise Assessment. When you patch a KEV vulnerability, BOD 26-04 expects you to determine whether the system was compromised before you applied the fix. If threat actors have been exploiting the vulnerability for weeks and you patch without investigating, you've closed the door but left the intruder inside.
For non-federal organizations, the NIST Cybersecurity Framework maps to similar outcomes. The Identify function requires asset management and vulnerability identification. The Protect function includes vulnerability management processes. The Respond function covers detection and analysis. But CSF doesn't provide the remediation timelines or the compromise-assessment trigger that BOD 26-04 does.
ISO 27001:2022 control 8.8 addresses vulnerability management but leaves the prioritization methodology to your organization. You could be compliant with 8.8 and still be patching alphabetically.
Lessons and Action Items for Your Team
Build a KEV-Aware Patch Workflow Now. Don't wait until a vulnerability affects your environment. Configure monitoring to alert when CISA adds entries to the KEV Catalog. Map those alerts to your asset inventory so you know within hours whether you're running affected software. Define your remediation SLAs based on asset exposure and criticality, mirroring the BOD 26-04 approach.
Treat "Publicly Exposed" as a Dynamic State. An asset's exposure changes with firewall rules, cloud security group modifications, and test environment setups. Your vulnerability management process needs current exposure data. If you're using a configuration management database, ensure it reflects actual network exposure.
Document Your Compromise-Assessment Trigger. When you patch a KEV vulnerability, who investigates whether the system was breached? What evidence do they review? Log analysis? File integrity checks? Network traffic patterns? Write the procedure before you need it. Patching a compromised system without detection means your next audit finding will read "organization failed to identify ongoing breach despite patching known exploited vulnerability."
Nominate Vulnerabilities You're Seeing Exploited. CISA maintains the KEV Catalog based on submitted evidence. If your security operations team sees exploitation of a vulnerability that isn't listed yet, submit it through CISA's KEV Nomination Form. You'll need the CVE ID, evidence of active exploitation, and confirmation that clear remediation guidance exists. Your submission helps other organizations prioritize the same threat.
Integrate KEV Status into Your Risk Register. When a vulnerability in your environment gets added to the KEV Catalog, that's a risk-level change. Your risk register should reflect it. If you're tracking CVE-2026-64849 as a medium-risk item and it appears on the KEV Catalog, the residual risk just increased. Update your risk assessment, notify stakeholders, and adjust your remediation timeline accordingly.
The MLflow vulnerability will be patched and forgotten within weeks at most organizations. The control gaps that made it dangerous won't be.
