Mistral AI Says Hackers Slipped Malware Into Its SDKs, Here’s What Developers Need to Check Now

Mistral AI, one of Europe’s best-known AI startups, says attackers briefly poisoned official developer packages for its SDKs, turning routine installs and automated updates into a potential security trap.

The company confirmed the supply-chain attack happened May 12, 2026, and involved compromised releases on npm and PyPI. The window was short, just a few hours, but long enough for overnight CI/CD jobs to pull the bad versions and bake them into builds, containers, and caches.

A hacking crew calling itself “TeamPCP” is also claiming it stole about 5GB of internal data, roughly 450 private repositories, and tried to sell it for up to $25,000. Mistral says it has no evidence its broader infrastructure was breached and describes the exposed code as “non-essential.”

What happened: a supply-chain hit, not a direct server break-in

Mistral says attackers didn’t smash through its front door. Instead, they exploited a third-party dependency tied to the TanStack JavaScript ecosystem, popular open-source libraries used across modern web development, to publish compromised versions of Mistral’s SDK packages.

This is the nightmare scenario for software teams: you trust an “official” package from a reputable vendor, your pipeline auto-updates it, and the damage spreads downstream to users and production systems before anyone notices.

The exact versions developers should hunt for

Mistral’s advisory names specific releases that were briefly available and later pulled.

On npm, affected packages include@mistralai/mistralaiversions2.2.2through2.2.4, plus cloud variants@mistralai/mistralai-azureand@mistralai/mistralai-gcpversions1.7.1through1.7.3.

On PyPI, the affected package ismistralaiversion2.4.6.

In practical terms, that means checking lockfiles (package-lock.json, pnpm-lock.yaml, poetry.lock), Docker images, build caches, and any pinned requirements files, because the compromised version may be present even if no one intentionally installed it.

The exposure window was only hours, but that’s enough for CI/CD to spread it

Mistral says the compromised npm packages were published May 11 at22:45 UTCand removed May 12 at01:53 UTC. The compromised PyPI package was published May 12 at00:05 UTCand removed at03:05 UTC.

That’s roughly three hours where an automated nightly build could fetch the tainted dependency, run tests, and push artifacts into registries, quietly distributing the problem across environments.

TeamPCP claims 5GB and 450 private repos; Mistral downplays the scope

The group calling itselfTeamPCPsays it grabbed about5GBof internal data and around450private repositories, and attempted to sell the haul for up to$25,000in cryptocurrency.

Those claims are difficult to verify from the outside, and Mistral is pushing back on the implied severity. The company says the incident centered on briefly compromised SDK packages and that it has no indication, so far, of a broader compromise of its global infrastructure.

Security professionals warn that “non-essential” code can still be valuable to attackers. Internal scripts, configuration patterns, endpoints, and authentication flows can speed up follow-on attacks like targeted phishing, secret hunting, and environment mapping.

Why the PyPI package is the bigger worry, especially for Linux-heavy AI stacks

Mistral says the compromisednpmpackages were effectively harmless in practice because a script referenced a file that didn’t exist, preventing meaningful execution. Even so, a poisoned package can still trigger costly incident response: audits, rebuilds, and sometimes credential rotations.

The more serious risk, according to Mistral’s analysis, was onPyPI. The compromisedmistralai 2.4.6package allegedly executed malicious code automatically when imported onLinux, spawned a background process, and attempted to collect credentials, secrets, and tokens stored on the machine.

The malware also attempted to download and run an additional file from83.142.209.194, an indicator of compromise defenders can use to search proxy logs, EDR telemetry, and DNS history.

Linux targeting matters because so much of AI infrastructure, CI runners, containers, GPU servers, and production inference systems, runs on Linux. A single compromised Python dependency can hit teams who think they’re “just infra,” not end-user software.

What to do now: audit lockfiles, caches, and container images, then rotate secrets if needed

Mistral’s advisory (MAI-2026-002) emphasizes a point many teams learn the hard way: you can be affected even if you never knowingly installed the compromised version. If it landed in a lockfile, build artifact, container layer, or CI cache, it can persist.

Start by identifying any builds and images created during the publication window, quarantine them, and rebuild from known-good lockfiles. Then compare hashes and verify what actually shipped.

Ifmistralai 2.4.6was imported on Linux in CI or production, teams should treat it as a potential credential exposure event, review outbound connections to83.142.209.194, inspect suspicious processes, and rotate sensitive secrets (Git tokens, cloud keys, deployment environment variables) as appropriate.

The bigger takeaway: open-source supply chains are still a soft target

This incident is a reminder that supply-chain attacks scale better than traditional hacks. Instead of breaking into one company, attackers aim for the company’s users, by slipping malicious code into trusted distribution channels.

For fast-moving AI companies and the developers integrating their models, SDKs can feel like “official products.” Security teams have to treat them like any other third-party code: verify, pin, monitor, and harden the publishing and build pipeline end to end, because a few hours is all an attacker needs.