CVE-2026-116176

To mitigate this vulnerability, apply one or more of the following operational controls:

1. Disable disaggregated KV-transfer:
Ensure that vLLM model serving workloads do not configure `--kv-transfer-config` to use `P2pNcclConnector`. Standard model serving without this optional connector avoids invoking the vulnerable address parser. Note that changing container deployment arguments will require restarting the model serving pod, resulting in temporary service interruption.

2. Sanitize ingress request headers:
Configure the ingress controller, API gateway, or reverse proxy fronting the inference service to strip or overwrite incoming `X-Request-Id` HTTP headers with internally generated unique IDs before proxying traffic to the backend vLLM containers.

3. Restrict pod network egress:
Apply OpenShift NetworkPolicy resources or firewall egress rules to restrict outbound network connections from the model serving namespace or pods, permitting communication only to trusted internal endpoints and blocking arbitrary external connections.

Caveats: Disabling `P2pNcclConnector` disables disaggregated prefill and decode functionality. Overwriting request headers may affect distributed request tracing if upstream clients rely on custom tracking headers.

--- CME Mitigation Guidance (2026-11-02) ---
Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure.

The highest-value action is to disable P2pNcclConnector in KV-transfer configurations to eliminate unvalidated address parsing from the X-Request-Id header and prevent backend workers from initiating outbound ZMQ connections: upgrade to vLLM 0.24.0 (or the fixed Rhoai/Odh Vllm Cuda Rhel/Rhoai/Odh Vllm Rocm Rhel/Rhaii/Vllm Neuron Rhel/Rhaii/Vllm Tpu Rhel/Rhoai/Odh Vllm Gaudi Rhel/Rhaii Fast/Vllm Neuron Rhel/Rhoai/Odh Kserve Agent Rhel/Rhoai/Odh Kserve Controller Rhel/Rhoai/Odh Kserve Router Rhel/Rhoai/Odh Kserve Storage Initializer Rhel/Rhaii/Vllm Gaudi Rhel/Rhelai3/Bootc Gaudi Rhel/Rhelai3/Bootc Aws Cuda Rhel/Rhelai3/Bootc Azure Cuda Rhel/Rhelai3/Bootc Azure Rocm Rhel/Rhelai3/Bootc Cuda Rhel/Rhelai3/Bootc Gcp Cuda Rhel/Rhelai3/Bootc Rocm Rhel/Rhaii/Vllm Cpu Rhel/Rhaii/Vllm Cuda Rhel/Rhaii/Vllm Rocm Rhel/Rhaii/Vllm Spyre Rhel/Rhoai/Odh Llm D Kv Cache Rhel/Rhoai/Odh Th Torch Cuda Py312 Rhel/Rhaii Fast/Vllm Gaudi Rhel/Rhaii Fast/Vllm Omni Cuda Rhel/Rhaii Fast/Vllm Spyre Rhel/Rhaii Fast/Vllm Tpu Rhel/Rhaii Fast/Vllm Cpu Rhel/Rhaii Fast/Vllm Rocm Rhel/Rhaii Fast/Vllm Cuda Rhel builds), which remove the vulnerable P2pNcclConnector component, closing crafted X-Request-Id HTTP header containing an arbitrary decode network address. Until patched, this is only a concern on vLLM deployments exposing the HTTP API endpoint configured with disaggregated KV-transfer using P2pNcclConnector — Default vLLM deployments running standard model serving without P2pNcclConnector enabled are unaffected — so Do not configure --kv-transfer-config to use P2pNcclConnector, strip or overwrite incoming X-Request-Id HTTP headers at ingress gateways, and apply egress network policies to block outbound connections from inference pods. As a compensating measure, Enforce allowlist validation on incoming HTTP headers to reject crafted X-Request-Id values containing arbitrary network addresses and Deploy Falco eBPF runtime probes to detect anomalous outbound network connections initiated by vLLM worker processes to unexpected external endpoints. These controls limit blast radius and contain exploitation, but they do not fix the underlying server-side request forgery defect — apply the upstream patch to fully remediate.

Highest-impact CME: CME-1304 SSRF Prevention (Outbound Request Allowlist) (high)