What a 14-Day Federal Patch Clock Costs a Team That Isn't a Federal Agency

(MLflow, CVE-2026-64849, August 2026)

By Pablo Bleck, Engineering Manager & Software Engineer, ActiveState

MLflow shipped its webhook API open by default across a platform with more than 30 million monthly downloads, and a CISA listing turned that unauthenticated endpoint into a 14-day deadline. The questions that would have caught it earlier are the ones most PR reviews skip under deadline pressure.

TL;DR

• CISA added CVE-2026-64849, an unauthenticated SSRF bypass in MLflow's webhook system, to its Known Exploited Vulnerabilities catalog, landing it in BOD 26-04's 14-day remediation tier for federal agencies.

• MLflow's default tracking server configuration shipped the webhook API open by default, part of a platform with more than 30 million monthly downloads; the flaw let attackers reach internal, loopback, and cloud-metadata endpoints and steal cloud credentials, including AWS IAM keys.

• MLflow 3.15.0 fixes the flaw, but the patch is the easy part; the expensive part is auditing and rotating every credential the exposed endpoint could have reached, inside a compressed clock.

• Three questions a PR review or dependency-adoption checklist should ask about default network exposure and credential reachability would have caught this before a CVE existed for it.

• ActiveState builds its library's open source components from source inside a SLSA Level 3 environment with a signed attestation and SBOM per component, so default-exposure questions get answered at adoption, not after a KEV listing.

A 14-day CISA deadline gets set in a policy office. Whether it turns into a clean patch or a 2 a.m. scramble gets decided somewhere else. This one comes from the pull-request-review side of that fight, not the boardroom, because that is usually where a gap like this gets caught first.

CISA added CVE-2026-64849 to its Known Exploited Vulnerabilities catalog and placed it in the 14-day tier of remediation deadlines federal agencies muct meet under Binding Operational Directive 26-04. It's an unauthenticated SSRF bypass. MLflow validates a webhook's URL on submission but not the destination after a redirect. DNS rebinding exploits the same gap. MLflow is an open source AI platform with more than 30 million monthly downloads.

My team doesn't run MLflow, but plenty of engineering teams reading this do, and none of them are federal agencies bound by BOD 26-04. Here's the part the federal deadline doesn't cover: 14 days gets you a patch. It says nothing about the days a team spends afterward finding out what the exposed endpoint already gave away.

The flaw itself is straightforward once you see it. MLflow's default tracking server configuration exposes an unauthenticated webhook API. An attacker who can reach it can force requests out to internal, loopback, and cloud-metadata endpoints, and pull cloud credentials, including AWS IAM keys, at low complexity and without needing any privileges first.

MLflow fixed it in version 3.15.0. Nobody had to misconfigure anything. The default shipped exposed, and 30 million monthly downloads treated that default as somebody else's already-made decision.

Inside the 14 days

When a KEV listing lands mid-sprint, here's the sequence: someone opens the CISA notice, checks whether the affected open source component runs anywhere in the environment, including the internal ML platform someone stood up 8 months ago and never added to the inventory, then starts triage.

That inventory step alone can burn a full day if a team doesn't already have a real accounting of what open source components run where, as opposed to what a spreadsheet from the last audit says runs where.

Once the affected instance is confirmed, patching MLflow itself is usually the easy part: bump to 3.15.0, run the test suite, redeploy.

What the patch doesn't cover is rotating every credential the exposed webhook could plausibly have reached, because determining whether an attacker already pulled a credential is a harder question than confirming the endpoint is closed now. For a service that touched cloud-metadata endpoints, that means walking the IAM keys and checking logs for a rebinding pattern nobody thought to alert on before this CVE existed, all inside 14 days if the federal deadline applies to you, or inside whatever timeline an internal security review sets if it doesn't.

ActiveState's own contractual remediation SLAs run 5 business days for a critical finding, 10 for high, and 30 for everything else, once a community-approved fix exists upstream; the clock starts when there is something to ship, not at disclosure. MLflow shipped that fix in 3.15.0.

The 14-day federal deadline sits inside that same window. What differs is how much credential-rotation work sits behind the patch when the deadline hits.

Three questions that would have caught it earlier

These are the ones a lot of dependency reviews skip under deadline pressure:

• Does the default configuration expose a network-facing endpoint, and does anything document that as an intentional choice, or is it just what ships?

• Does that endpoint, or anything reachable from the service it belongs to, sit close enough to internal, loopback, or cloud-metadata addresses to matter if it is reachable from outside the service boundary?

• Does the endpoint require authentication by default, or does authentication get bolted on later as a hardening step somebody has to remember to do?

A scanner catches this once a signature exists. CI catches it only if someone remembered to write a check for the pinned version range.

Neither one catches an unauthenticated-by-default webhook sitting quietly in a service that has been running fine for 8 months, because nothing about it looks broken until somebody tests whether it should have been reachable at all.

Checking for this before it reaches a build

This is the kind of gap the library we build from is meant to close before it opens. Every component in ActiveState's library, more than 79 million open source components built from source across 12 language ecosystems, is built inside a SLSA Level 3 environment with a signed attestation and a full software bill of materials attached.

A question like "does this component's default configuration expose anything unauthenticated" is something we can check against provenance and build metadata before the component ever reaches a developer's dependency file, not something we discover from a KEV listing after it is already running in 10 different services. Catalog-governed open source components see roughly a 95% reduction in CVEs compared to the same packages pulled straight from the public registry, and reclaiming 4 to 8 developer hours per CVE is the practical version of what that means: less credential-rotation work at 11 p.m. on day 12 of a 14-day clock, because the question got asked at adoption instead of at incident response.

That is the check I would point to, because it is the one my team runs. If your review process cannot answer "what does this open source component's default configuration expose" before merge, that is worth fixing on your own sprint, on your own clock, before a KEV listing sets one for you.

Frequently Asked Questions

What is CVE-2026-64849?

It's an unauthenticated SSRF bypass. MLflow validates a webhook's URL on submission but not the destination after a redirect. DNS rebinding exploits the same gap.MLflow's default tracking server configuration exposes an unauthenticated webhook API, and an attacker who can reach it can force requests to internal, loopback, and cloud-metadata endpoints and steal cloud credentials, including AWS IAM keys, at low complexity and with no privileges required. MLflow fixed it in version 3.15.0.

Why does BOD 26-04 matter to a team that isn't a federal agency?

BOD 26-04 assigns remediation deadlines by risk tier, from three days for the highest-risk KEV entries up to 60 days. This one landed in the 14-day tier, binding only for federal agencies. What it signals to everyone else is that the flaw is confirmed as actively exploited, which is a reasonable trigger for any team running the affected open source component to run its own compressed remediation on the same timeline, even without a legal requirement to do so.

What does the MLflow flaw expose, and does it require any special access to exploit?

No special access. The webhook API is unauthenticated by default, and the flaw uses DNS rebinding to get around the SSRF protections that would otherwise block requests to internal, loopback, or cloud-metadata addresses. CISA's listing describes the exploit complexity as low and the privileges required as none.

Which MLflow version fixes CVE-2026-64849?

MLflow 3.15.0.

What should a PR review or dependency-adoption checklist ask before bringing in a new open source component like MLflow?

At minimum: whether the default configuration exposes any network-facing endpoint and whether that's a documented, intentional choice; whether that endpoint or anything reachable from it sits close enough to internal, loopback, or cloud-metadata addresses to matter; and whether authentication is required by default, or added later as a step someone has to remember. Those three questions catch this class of finding before a CVE number exists for it.