vLLM is an inference and serving engine for large language models (LLMs). Before version 0.11.0rc2, the API key support in vLLM performs validation using a method that was vulnerable to a timing attack. API key validation uses a string comparison that takes longer the more characters the provided API key gets correct. Data analysis across many attempts could allow an attacker to determine when it finds the next correct character in the key sequence. Deployments relying on vLLM's built-in API key validation are vulnerable to authentication bypass using this technique. Version 0.11.0rc2 fixes the issue.
Affected: PyPI: vllm
### Summary The API key support in vLLM performed validation using a method that was vulnerable to a timing attack. This could potentially allow an attacker to discover a valid API key using an approach more efficient than brute force.
### Details https://github.com/vllm-project/vllm/blob/4b946d693e0af15740e9ca9c0e059d5f333b1083/vllm/entrypoints/openai/api_server.py#L1270-L1274
API key validation used a string comparison that will take longer the more characters the provided API key gets correct. Data analysis across many attempts can allow an attacker to determine when it finds the next correct character in the key sequence. ### Impact Deployments relying on vLLM's built-in API key validation are vulnerable to authentication bypass using this technique.
Affected: PyPI: vllm
### Summary The API key support in vLLM performed validation using a method that was vulnerable to a timing attack. This could potentially allow an attacker to discover a valid API key using an approach more efficient than brute force.
### Details https://github.com/vllm-project/vllm/blob/4b946d693e0af15740e9ca9c0e059d5f333b1083/vllm/entrypoints/openai/api_server.py#L1270-L1274
API key validation used a string comparison that will take longer the more characters the provided API key gets correct. Data analysis across many attempts can allow an attacker to determine when it finds the next correct character in the key sequence. ### Impact Deployments relying on vLLM's built-in API key validation are vulnerable to authentication bypass using this technique.
ray: Ray Job Submission Arbitrary Code Execution libtiff: TIFFRasterScanlineSize64 produce too-big size and could cause OOM libtiff: Segment fault in libtiff in TIFFReadRGBATileExt() leading to denial of service shadow-utils: Default subordinate ID configuration in /etc/login.defs could lead to compromise libssh: out-of-bounds read in sftp_handle() vllm: Server Side request forgery (SSRF) in MediaConnector sqlite: Integer Truncation in SQLite libtiff: LibTIFF Use-After-Free Vulnerability openssl: Out-of-bounds read & write in RFC 3211 KEK Unwrap libtiff: Libtiff Write-What-Where golang.org/x/oauth2/jws: Unexpected memory consumption during token parsing in golang.org/x/oauth2/jws golang.org/x/crypto/ssh: Denial of Service in the Key Exchange of golang.org/x/crypto/ssh runc: container escape with malicious config due to /dev/console mount and related races vim: Vim path traversial vim: Vim path traversal firefox: thunderbird: expat: libexpat in Expat allows attackers to trigger large dynamic memory allocations via a small document that is submitted for parsing vllm: Timing Attack in vLLM API Token Verification Leading to Authentication Bypass ray: Ray is vulnerable to RCE via Safari & Firefox Browsers through DNS Rebinding Attack starlette: Starlette DoS via Range header merging vllm: vLLM: Remote Code Execution via malicious model configuration