Created plugin detector for CVE-2026-64849-mlflow

[mangeshwalsane2-hash]

Created plugin detector for CVE-2026-64849-mlflow, please review.
Testbeds at: google/security-testbeds#266

[robert-doyensec]

@tooryx this plugin relies on httpbin to redirect to localhost. is that okay? It's not great to rely on an external service, but It doesn't appear that anything very sensitive would be sent to httpbin, because the webhook is created by the plugin before being executed, and isn't configured with a secret for signing. The vulnerability requires a redirect to bypass SSRF protections, which I don't think we have a way to do otherwise.

[tooryx]

Can we rely on the callback server instead?

[mangeshwalsane2-hash]

Hi @tooryx ,
I investigated using the Tsunami Callback Server (TCS) directly, but it leads to false positives on patched instances due to how MLflow webhooks work:

  1. Intended Feature vs SSRF: MLflow webhooks are designed to make outbound HTTP requests to external/public endpoints. If we pass {{ T_CBS_URI }} directly, both vulnerable (< 3.16.0) and patched (>= 3.16.0) MLflow instances will successfully ping TCS, making TCS unable to distinguish between legitimate webhook delivery and an SSRF bypass.
  2. The Actual Vulnerability (CVE-2026-64849): The flaw is that MLflow's webhook client follows HTTP 302 redirects to reach internal/loopback services (127.0.0.1, cloud metadata 169.254.169.254) without validating the redirect destination.
  3. TCS Limitation: TCS currently only logs incoming interactions and cannot act as a 302 redirector that instructs MLflow to redirect back to 127.0.0.1.
  4. In-Band Reflective Verification: By having httpbin.org return a 302 Found to 127.0.0.1:5000, vulnerable versions follow the redirect and reflect the internal output in "response_body":, whereas patched versions (>= 3.16.0) intercept the socket connection and return SSRFProtectionError.

cc: @robert-doyensec

[robert-doyensec]

Can we rely on the callback server instead?

I believe it would only be possible if we added functionality to the callback server to redirect to arbitrary URLs. Then the callback server could redirect to localhost, which would validate the vulnerability.

[tooryx]

In such a case, I would recommending expanding the capabilities of the TCS. This is a bit more work but makes able to handle these cases generically in the future

[robert-doyensec]

@mangeshwalsane2-hash I can begin on the TCS changes if you would like, I'm not sure if you might have already started

[mangeshwalsane2-hash]

@robert-doyensec ,Thanks for checking in! I haven't started yet, but I'd like to take this up. I will do TCS changes today.

[mangeshwalsane2-hash]

@robert-doyensec I have implemented and tested the HTTP 302 redirect capability in the Tsunami Callback Server (TCS) and submitted the PR here: google/tsunami-security-scanner-callback-server#4

TCS Enhancement:

• Added support for redirect query parameters (?to=, ?redirect=, ?url=) while maintaining 100% backward compatibility (returns 200 OK when no redirect parameter is specified).

Limitation with MLflow on Localhost:

I won't be able to test this end-to-end on localhost until these changes are merged and deployed to the live TCS environment. MLflow's webhook validator hardcodes a strict check requiring https:// and a publicly routable IP address. Because local TCS runs over http:// on private/loopback IPs (127.0.0.1), MLflow immediately blocks webhook creation before any request is sent.

Once Deployed:

The live TCS endpoint will provide a public HTTPS domain. Setting {{ T_CBS_URI }}?to=http%3A%2F%2F127.0.0.1%3A5000... in the plugin .textproto will satisfy MLflow's checks, trigger the 302 redirect to loopback, and completely eliminate the need for httpbin.org.

How would you prefer to handle the MLflow plugin PR #918 in the meantime, should I update the .textproto to use {{ T_CBS_URI }} with REQUIRES_CALLBACK_SERVER in anticipation of the deployment?