CVE-2026-27765: vLLM: Gaudi plugin input flaw enables local DoS
UNKNOWNThis CVE affects the vLLM Hardware Plugin for Intel Gaudi accelerators, where improper input validation (CWE-20) lets an authenticated local user crash the inference process, taking down availability while leaving confidentiality and integrity untouched. The practical exposure is narrow: exploitation requires an authenticated user with local access, there's no public exploit or Nuclei template, EPSS sits at 0.00112 (top 98% least likely to be exploited), it's absent from CISA KEV, and CISA's own SSVC decision is TRACK rather than Act-now. The realistic risk scenario is a shared or multi-tenant vLLM deployment on Gaudi HPU hardware, where one authenticated tenant could disrupt inference service for others sharing the accelerator. Upgrade the vLLM Gaudi plugin to 0.16.0 or later, restrict local/shell access to inference hosts to trusted operators only, and add monitoring for unexpected inference worker crashes or restarts as a detection signal. Given the low exploitation likelihood, local-access requirement, and availability-only blast radius, this does not warrant a breaking alert.
How severe is it?
What should I do?
No patch available
Monitor for updates. Consider compensating controls or temporary mitigations.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
Compliance analysis pending. Sign in for full compliance mapping when available.
Frequently Asked Questions
What is CVE-2026-27765?
This CVE affects the vLLM Hardware Plugin for Intel Gaudi accelerators, where improper input validation (CWE-20) lets an authenticated local user crash the inference process, taking down availability while leaving confidentiality and integrity untouched. The practical exposure is narrow: exploitation requires an authenticated user with local access, there's no public exploit or Nuclei template, EPSS sits at 0.00112 (top 98% least likely to be exploited), it's absent from CISA KEV, and CISA's own SSVC decision is TRACK rather than Act-now. The realistic risk scenario is a shared or multi-tenant vLLM deployment on Gaudi HPU hardware, where one authenticated tenant could disrupt inference service for others sharing the accelerator. Upgrade the vLLM Gaudi plugin to 0.16.0 or later, restrict local/shell access to inference hosts to trusted operators only, and add monitoring for unexpected inference worker crashes or restarts as a detection signal. Given the low exploitation likelihood, local-access requirement, and availability-only blast radius, this does not warrant a breaking alert.
Is CVE-2026-27765 actively exploited?
No confirmed active exploitation of CVE-2026-27765 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-27765?
No patch is currently available. Monitor vendor advisories for updates.
What is the CVSS score for CVE-2026-27765?
No CVSS score has been assigned yet.
What are the technical details?
Original Advisory
Improper input validation for some vLLM Hardware Plugin for Intel(R) Gaudi(R) software before version 0.16.0 within Ring 3: User Applications may allow a denial of service. Authorized adversary with an authenticated user combined with a low complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.
Weaknesses (CWE)
CWE-20 — Improper Input Validation: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
- [Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
- [Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
Source: MITRE CWE corpus.