The Clock Is Already Running
When CVE-2026-33626 dropped on April 24, the LMDeploy inference framework had a critical deserialization flaw that gave unauthenticated attackers remote code execution on GPU hosts running popular LLMs. Within 13 hours, it was under active exploitation in the wild.
Before LMDeploy there was Langflow — 20 hours from disclosure to confirmed attacks. Before Langflow there was Marimo — a Python notebook interface that saw mass exploitation within days. Three AI/ML infrastructure frameworks, three exploitation windows that closed before most organisations finished triaging the CVE notification email.
This is not a run of bad luck. It is the inevitable outcome of a security posture mismatch that the industry has been building for two years: the assumption that AI inference infrastructure lives “inside the firewall” and can be treated with the operational care of a development tool, while it is actually exposed to the internet with the attack surface of a production web server.
Why Inference Servers Are High-Value Targets
It helps to understand what an attacker gets from compromising an LMDeploy server, or any self-hosted inference platform.
The obvious answer is code execution on a GPU host. But that undersells it. Inference servers typically sit at the centre of an organisation’s AI deployment architecture. They have access to proprietary fine-tuned model weights — which represent months of compute spend and may encode sensitive training data. They connect to internal data pipelines that feed them context for retrieval-augmented generation. They authenticate to internal APIs and databases. And they run as service accounts that, in many deployments, were provisioned with generous permissions because “it’s just the AI server.”
A compromised inference server is not just a foothold. In many organisations, it is a keyhole to the entire AI data layer.
The secondary value is scale. Shodan indexes LMDeploy, Langflow, Flowise, and Ollama service banners. When a critical CVE is published with a public proof-of-concept, automated scanning reaches thousands of exposed instances within minutes. The attackers do not need to know your organisation exists. They scan the entire internet for the service version string and fire the exploit at everything that responds.
The Operational Security Mismatch
The teams deploying AI inference infrastructure are overwhelmingly application engineers and ML engineers, not security practitioners. Their operational habits come from software development environments: expose a port to test it, iterate fast, deal with hardening later. “Later” rarely comes, because the model works, the product team is happy, and the inference server becomes load-bearing.
This is not a criticism of those engineers. It is a description of the production gap that every fast-moving technology adoption creates — the same gap that existed with containerisation, with serverless, with cloud-first transitions. The technology moves faster than the security controls, and the attack surface forms before anyone has drawn a boundary around it.
What makes AI infrastructure different is the exploitation velocity. In the early cloud adoption cycle, the window between “exposed misconfiguration” and “exploited by attackers” was measured in weeks or months. Automated exploitation infrastructure has compressed that window dramatically. The exploitation of CVE-2026-33626 in 13 hours required no manual targeting. Someone published a working PoC, an automated scanner found exposed instances, and the exploit ran.
Why Standard Vulnerability Management Fails Here
The conventional vulnerability management cadence — receive CVE notification, triage severity, schedule for next patch window — operates on a 30-to-90-day cycle for most organisations. That cadence was designed for a world where exploitation typically lagged disclosure by weeks or months. It is not useful when exploitation precedes the first patch cycle by six weeks.
What is required for AI infrastructure is the same operational posture applied to internet-exposed web application servers: patch immediately, treat exposure as the primary risk control, and assume that any vulnerable internet-facing instance is compromised before the patch is applied. This means running inference servers behind API gateways with authentication, restricting access to known IP ranges, and maintaining an asset inventory that includes AI infrastructure alongside traditional production services.
None of these requirements are novel. They are standard hardening practices for any production internet service. The gap is that AI infrastructure has not been treated as a production internet service. It has been treated as a development tool that got promoted.
The Asset Inventory Problem
The practical obstacle to closing this gap is that AI inference servers are frequently invisible to the teams responsible for patching them. They are not provisioned through the IT asset management system. They were stood up by a data science team on a cloud VM that was never registered anywhere. The security team does not know they exist.
You cannot patch what you cannot see. You cannot gate access to a service you do not know is internet-exposed. You cannot respond in a 13-hour window to a vulnerability in a platform that is not in your vulnerability scanner’s scope.
The first control is not a patch. It is an inventory. If your organisation is deploying AI inference infrastructure — LMDeploy, Langflow, Ollama, vLLM, any of the other popular frameworks — and you do not have those deployments in your centralised asset register, you are running blind on one of the fastest-growing attack surfaces in your environment.
The Window Has Already Closed
There is a version of this argument that could have been written as a warning six months ago. That version would have said: get ahead of this before attackers figure out the pattern. That version is no longer available. Attackers have already figured out the pattern. Three frameworks in 2026 alone. The exploitation infrastructure is built, the scanning is automated, and the proof-of-concepts are being weaponised faster than disclosure advisories can be processed.
The corrective action is not a future project. It is an immediate audit of what AI inference services your organisation is running, where they are exposed, and whether they have been treated as production infrastructure or as lab equipment. For most organisations, the honest answer to that last question is going to be uncomfortable.