# vLLM: isolate KV-transfer and distributed communication

An internal cluster channel can carry execution-sensitive messages without being the public inference API. Restricting /v1 access alone does not control a service bound on a different address or inter-node port.

## What deployment does this concern?

**Component and scope:** PyNcclPipe KV-cache transfer in the V0 engine.

**Affected versions / scope:** 0.6.5 through 0.8.4

**Vendor remediation:** 0.8.5

The affected V0 PyNcclPipe transfer path receives untrusted serialised network messages. Network reachability to the relevant communication service and use of that backend define exposure; this is not a malicious-model-loading case.

## Vendor response and practical action

The vendor identifies 0.8.5 as patched and discusses binding and network isolation. Current security guidance separately warns about insecure defaults in several distributed communication paths.

Treat the vendor notice as the starting point for an applicability decision. Identify the installed artifact and configuration, document whether the prerequisite exists, and assign an owner to any required change. A public advisory does not establish that your installation was exposed or that a managed service shares the same condition.

## What clients can learn

Map public API, model-management and cluster networks independently. Keep worker communication on trusted isolated networks and verify bind addresses, firewall rules and the backend actually in use.

A useful evaluation result connects a named control to evidence from the actual deployment. Keep the provider's statement, your effective configuration and a relevant demonstration together. If the result depends on a feature being disabled or a network being isolated, retain that fact with the version number so a later change triggers review.

## Questions to take to your provider

- Is the deployed engine V0 and is PyNcclPipe KV transfer enabled?
- Which addresses and ports are reachable from untrusted networks?
- What authentication and encryption apply to each distributed channel?
- Which release and topology changes establish remediation?

Use the [six-page evaluation worksheet](/assets/downloads/ai-gateway-evaluation-worksheet.pdf) to record evidence, ownership and actions. Continue with [Running LLM inference in production: security, isolation and capacity](/resources/llm-inference-security-and-operations) for the wider evaluation context.

### Technical detail: evidence and identifier limits

The current documentation must be read for the chosen distributed backend. It does not justify saying every vLLM deployment sends plaintext prompts, weights and outputs through ZeroMQ.

- Primary identifier: GHSA-hjq4-87xh-g4fv; vendor mapping CVE-2025-47277.

Evidence label: **security advisory**. Source-review date: **2026-10-07**. Source publication or event date: **2025-05-20**. These dates do not change merely because this article is rebuilt.

## Primary sources

- [GHSA-hjq4-87xh-g4fv · vendor advisory](https://github.com/vllm-project/vllm/security/advisories/GHSA-hjq4-87xh-g4fv)
- [vLLM security guidance](https://docs.vllm.ai/en/latest/usage/security/)


---
Published: 2026-10-07. Modified: 2026-10-07. Sources reviewed: 2026-10-07.

Author: OneQuill Research. Affiliation: OneQuill develops OneVir. Documentary review; selected case totals are not vendor security rankings.