CVE-2026-33865

What it actually does

MLflow versions through 3.10.1 improperly handle YAML-based MLmodel artifact content when rendering artifacts in the web UI, allowing stored cross-site scripting. An authenticated user with permission to upload or register model artifacts can place script content in an MLmodel file. When another authenticated user views the affected artifact in the MLflow UI, the browser executes attacker-controlled JavaScript in the context of the MLflow web application. This can allow actions within the victim’s session, access to UI-exposed data, modification of model metadata or experiment content within the victim’s permissions, and potential theft of session tokens if they are accessible to client-side script.

Why it matters to the business

A malicious or compromised MLflow user can turn shared model artifacts into a persistent browser-based attack against other users, including data scientists, ML engineers, reviewers, and administrators. This can undermine trust in experiment tracking and model registry workflows, lead to unauthorized changes to model metadata or lifecycle state, expose sensitive experiment information, and potentially enable broader account misuse. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but the risk is higher in collaborative MLflow deployments where many users upload and review artifacts.

How an attack unfolds

An attacker first obtains authenticated access to an MLflow deployment, either as a legitimate low-privileged user or through compromised credentials. The attacker creates or modifies a model artifact containing a crafted YAML MLmodel file with embedded script content or markup that is not safely sanitized by the MLflow UI. The artifact is uploaded to an experiment run or model-related workflow where other users are likely to inspect it. When a victim opens the artifact view in the MLflow web interface, the malicious payload executes in the victim’s browser under the MLflow application origin. The script can then issue requests using the victim’s active session, alter MLflow resources within the victim’s permissions, attempt to capture accessible session or application data, or redirect the victim to further credential-harvesting or malware-delivery pages.

How to fix it

Upgrade MLflow to a version newer than 3.10.1 once an official fixed release is available from the MLflow maintainers, and prioritize deployments where untrusted or semi-trusted users can upload artifacts. If an upgrade is not yet available, reduce exposure by restricting MLflow UI and artifact-upload access to trusted users, enforcing strong authentication and least-privilege roles, isolating MLflow from the public internet, and reviewing whether artifact rendering can be limited or disabled for untrusted content. Apply defense-in-depth controls such as secure cookie attributes, strict Content Security Policy where feasible, reverse-proxy access controls, and network segmentation around MLflow services and backing artifact stores. Treat existing uploaded MLmodel files from untrusted sources as potentially unsafe until reviewed or regenerated.

How to confirm the fix worked

Confirm all MLflow services report a version later than 3.10.1 after remediation. Inventory MLflow deployments, containers, notebooks, development servers, and packaged services that expose the MLflow UI. Validate that authenticated low-privilege users cannot upload MLmodel artifacts that execute JavaScript when viewed in the UI. Test with a benign proof string such as a harmless script alert in a non-production environment only. Review access controls to ensure only intended users can upload artifacts and view model runs. Confirm reverse proxies or identity-aware access controls prevent unauthenticated internet access to the MLflow UI.

Typical attack path

1. Gain authenticated access to an affected MLflow instance through legitimate access, credential theft, or another weakness.
2. Create a malicious YAML-based MLmodel artifact containing stored XSS payload content.
3. Upload the crafted artifact to an experiment run, model artifact location, or workflow visible to other MLflow users.
4. Entice or wait for another user to view the uploaded artifact in the MLflow web interface.
5. Execute attacker-controlled JavaScript in the victim’s browser within the MLflow application context.
6. Use the victim’s session to perform unauthorized MLflow actions, access UI-visible information, alter metadata, or pivot to additional browser-based attacks.

How to detect it

Review MLflow application logs, reverse proxy logs, artifact store access logs, object storage audit events, and identity provider sign-in logs for suspicious artifact uploads and subsequent victim interactions. Focus on uploads or modifications of files named MLmodel containing script tags, JavaScript URLs, HTML event handlers, encoded payloads, external domains, or unusual iframe/svg/object markup. Correlate suspicious MLmodel uploads with later UI views of the same artifact and unexpected MLflow actions by users who viewed it, such as model stage changes, run edits, experiment deletions, token or credential activity, or administrative operations. Examine browser security telemetry, EDR web history, and proxy/DNS logs for MLflow users contacting unexpected external domains immediately after visiting MLflow artifact pages. Because exploitation requires user interaction and authenticated access, also review anomalous logins, new low-privilege accounts, unexpected artifact uploads, and access from unusual IP addresses or user agents. No public threat actor exploitation or KEV listing is currently indicated, so prioritize local artifact-content hunting over actor-specific indicators.

• MLmodel
• <script
• </script>
• javascript:
• onerror=
• onload=
• onclick=
• onmouseover=
• <iframe
• <svg
• <object
• <embed
• document.cookie
• localStorage
• sessionStorage
• fetch(
• XMLHttpRequest
• eval(
• atob(
• srcdoc=
• data:text/html
• data:application/javascript

What your security team should do

• Inventory all MLflow deployments and identify instances running version 3.10.1 or earlier.
• Restrict access to MLflow UIs and artifact upload functions to trusted authenticated users until upgraded.
• Monitor MLflow release channels and upgrade to the first fixed version newer than 3.10.1 as soon as available.
• Review recently uploaded MLmodel files for embedded HTML, JavaScript, event handlers, script tags, suspicious URLs, or obfuscated payloads.
• Hunt for signs that MLflow users viewed suspicious artifacts followed by unusual model, experiment, or registry changes.
• Apply least-privilege access controls for MLflow users, especially around artifact upload, experiment modification, and model registry actions.
• Ensure session cookies and reverse proxy configurations use secure, HttpOnly, SameSite, and TLS-only settings where supported.
• Add SIEM detections for suspicious MLmodel artifact content and MLflow UI requests associated with script execution attempts.