CVE-2026-33865: 
NixOS vulnerability analysis and mitigation

CVE-2026-33865 is a Stored Cross-Site Scripting (XSS) vulnerability in MLflow's web interface caused by unsafe YAML parsing of MLmodel artifacts. An authenticated attacker can upload a malicious MLmodel file containing a JavaScript payload that executes in the browser of any user who views the artifact in the UI, enabling session hijacking or unauthorized actions on behalf of the victim. The vulnerability affects all MLflow versions through 3.10.1, with the fix introduced in version 3.11.1. It was published on April 7, 2026, and carries a CVSS v3.1 score of 5.4 (Medium) and a CVSS v4.0 score of 5.1 (Medium) (GitHub Advisory, Feedly).

The root cause is the use of yaml.load() instead of yaml.safeLoad() in MLflow's frontend JavaScript code (specifically in ShowArtifactLoggedModelView.tsx and useValidateLoggedModelSignature.ts) when parsing MLmodel YAML artifact content (CWE-79). In js-yaml v3.x, yaml.load() supports JavaScript-specific YAML tags such as !!js/function, which allow arbitrary JavaScript execution when processing attacker-controlled content. An authenticated attacker crafts a malicious MLmodel file embedding a !!js/function payload in the YAML structure, uploads it as an artifact, and the payload executes in the victim's browser when they navigate to the artifact view. A public proof-of-concept including a complete Python script and malicious YAML payload structure has been published (GitHub PR #21435, Afine Blog).

Successful exploitation allows an authenticated attacker to execute arbitrary JavaScript in the browser context of any MLflow user who views the malicious artifact, enabling session token theft, account takeover, and unauthorized operations performed on behalf of the victim. The scope is changed (cross-origin impact), with low confidentiality and integrity impacts on both the vulnerable and subsequent systems, and no availability impact. In multi-user MLflow deployments — common in enterprise ML pipelines — this could allow lateral movement by compromising higher-privileged accounts such as administrators or data scientists with broader access (GitHub Advisory, Feedly).

A public proof-of-concept exploit is available on the Afine security blog, including a malicious YAML payload using the !!js/function tag, a complete Python PoC script using MLflow's client to log the artifact, and a trigger URL targeting a real MLflow instance (Afine Blog). The exploit is rated high confidence and classified as actionable reproduction steps. As of the time of reporting, there is no evidence of in-the-wild exploitation, and the CVE is not listed in the CISA KEV catalog. The EPSS score is approximately 0.054%, indicating low but non-negligible exploitation probability. The vulnerability is detectable by Qualys scanner (detection ID: 5010630) (Feedly).

1. Reconnaissance: Identify a target MLflow instance (version ≤ 3.10.1) accessible via the web UI. Confirm the version by checking the MLflow UI or API endpoints.
2. Authenticate: Obtain valid credentials for the MLflow instance — any low-privileged user account with artifact upload permissions is sufficient.
3. Craft malicious MLmodel file: Create a YAML file named MLmodel containing a !!js/function payload in a field that will be parsed by the frontend, for example:

flavors:
  python_function:
    loader_module: !!js/function 'function(){alert(document.cookie);}'

4. Upload the artifact: Use the MLflow Python client or REST API to log the malicious MLmodel file as an artifact to an experiment run:

import mlflow
mlflow.set_tracking_uri("http://target-mlflow-instance")
with mlflow.start_run() as run:
    mlflow.log_artifact("MLmodel")
    print(run.info.run_id)

5. Deliver the trigger URL: Share or social-engineer a victim user into visiting the artifact view URL: http://mlflow-instance/#/experiments/<id>/runs/<run_id>/artifacts/logged_model
6. Payload execution: When the victim's browser loads the artifact view, the frontend parses the YAML using yaml.load(), executing the injected JavaScript — enabling cookie theft, session hijacking, or further actions on behalf of the victim (Afine Blog, GitHub PR #21435).

• Network: Unusual outbound HTTP requests from a victim's browser to attacker-controlled domains shortly after accessing an MLflow artifact view URL; unexpected POST requests to MLflow API endpoints (e.g., experiment or run creation) not initiated by the user.
• File System / Artifacts: MLmodel YAML files in artifact storage containing !!js/function, !!js/regexp, or other JavaScript-specific YAML tags; unexpected or anomalously structured MLmodel files uploaded by non-standard users.
• Logs: MLflow access logs showing artifact uploads (PUT or POST to artifact endpoints) followed shortly by other users accessing the same artifact path; browser console errors related to YAML parsing in older MLflow versions.
• Process/Session: Unexpected API calls (experiment deletion, run modification, user permission changes) originating from a victim user's session token that do not match their normal activity pattern (Afine Blog, GitHub Advisory).

Upgrade MLflow to version 3.11.1 or later, which replaces yaml.load() with yaml.safeLoad() in the affected frontend components (ShowArtifactLoggedModelView.tsx and useValidateLoggedModelSignature.ts), preventing execution of JavaScript-specific YAML tags (GitHub PR #21435, GitHub Advisory). As interim mitigations: restrict MLmodel artifact upload permissions to trusted users only; implement Content Security Policy (CSP) headers on the MLflow web interface to limit the impact of any XSS execution; and monitor artifact storage for MLmodel files containing suspicious YAML tags such as !!js/function.

The vulnerability was discovered and reported by researchers at Afine, who published a detailed technical blog post including a proof-of-concept (Afine Blog). CERT-PL, which assigned the CVE, published an advisory on their website (CERT-PL). The MLflow maintainer harupy promptly merged the fix on March 6, 2026, ahead of the public CVE disclosure on April 7, 2026, and the patch was labeled for inclusion in the next patch release (v3.10.2 label was applied, with the fix shipping in 3.11.1). Coverage also appeared on Malware News and security aggregators shortly after disclosure.