LMDeploy CVE-2026-33626: 12-hour time-to-exploit on an AI inference engine

Twelve Hours and Thirty-One Minutes

On April 21, 2026, GitHub published GHSA-6w67-hwm5-92mq, later assigned CVE-2026-33626, against LMDeploy — the InternLM / Shanghai AI Laboratory toolkit for serving vision-language and text large language models. The flaw lives in the load_image() function in lmdeploy/vl/utils.py, which fetches arbitrary URLs to materialize images for the vision-language inference path. The function had no internal- or private-IP-range validation, which makes it a textbook Server-Side Request Forgery primitive. CVSS scored it 7.5.

Twelve hours and thirty-one minutes later, the Sysdig Threat Research Team observed the first exploitation attempt against their honeypot fleet. In an eight-minute attack session, the operator used the vision-LLM image loader as a generic HTTP SSRF primitive and port-scanned the internal network behind the model server: AWS Instance Metadata Service (IMDS), Redis, MySQL, a secondary HTTP administrative interface, and an out-of-band DNS exfiltration endpoint. The attacker did not need to bring exploit tooling; they used the legitimate load_image() request shape.

What separates CVE-2026-33626 from a textbook SSRF write-up is the host fleet the SSRF primitive ran on. Vision-LLM inference runs on GPU-equipped instances — A100s, H100s, L40s. Those instances are provisioned with broad IAM roles that need to read model artifacts from S3, write checkpoints, sometimes assume cross-account roles into training data lakes. A single successful fetch of the AWS Instance Metadata Service token (http://169.254.169.254/latest/meta-data/iam/security-credentials/) from inside the inference process gives the attacker, in clear text, the temporary credentials of the inference node’s IAM role. From there, the IAM blast radius is whatever the role’s policy allows — and on production inference fleets, the policy is rarely tight.

One SSRF, twelve hours of time-to-exploit, and the AI inference layer becomes an IAM-credential-disclosure primitive.

AI Inference Engines Are Production Infrastructure Now

The category boundary that platform-engineering teams have been holding — “AI inference is a research workload, the security posture catches up later” — has collapsed in 2026. Three reasons:

• Inference engines are now reachable from production application traffic. Every customer-facing chatbot, every vision-LLM-powered document pipeline, every multimodal search surface routes user-controlled input through load_image()-shaped code paths. The 2025 framing of “inference is a backend research tool” no longer matches the production deployment shape.
• GPU-instance IAM is structurally broad. S3 model-artifact access, training-data access, cross-account assume-role for fine-tuning pipelines, ECR access for inference container pulls. The inference role’s blast radius is wider than most application-tier roles by default.
• The inference toolkit ecosystem is young. LMDeploy is a 2023-vintage Python project from a research lab. vLLM is a 2023-vintage Python project from Berkeley. SGLang is a 2024-vintage Python project from LMSys. Production-grade input validation is not the legacy of any of these projects. The security maturity curve is at the front of the inflection.

Six other n8n-class CVEs in the workflow-automation adjacency since January 2026 (the CVE-2026-21858 “Ni8mare” RCE in n8n, max-severity at CVSS 10.0, was the most-cited), plus the Azure SRE Agent CVE-2026-32173 from late April, make the year-to-date picture clear: AI-orchestration toolkits and AI-inference toolkits are now CVE-class production-infrastructure software, with a young codebase and a fast time-to-exploit.

The Sysdig Honeypot Replay, Step by Step

Sysdig’s published timeline of the attack session lays out the exact playbook a 2026 security-agent posture has to defend against:

1. Reconnaissance via the legitimate API. The attacker hit the LMDeploy /v1/chat/completions endpoint with a vision-language prompt that included an image URL pointing at http://169.254.169.254/latest/meta-data/. The inference engine dutifully fetched the metadata page.
2. IMDSv1 token harvest. The metadata response contained the IAM role name and, on IMDSv1, the credential triplet (access key, secret key, session token) without a session-token requirement.
3. Internal port scan. The attacker chained the SSRF into a sweep of internal RFC1918 ranges, fingerprinting Redis (port 6379), MySQL (port 3306), and a secondary HTTP administrative interface.
4. Out-of-band exfiltration. The credential triplet was exfiltrated via a DNS lookup to an attacker-controlled domain, sidestepping any egress proxy that would have blocked an outbound HTTPS POST.
5. Persistence preparation. The session ended with reconnaissance against the secondary admin interface — the staging step before a re-entry path is established.

Steps 1-4 fit inside eight minutes. The full kill-chain on a less-instrumented target would have taken less.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

The 2026 Security-Agent Posture for Self-Hosted AI Inference

Five concrete controls every platform-engineering team running self-hosted AI inference should put in place this quarter:

1. Enforce IMDSv2 on every GPU instance. IMDSv2 requires a session-token PUT before a credential GET. SSRF primitives that issue raw HTTP GETs against the metadata endpoint return 401. The fix is one Terraform / CloudFormation / Pulumi line per launch template. There is no reason any 2026 inference fleet should be running with IMDSv1 still enabled.

2. Restrict egress to the internal-IP space. Inference nodes should not be allowed to issue outbound HTTP / HTTPS / DNS to arbitrary destinations. Egress should be whitelisted to the model-provider endpoints, the artifact stores, and the telemetry stack. The Sysdig honeypot replay’s DNS exfiltration step depends on permissive egress.

3. Tighten the IAM role on inference instances. Read-only S3 access scoped to the specific model-artifact prefix. No write back to the training data lake from the inference role. No iam:PassRole or sts:AssumeRole unless explicitly required and audited.

4. Validate URLs in vision-LLM image loaders. Code-level fix: any fetch_url() shape on the inference path validates against an allow-list of public destinations, blocks RFC1918 and link-local ranges, blocks localhost, and enforces a request timeout. The LMDeploy patched release does exactly this.

5. Wire continuous-audit agent coverage on inference fleets. A security-agent that re-runs the five controls above against every inference node every day catches drift before it ships to production. This is the active-operational-layer pattern: the agent does the audit, the platform team is notified only when an exception fires.

How IAN Helps: The Security Agent on the Active Operational Layer

IAN is the AI DevOps team for cloud infrastructure, delivered as a coordinated team of specialized agents on the active operational layer. The security agent inside the IAN team is built to keep the inference-fleet posture above:

• Continuous IMDSv2-enforcement audit. The security agent re-runs the IMDSv2-only check across every GPU instance in every connected cloud account daily, surfaces drift as an Operate-tier remediation PR, and tracks the remediation rate on the inventory dashboard.
• Egress-policy drift detection. The security agent watches security-group rules and VPC egress configurations for the inference-fleet subnet, flags any rule that opens the egress aperture beyond the allow-list, and proposes a scoped revert.
• IAM-role-scope analysis. The security agent compares the IAM-role policy attached to each inference instance to the access pattern observed in CloudTrail, surfaces unused permissions, and proposes a tightened policy as an Operate-tier remediation PR.
• Vision-LLM toolkit dependency tracking. The security agent watches the installed-package manifest on every inference node for known-vulnerable versions of LMDeploy, vLLM, SGLang, and other inference toolkits, opens a remediation PR when the deployed version trails the patched version, and prioritizes by CVE severity.
• BYOK on model keys. Customers bring their own Anthropic / OpenAI / model-provider keys, stored in the customer’s secret manager. Inference traffic flows direct from IAN’s orchestration layer to the customer’s model provider — the security agent does not see prompts or chain-of-thought.

The Three-Phase Rollout

Phase 1 — Audit the inference fleet. Run the security-agent Observe pass against every GPU instance — IMDSv2 enforcement, egress policy, IAM-role scope, installed-package versions. Surface the gap inventory. Two-to-four weeks.

Phase 2 — Codify the inference-fleet baseline. Promote the security-agent’s checks from Observe-only to Operate-tier remediation PRs. Pre-authorize the scoped patches: IMDSv2 flag flips, egress whitelist tightenings, IAM-policy diff applies. Two-to-three months.

Phase 3 — Cross the security / cost / SRE agent loop. The inference-fleet inventory feeds the cost-agent’s GPU-utilization audit and the SRE-agent’s incident-context surface. A CVE-disclosure event against a deployed inference toolkit becomes a cost-and-availability signal as well as a security signal.

CVE-2026-33626’s twelve-hour-thirty-one-minute time-to-exploit is the headline number. The structural lesson is that AI inference engines are now production infrastructure. The 2026 security-agent posture treats them that way.

Get a free infrastructure audit → | See pricing →