What Happened
When CVE-2026-33626 was disclosed, attackers quickly began exploiting a server-side request forgery (SSRF) vulnerability in LMDeploy, an open-source toolkit for deploying large language models. Sysdig's honeypot infrastructure detected the first exploitation attempt just 13 hours after the vulnerability became public.
The flaw affects all versions of LMDeploy with vision language support (0.12.0 and prior). This SSRF vulnerability allows attackers to force the application to make requests to internal services and exfiltrate sensitive data that should remain protected from external networks.
Timeline
Hour 0: CVE-2026-33626 is publicly disclosed, detailing the SSRF vulnerability in LMDeploy's vision language processing.
Hour 13: Sysdig honeypot systems record the first exploitation attempt. Attackers probe the vulnerability to access internal metadata services and attempt to pivot to adjacent systems.
Hours 13+: Exploitation activity continues as additional threat actors develop and deploy their own attack tools against vulnerable instances.
Which Controls Failed or Were Missing
This incident reveals three critical control failures:
Vulnerability scanning for AI infrastructure components. Many organizations don't inventory their AI tools with the same rigor as traditional web applications. If you're running LMDeploy in production, your asset management system should have flagged every instance when this CVE was published. That inventory either didn't exist or wasn't actionable.
Emergency patching procedures for high-severity flaws. Thirteen hours is faster than most standard patch cycles, but your emergency response capability should be quicker. When a vulnerability allows direct access to internal services, your team needs a process to patch or mitigate within hours, not days.
Network segmentation around AI services. SSRF vulnerabilities succeed because applications can reach resources they shouldn't. If your LMDeploy instances could query AWS metadata endpoints, internal databases, or other sensitive services, your network architecture provided attackers with everything they needed.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.1 mandates identifying security vulnerabilities using industry-recognized sources and assigning a risk ranking to newly discovered vulnerabilities. For AI infrastructure handling or adjacent to cardholder data, this means:
- Monitoring CVE feeds for all components in your AI stack
- Risk-ranking based on exploitability and data exposure (SSRF with 13-hour exploitation time ranks critical)
- Documented response procedures
PCI DSS v4.0.1 Requirement 6.3.3 requires critical security patches to be installed within one month of release. However, "critical" is defined by your risk assessment. An SSRF in an internet-facing AI service that can access internal resources should trigger your emergency patching protocol, not your 30-day cycle.
Requirement 1.3.3 addresses network segmentation: restrict inbound and outbound traffic to that necessary for the cardholder data environment. Your LMDeploy instances should operate in a network zone where:
- Outbound requests are restricted to specific, necessary destinations
- Internal metadata services are unreachable
- Database access requires explicit firewall rules, not default network visibility
NIST 800-53 Rev 5 Control SI-2 (Flaw Remediation) requires organizations to install security-relevant software updates within time periods defined by organizational risk. For systems with public-facing SSRF vulnerabilities, that time period should be measured in hours, and you need the infrastructure to make that possible.
ISO/IEC 27001:2022 Control 8.8 (Management of Technical Vulnerabilities) requires timely information about technical vulnerabilities, evaluation of exposure, and appropriate measures when vulnerabilities are identified. The 13-hour exploitation window shows why "timely" can't mean weekly vulnerability scans and monthly patch meetings.
Lessons and Action Items for Your Team
Build an AI component inventory this week. Create a configuration management database entry for every AI/ML tool you run in production. Include:
- Component name and version
- Network location and exposure (internet-facing, internal-only, etc.)
- Data classification for what it can access
- Owner and escalation contact
Tag these assets so your vulnerability management system can alert on relevant CVEs immediately.
Define your emergency patch SLA. Write down the conditions that trigger emergency patching:
- Internet-facing service with critical CVSS score
- Exploitation confirmed in the wild within 24 hours
- Vulnerability enables access to sensitive data or internal services
For these scenarios, your target should be mitigation (patch or compensating control) within 24 hours of disclosure. Test this process quarterly.
Implement application-layer egress filtering. Don't rely on your application to make safe requests. Configure your infrastructure to:
- Block access to cloud metadata endpoints (169.254.169.254 for AWS, equivalent for other providers)
- Whitelist specific external domains your AI services legitimately need
- Deny all other outbound traffic by default
For LMDeploy specifically, document which external resources it requires for vision language processing, then block everything else at the network level.
Deploy honeypots for your AI infrastructure. Sysdig detected this exploitation because they run honeypots that mimic vulnerable services. You can do the same:
- Stand up a deliberately vulnerable LMDeploy instance (isolated network, no access to real data)
- Monitor it for exploitation attempts
- Use those attempts to validate your detection rules in production
When you see scanning or exploitation in the honeypot, you know to hunt for the same indicators in your production environment.
Test your SSRF defenses now. Don't wait for the next CVE. Use tools like ssrf-sheriff or Burp Suite to test whether your AI services can:
- Access cloud metadata services
- Query internal DNS
- Reach your database servers
- Access file shares or object storage
If any of these succeed, you have an architecture problem that the next SSRF vulnerability will exploit.
The 13-hour window isn't the anomaly anymore—it's the new baseline. Your vulnerability response process needs to match that speed, and your architecture needs to contain the damage when you don't patch fast enough.
