The most dangerous vulnerability in the AI stack right now didn’t come from a sophisticated exploit chain or a nation-state attacker. It came from developers doing what developers have always done: copying code that works.
Avi Lumelsky, a security researcher at Israeli cybersecurity firm Oligo Security, has published findings on what he calls “ShadowMQ,” a pattern of critical remote code execution vulnerabilities embedded in AI inference frameworks built by Meta, Nvidia, Microsoft, and the PyTorch open source community. The affected projects include vLLM and SGLang, two of the most widely deployed inference serving frameworks in production today, according to Oligo Security’s research disclosure.
The root cause is a bug class that web developers stopped tolerating years ago. These frameworks use ZeroMQ (ZMQ), a lightweight messaging library, for internal process communication. The data moving through those ZMQ channels gets serialized using Python’s pickle module. Pickle will execute arbitrary code during deserialization. This has been documented as dangerous since at least 2014. Every Python security guide says the same thing: never unpickle untrusted data.
Yet here it is, running in production inference infrastructure at four of the largest AI companies on the planet. The AI development community, in its rush to ship, skipped the web’s security lessons entirely.
Not a Bug. A Propagation Pattern.
What makes ShadowMQ different from a single CVE is how it spread. CSO Online and The Hacker News covered this as a vulnerability announcement. It’s more than that.
The security industry has a well-developed vocabulary for supply chain attacks: malicious packages uploaded to PyPI, typosquatting in npm, backdoors planted in open source dependencies. ShadowMQ is a different species. The code wasn’t malicious. It worked exactly as intended. It was just insecure. And it spread through the most human behavior in software development: copying code that works from someone you trust.
One team implemented a ZMQ handler that uses pickle for serialization. It was functional, tested, running at scale. When the next team at a different company needed a process communication layer, they grabbed the existing implementation. Why wouldn’t they? Repeat across four or five major frameworks and you’ve got the same exploitable flaw sitting inside Meta’s LLaMA Stack, Nvidia’s inference tools, Microsoft’s DeepSpeed, and the two most popular open source inference servers.
This is how unsafe patterns metastasize. Not through malice, but through trust. And the security industry doesn’t really have a framework for it yet. We know how to scan for malicious packages. We know how to detect backdoors. We don’t have good tooling for catching insecure-but-functional code that gets copy-pasted across an entire ecosystem by developers acting in good faith.
Why Inference Is the Layer That Matters
There’s an important distinction that most coverage misses. These are not training systems. Training infrastructure processes data in controlled environments with restricted access. Inference servers are the production layer. They handle user requests, process inputs, and return outputs in real time. They are, by definition, network-accessible.
An attacker who achieves RCE on an inference server gets access to the models being served, the data flowing through them, and potentially the broader cloud infrastructure the server connects to. In multi-tenant environments, which is how most cloud AI services operate, that’s catastrophic.
Lumelsky previously worked at Deci AI, a model optimization company that Nvidia acquired. He wasn’t looking at these systems from the outside. He knew where to look because he’d built similar systems himself.
Three Researchers, Three Angles, Same Blind Spot
Lumelsky’s findings don’t exist in isolation. They’re the third data point in a pattern that, as far as I can tell, nobody else has connected.
In late 2025, Michael Bargury at Zenity Labs demonstrated at Black Hat that endpoint detection and response (EDR) tools are effectively blind to on-device AI inference. The monitoring that enterprises rely on to detect threats cannot see what AI models are doing at the endpoint level.
In February, PromptSpy became the first documented case of AI malware using on-device inference as a command and control channel, proving that local AI processing creates covert communication paths traditional security tools can’t observe.
Now Lumelsky shows the inference frameworks themselves have RCE holes that went undetected for years.
Three researchers, three angles, one conclusion: the inference layer is unprotected. EDRs can’t see it. The frameworks have holes. And the architecture itself can be weaponized as a covert channel. The AI security conversation has been consumed by training data poisoning, model theft, and prompt injection for two years. Meanwhile, nobody was checking whether the messaging layer between processes in vLLM was using safe serialization.
The Decade That Got Skipped
The immediate fix is straightforward. Stop using pickle for inter-process communication in any network-accessible system. Use a safe serialization format. Validate inputs before deserialization. These are not novel recommendations. They’ve been standard security guidance for over a decade.
The harder problem is the code reuse chain. Every team that built on these patterns, or borrowed from them, needs to audit their own implementations. That’s a lot of work across a fragmented ecosystem with no central authority to coordinate it.
But the real story here, in my view, is the pattern repetition. The web development community fought these exact battles. Deserialization attacks, unsafe defaults in popular frameworks, insecure code spreading through trusted channels. It took years of breaches, CVEs, and painful lessons before safe-by-default became the expectation. The AI development community appears to be running the same playbook from the start, just faster and with higher stakes. Pickle deserialization in 2026 inference infrastructure is the equivalent of SQL injection in 2006 web apps. We know better. The code doesn’t.
For inquiries and analysis contact laterstack@proton.me