CVE-2026-33626: LMDeploy SSRF Weaponised Within Hours of Disclosure

A server-side request forgery in LMDeploy’s multimodal image loader was being actively exploited within 12 hours and 31 minutes of public disclosure. That’s the headline finding from Sysdig’s threat research team, which observed the first confirmed attack session against their honeypot infrastructure at 01:02 UTC on April 22, 2026 — less than thirteen hours after CVE-2026-33626 was published.

The vulnerability is straightforward in retrospect. The exploit chain to cloud credential theft is not.

The Vulnerability

LMDeploy is an open-source inference and serving framework for large language models developed by the InternLM team at Shanghai AI Lab. It’s widely used to host vision-language models — multimodal systems that accept both text and image inputs — on GPU infrastructure.

The flaw lives in lmdeploy/vl/utils.py, inside the load_image() function. When a request arrives at the LMDeploy API with an image URL rather than base64-encoded image data, load_image() fetches the URL to retrieve the image content. That fetch happens without any validation of the destination IP address.

The consequence is that an attacker who can reach the LMDeploy API endpoint can supply a URL pointing anywhere — including addresses that should never be reachable from an application server, like cloud instance metadata endpoints.

POST /v1/chat/completions HTTP/1.1
Content-Type: application/json

{
  "model": "InternVL2-8B",
  "messages": [{
    "role": "user",
    "content": [
      {"type": "text", "text": "describe this image"},
      {"type": "image_url", "image_url": {"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}}
    ]
  }]
}

The server makes the request, retrieves the metadata service response, and — depending on how the error is surfaced — may return it directly in the API response or in application logs.

CVE-2026-33626 was assigned a CVSS score of 7.5 (High). It is tracked under GitHub Advisory GHSA-6w67-hwm5-92mq and affects all LMDeploy versions up to and including 0.12.0 with vision-language model support.

The Exploitation Timeline

Sysdig’s threat research team maintains a network of honeypots specifically instrumented to detect rapid post-disclosure exploitation of AI and ML infrastructure vulnerabilities. Their report on CVE-2026-33626 documents what they describe as one of the fastest exploitation timelines they’ve observed for a vulnerability in the AI tooling space.

The CVE was published on April 21, 2026. The first exploitation attempt against their honeypot was recorded at 01:02 UTC on April 22 — 12 hours and 31 minutes after disclosure. The session lasted approximately eight minutes and followed a clear, methodical pattern:

1. IMDS credential harvest. The first request targeted http://169.254.169.254/latest/meta-data/iam/security-credentials/ to enumerate available IAM roles.
2. Role credential retrieval. A follow-up request fetched the specific role credentials, including the AccessKeyId, SecretAccessKey, and Token.
3. Internal service enumeration. The attacker probed common internal ports: Redis on 6379, MySQL on 3306, and an HTTP admin interface on 8080.
4. Out-of-band exfiltration confirmation. A DNS lookup to an attacker-controlled subdomain confirmed the instance had outbound DNS resolution and that data could be exfiltrated via DNS if direct HTTP wasn’t available.

The entire session was automated — no human typing pace, consistent timing between requests, identical user-agent across all calls. This was a scanning tool, not manual exploitation.

Why GPU Instances Are a High-Value Target

The severity of an SSRF is determined almost entirely by what lives at the reachable addresses. On a typical on-premises server, IMDS doesn’t exist and the blast radius is limited to whatever is running locally. On cloud-hosted GPU inference nodes, the calculation changes significantly.

GPU instances in cloud environments are routinely granted IAM roles broad enough to do their job: pulling model weights from S3, writing inference logs to CloudWatch, reading configuration from Secrets Manager, sometimes pushing results to downstream services. That’s a lot of permissions for a role that becomes fully accessible the moment an attacker can hit 169.254.169.254.

Sysdig notes in their report that the temporary credentials returned by IMDS carry the full permission set of the attached instance role. An attacker who harvests those credentials has, in effect, harvested the cloud account access of whatever IAM principal the GPU node is running as. Depending on how the role is scoped, that can mean access to other S3 buckets, the ability to call other AWS services, and the ability to persist access by creating new IAM users or roles if the instance role has IAM write permissions.

The specific IAM permissions on any given deployment are not controlled by LMDeploy — they’re set by the operator. But the vulnerability makes those permissions reachable from an unauthenticated API request.

Who Is Exposed

Any deployment of LMDeploy 0.12.0 or earlier that:

• Serves a vision-language model (text-only LMDeploy deployments are not affected — the vulnerable code path requires image URL processing)
• Runs on cloud infrastructure with an accessible IMDS endpoint
• Has the LMDeploy API reachable from untrusted networks

The last condition is worth pausing on. Some LMDeploy deployments are internal-only. But operators who expose inference APIs to external applications — including applications that forward user-supplied image URLs — are effectively exposing the SSRF to whoever can reach those upstream applications.

The InternVL2 and InternVL3 model families are popular LMDeploy workloads and both are vision-language models. Deployments using these or any other multimodal model should be treated as affected.

The Fix

LMDeploy 0.12.1 patches the vulnerability by adding destination validation to load_image(). Before making any URL fetch, the patched version resolves the target hostname and checks whether the resulting IP falls within any private, link-local, or loopback range. URLs resolving to 169.254.0.0/16 (AWS/GCP IMDS), 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 127.0.0.0/8 are rejected before the request is made.

This is the correct fix — it addresses the root cause rather than attempting to block specific known-bad endpoints, which would be trivially bypassable via redirect chains or DNS manipulation.

Recommended Actions

Upgrade immediately. If you are running any LMDeploy version ≤ 0.12.0 with a vision-language model, upgrade to 0.12.1. The patch is available on PyPI and the fix is documented in the release notes.

Patch your IMDSv2 configuration. On AWS, enforce IMDSv2 (the token-based metadata service) on all GPU instances. IMDSv2 requires a PUT request to obtain a session token before any metadata can be retrieved — this breaks the simple GET-based SSRF shown in the exploit, though it does not eliminate SSRF risk entirely.

Audit your IAM roles. Review the instance profiles attached to your GPU inference nodes. Remove any permissions not required for the inference workload. If the role currently has IAM write permissions, remove them immediately.

Check for post-exploitation indicators. If you were running a vulnerable version during the April 21-22 window, check CloudTrail for unexpected API calls using credentials associated with your GPU instance roles. Look for calls to IAM, S3 ListBuckets, or any service outside the normal operational pattern for those roles.

Network-layer mitigations. Block outbound access from GPU inference nodes to 169.254.169.254 at the network level as a defence-in-depth measure, independent of the application-layer fix.

The exploitation of CVE-2026-33626 within hours of disclosure follows a pattern that is becoming standard for AI infrastructure vulnerabilities: they’re technically approachable, the tooling is popular, and the target environments tend to have cloud credentials that make exploitation disproportionately valuable. The assumption that AI inference infrastructure lives on a protected internal network — if it ever was accurate — is no longer a reliable baseline to plan around.