PyPI typosquats of openai and transformers carried key-stealing malware; advisories can lag 95 days

What happened

On 11 September 2026, GitHub's Advisory Database reviewed four malware advisories together for PyPI packages named langgrap, openaii, transfomers and ollamaa — each a single character away from langgraph, openai, transformers and ollama, four of the most commonly imported libraries in AI-adjacent Python work. According to a dev.to write-up, the advisories were grouped under one campaign label, 2026-09-openaii, and all four packages have since been pulled: queries against PyPI's JSON API now return 404 for every name.

What the packages did

Per the advisories as summarised on dev.to, each package relied on a malicious .pth file. The mechanism matters: a .pth file executes the moment the Python interpreter starts, in any script in that environment, whether or not anything imports the package. Installation alone is enough.

From there the chain was consistent across all four: download an additional stage from a remote host, exfiltrate SSH keys and cloud credentials, install cryptocurrency mining software, set up persistence that survives a reboot, and clear logs to cover the traces.

One detail stands out. The advisories reportedly describe the payload as containing a deliberate attempt to deter analysis by AI agents, with identical wording in all four write-ups. They do not say which tools were targeted or whether it worked, but the phrasing implies the authors expected an AI coding assistant, not only a human, to be reading the code before it ran.

The version numbers were part of the disguise. The fake transfomers claimed 4.44.2 while the genuine transformers sits at 5.17.0, and openaii claimed 1.55.3 against the real openai client's 3.13.0 — plausible older releases a hurried developer might not think to question.

A second campaign, the same day

The same review cycle covered aitextkit-py and aitextutils-py, a separate campaign (2026-09-aitextkit-py) credited to researcher kam193 through the OpenSSF Malicious Packages Project. It reused the same downloader pattern but a different persistence mechanism, a systemd service named anymeetly-cameradriver. The dev.to author cautions that two campaigns landing on one day are two data points, not a trend, and that nothing in the record shows a shared operator.

The same post is also careful about terminology. GitHub's advisories describe all six packages as typosquatting, and nothing in them suggests an AI model invented the names, so the more dramatic slopsquatting label does not apply. Impact also cannot be measured: PyPI does not expose download figures, and once a package is removed there is no retroactive number, so whether one person or thousands installed any of the six is unknown.

The advisory lag, measured

A second dev.to post quantifies the blind spot this campaign sat inside. The author took the 100 most recent malware advisories for npm from the GitHub Advisory Database, matched each affected package to its first publication date in the npm registry, and measured the gap between the two.

The findings: the median window is zero days, meaning most npm malware is flagged the day it appears. But 30 of the 100 packages had been on the registry for more than a full day, and the worst, unifi-credential-server, was available for 95 days. Notably, 95% of the packages were under 30 days old when their advisory landed. Four packages had already been removed, so their windows could not be computed.

Why it matters

Neither the PyPI campaign nor the npm measurement shows that advisory-based scanning is useless — it covers the 70% of cases where the advisory was effectively immediate, and tools like Dependabot and Snyk catch substantial real risk. The problem is the tail: between publication and advisory, every known-vulnerability scanner reports a malicious package as clean, correctly by its own definition.

The measurable early signal, both posts argue, is metadata visible the instant a dependency appears in a pull request: a package that is days old with almost no adoption. That heuristic is rare enough to be actionable — the author's rule combining recent publication with near-zero adoption fires on roughly one in 290 dependencies that real developers add — and it flags typosquats and model-invented names alike. Their sweep of 1,778 real dependencies found zero AI-hallucinated package names, suggesting that particular attack is rarer than headlines imply. Meanwhile, attackers naming packages after the most-imported AI libraries, and writing payloads that anticipate AI review, have clearly adapted to how modern development actually works.