Two disclosures this week crystallise a problem the security industry has been slow to acknowledge. On Monday, KTransformers — a popular open-source framework for running large language models on GPU servers — was found to expose an unauthenticated remote code execution endpoint scoring CVSS 9.8. The scheduler’s ZMQ socket binds to all network interfaces with no authentication and deserialises arbitrary Python pickle payloads. Any host that can reach the port gets full code execution on what is often a privileged GPU server. On Tuesday, LMDeploy’s vision-language module was exploited in the wild — within thirteen hours of the vulnerability being made public.
Thirteen hours. That is not a gap. That is a race condition between disclosure and exploitation where defenders are structurally disadvantaged.
These are not obscure edge-case tools. KTransformers and LMDeploy are production AI inference infrastructure. They are the engines running LLMs in enterprise environments where teams have decided that a fully managed cloud API is too expensive, too slow, or insufficiently private. As AI moves from cloud consumption to on-premises deployment, the attack surface moves with it — but the security posture has not followed.
The root causes of both vulnerabilities are embarrassingly familiar. Pickle deserialisation of untrusted input is a known-dangerous pattern that Python’s own documentation warns against. Binding a network service to 0.0.0.0 with no authentication is a mistake that web application security training has addressed for fifteen years. These are not novel attack classes discovered by elite researchers — they are hygiene failures that should not exist in any production-grade networked service in 2026.
The charitable explanation is that these frameworks were originally designed as research and development tools — scaffolding for experimenting with model architectures, not infrastructure for securing. The researcher’s mental model is a local workstation or a trusted cluster where everyone on the network is a colleague. That model is functionally accurate in a university HPC environment. It is catastrophically wrong in an enterprise.
The less charitable explanation is that the AI tooling ecosystem has prioritised benchmark performance and ease of installation over security design, and that no one in the review chain — developers, packagers, platform teams, enterprise architects — asked the question: what happens when this binds to a network interface?
The enterprise security failure is more troubling than the developer oversight. Organisations are standing up GPU servers running AI inference frameworks under the same operational model they use for developer laptops — provisioned quickly, largely unmonitored, treated as internal-only because they were designed as internal-only. The gap between “designed for internal use” and “actually isolated from network-accessible paths” is exactly where these vulnerabilities live.
Standard enterprise security controls that would catch this are being systematically bypassed. Vulnerability scanners are not scanning GPU servers because they are “AI infrastructure, not production.” Patch management programmes do not cover open-source Python packages installed via pip. Network segmentation reviews do not include the AI inference tier because it was not in scope when the policy was written. SIEM pipelines do not ingest logs from model servers.
The result is an estate of high-privilege servers running known-vulnerable software on flat network segments, with no monitoring and no patch cadence — and threat actors have noticed.
The pattern is going to accelerate. AI inference frameworks are proliferating faster than any single security team can audit. Every month, new frameworks emerge with new distributed architectures, new inter-process communication schemes, and new default-open configurations. The gap between “AI team decides to self-host a new model” and “security team knows it exists” is measured in weeks to months, not hours.
What needs to change is not primarily the frameworks — though developers should absolutely apply secure-by-default networking and avoid unsafe serialisation. What needs to change is how enterprises classify AI infrastructure.
GPU servers running inference workloads are production servers. They hold sensitive data. They have network access. They run with elevated privileges. They should be in scope for vulnerability scanning, patch management, network segmentation review, and SIEM monitoring — not because AI is special, but because networked services that process data are infrastructure, regardless of the prefix in their name.
The organisations that treat AI toolchain security as a specialised future problem rather than an immediate present one are the organisations that will be explaining a breach to their board next quarter. The attack surface arrived before the security posture. Catching up is the work.