An LLM SDK package name is not a safety signal

Developers keep treating package names that say "LLM SDK" or "AI toolkit" as a soft quality proxy. That habit is understandable. It is also unsafe.
A fresh OSV malware cluster published on 28 September 2026 shows why. Several npm packages branded as AI or LLM SDKs shipped a classic preinstall dropper that writes a native Windows PE and runs it with no user interaction. The branding invited trust. The delivery mechanism did not need any novel AI runtime. It needed npm's install lifecycle.
This is a different failure mode from MCP servers that AI agents install. There the surface is agent-driven discovery of MCP-shaped names. Here the bait is the AI or SDK label itself, even when the implant is a textbook preinstall PE. It is also distinct from provenance and trusted publishing and from download counts as trust. Those posts dismantle other proxies. This one is about naming as bait.
What the advisories state#
Amazon Inspector's OSV entries for nebula-sdk (MAL-2026-17219, also GHSA-fm5g-6rr8-p9vq), nebula-llm (MAL-2026-17227), and llm-nebula (MAL-2026-17230) share a shape.
For nebula-sdk and nebula-llm, the advisory text describes a preinstall.cjs lifecycle script that embeds a base64-encoded, zlib-compressed Windows PE as a string literal. On npm install on Windows, the script decodes and decompresses that blob, writes the executable under %LOCALAPPDATA%\Microsoft\Conhost\conhost.exe (masquerading as the legitimate Console Host binary), and spawns it detached with stdio ignored and windowsHide set so the process is hidden. Advisory details for the PE strings reference a GitHub path and an IP address consistent with a native RAT-family tool. The advertised purpose is an AI or LLM SDK. A bundled Windows executable dropped at install time is unrelated to that purpose.
llm-nebula presents itself as an LLM SDK (a small client stub in the package) while declaring preinstall: node preinstall.cjs. The advisory describes a large obfuscated preinstall.cjs that reconstructs strings and resolves Node builtins dynamically at runtime. That is the same install-time dropper composition: a benign-looking library cover, with the real work in the lifecycle hook.
Affected versions named in those OSV records include nebula-sdk 1.0.0 and 1.0.1, and 1.0.0 for nebula-llm and llm-nebula. GitHub's advisory for nebula-sdk treats any host that installed or ran the package as fully compromised and recommends rotating secrets from a different computer. Those are the public statements. This post does not invent compromise beyond them.
Why the AI name works as bait#
Search, autocomplete, and AI coding assistants already steer people toward names that sound like tooling. Slopsquatting covers hallucinated names attackers wait to claim. This cluster is adjacent: the names look like the category developers and agents are already shopping for. "SDK" and "LLM" read as infrastructure, not as a random utility. That is a trust cue, not an integrity check.
Attackers chose the label because it matches demand. The implant still runs through the oldest npm install path: a lifecycle script with the installer's privileges.
CVE-only scanners miss this class when there is no CVE. NVD describes vulnerabilities in otherwise legitimate software. A malicious publish is a different condition, which is why compromise and CVE state stay independent. Empty cve_ids does not mean safe to install.
What to check before install#
Treat AI- or LLM-branded package names as marketing, not as a safety signal. Read the package.json scripts before you install. A preinstall or postinstall that you did not expect is a stop, not a curiosity. Prefer pinned versions from known publishers. Gate CI and agent install paths on an independent malicious-publish signal before npm install finishes, as outlined in the supply chain docs and the AI agents use case.
If a host already installed a version named in these advisories, follow the advisory remediation: assume compromise of that machine's secrets, rotate from a clean system, and remove the package knowing that removal alone may not undo what already ran.
Attestd's thesis here is narrow. Name integrity and before-install sensing exist because labels like "LLM SDK" fail as proxies. The npm supply chain attacks pillar holds the wider taxonomy. Decide on the exact name and version before the install, not after the branding feels familiar.
Naming is not a control#
An AI or SDK string in an npm package name does not audit the tarball. The September 2026 OSV entries make that concrete: AI branding on the cover, Windows PE delivery in preinstall. Check the advisory, the scripts, and an independent compromise signal. Do not let the category name win the race against install.
Related
EditorialMCP servers that AI agents install are a different risk class
Agent-installed MCP servers are high privilege and often low download. Popularity thresholds miss this class until OSV catches up. What to check before install.
Robert4 min read
Editorialnpm download counts are not a package trust signal
JFrog Equation of Compromise shows download farms can manufacture npm totals. Millions of downloads with zero dependents is a smell, not trust.
Robert7 min read
EditorialThe real cost of a supply chain compromise
Public 2026 npm incidents show supply chain cost as blocked builds, uncertain credential exposure, and rebuilds. CVE dashboards miss that split.
Robert4 min read