CVE-2026-22778
vLLM · vLLM is an inference and serving engine for large language models Multiple Products
A critical vulnerability exists in the vLLM inference and serving engine that allows an unauthenticated attacker to leak sensitive memory addresses from the server by sending a malformed image.
Executive summary
A critical vulnerability exists in the vLLM inference and serving engine that allows an unauthenticated attacker to leak sensitive memory addresses from the server by sending a malformed image. This information leak can then be used in a subsequent attack to bypass memory protections and achieve remote code execution, leading to a complete compromise of the affected system. Due to the high severity and potential for full system takeover, immediate remediation is required.
Vulnerability
The vulnerability is an information disclosure flaw that can be chained with another vulnerability to achieve remote code execution. An attacker can send a specially crafted, invalid image to a vLLM multimodal endpoint. The underlying Python Imaging Library (PIL) fails to process the image and generates an error, which vLLM improperly forwards to the client without sanitization. This error message contains a heap memory address from the server, which leaks sensitive information about the application's memory layout. This leak effectively bypasses Address Space Layout Randomization (ASLR), a security mechanism designed to prevent memory corruption attacks. With the leaked address, an attacker can reliably exploit a separate heap overflow vulnerability (such as one in a JPEG2000 decoder) to execute arbitrary code with the privileges of the vLLM service.
Business impact
This vulnerability is rated as critical severity with a CVSS score of 9.8. Successful exploitation allows an attacker to gain complete control over the vLLM server, enabling them to execute arbitrary code. This could lead to severe consequences, including the theft of proprietary models, sensitive data being processed by the LLM, and user credentials. A compromised server could also be used to disrupt service (Denial of Service) or as a pivot point to launch further attacks against the internal network. The potential for data breaches, service outages, and reputational damage poses a significant risk to the organization.
Remediation
Immediate Action: Upgrade all affected instances of vLLM to version 0.14.1 or later. This patched version corrects the error handling mechanism to ensure that sensitive memory addresses are no longer leaked to the client. After patching, monitor application logs for any signs of continued exploitation attempts.
Proactive Monitoring: Security teams should monitor for an unusual volume of image processing errors or exceptions originating from the vLLM multimodal endpoint, especially if correlated with a specific source IP. Network traffic should be monitored for any unexpected outbound connections from vLLM servers, which could indicate a successful compromise and command-and-control communication. Review access logs for repeated requests with invalid image data.
Compensating Controls: If immediate patching is not feasible, implement the following controls to mitigate risk:
- Place a Web Application Firewall (WAF) or an API gateway in front of the vLLM endpoint to filter responses and block error messages that contain memory addresses or other sensitive system information.
- Restrict network access to the multimodal endpoint, allowing connections only from trusted and validated sources.
- Run the vLLM service in a sandboxed or containerized environment with strict egress filtering to limit an attacker's ability to communicate outbound if the system is compromised.
Exploitation status
Public Exploit Available: False
Analyst recommendation
Given the critical CVSS score of 9.8 and the potential for unauthenticated remote code execution, this vulnerability represents a severe threat to organizations utilizing affected vLLM versions. Although it is not currently listed in the CISA KEV catalog, its impact warrants immediate attention. We strongly recommend that all affected vLLM instances are patched to version 0.14.1 or later on an emergency basis. If patching cannot be performed immediately, the compensating controls listed above should be implemented as a temporary measure while an upgrade plan is expedited.