cvelistv5 - cve-2025-30202

cve-2025-30202

Vulnerability from cvelistv5

Published

2025-04-30 00:24

Modified

2025-04-30 13:16

Severity ?

7.5 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Summary

Data exposure via ZeroMQ on multi-node vLLM deployment

References

▼	URL	Tags
	security-advisories@github.com	https://github.com/vllm-project/vllm/commit/a0304dc504c85f421d38ef47c64f83046a13641c
	security-advisories@github.com	https://github.com/vllm-project/vllm/pull/6183
	security-advisories@github.com	https://github.com/vllm-project/vllm/security/advisories/GHSA-9f8f-2vmf-885j

Impacted products

▼	Vendor	Product
	vllm-project	vllm

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-30202",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-04-30T13:16:29.868734Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-04-30T13:16:43.914Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "vllm",
          "vendor": "vllm-project",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 0.5.2, \u003c 0.8.5"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Versions starting from 0.5.2 and prior to 0.8.5 are vulnerable to denial of service and data exposure via ZeroMQ on multi-node vLLM deployment. In a multi-node vLLM deployment, vLLM uses ZeroMQ for some multi-node communication purposes. The primary vLLM host opens an XPUB ZeroMQ socket and binds it to ALL interfaces. While the socket is always opened for a multi-node deployment, it is only used when doing tensor parallelism across multiple hosts. Any client with network access to this host can connect to this XPUB socket unless its port is blocked by a firewall. Once connected, these arbitrary clients will receive all of the same data broadcasted to all of the secondary vLLM hosts. This data is internal vLLM state information that is not useful to an attacker. By potentially connecting to this socket many times and not reading data published to them, an attacker can also cause a denial of service by slowing down or potentially blocking the publisher. This issue has been patched in version 0.8.5."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-04-30T00:24:45.723Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/vllm-project/vllm/security/advisories/GHSA-9f8f-2vmf-885j",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-9f8f-2vmf-885j"
        },
        {
          "name": "https://github.com/vllm-project/vllm/pull/6183",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/vllm-project/vllm/pull/6183"
        },
        {
          "name": "https://github.com/vllm-project/vllm/commit/a0304dc504c85f421d38ef47c64f83046a13641c",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/vllm-project/vllm/commit/a0304dc504c85f421d38ef47c64f83046a13641c"
        }
      ],
      "source": {
        "advisory": "GHSA-9f8f-2vmf-885j",
        "discovery": "UNKNOWN"
      },
      "title": "Data exposure via ZeroMQ on multi-node vLLM deployment"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-30202",
    "datePublished": "2025-04-30T00:24:45.723Z",
    "dateReserved": "2025-03-18T18:15:13.849Z",
    "dateUpdated": "2025-04-30T13:16:43.914Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-30202\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2025-04-30T01:15:51.800\",\"lastModified\":\"2025-04-30T01:15:51.800\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Versions starting from 0.5.2 and prior to 0.8.5 are vulnerable to denial of service and data exposure via ZeroMQ on multi-node vLLM deployment. In a multi-node vLLM deployment, vLLM uses ZeroMQ for some multi-node communication purposes. The primary vLLM host opens an XPUB ZeroMQ socket and binds it to ALL interfaces. While the socket is always opened for a multi-node deployment, it is only used when doing tensor parallelism across multiple hosts. Any client with network access to this host can connect to this XPUB socket unless its port is blocked by a firewall. Once connected, these arbitrary clients will receive all of the same data broadcasted to all of the secondary vLLM hosts. This data is internal vLLM state information that is not useful to an attacker. By potentially connecting to this socket many times and not reading data published to them, an attacker can also cause a denial of service by slowing down or potentially blocking the publisher. This issue has been patched in version 0.8.5.\"},{\"lang\":\"es\",\"value\":\"vLLM es un motor de inferencia y servicio de alto rendimiento y eficiente en memoria para LLM. Las versiones a partir de la 0.5.2 y anteriores a la 0.8.5 son vulnerables a denegaci\u00f3n de servicio y exposici\u00f3n de datos a trav\u00e9s de ZeroMQ en implementaciones de vLLM multinodo. En una implementaci\u00f3n de vLLM multinodo, vLLM utiliza ZeroMQ para algunos fines de comunicaci\u00f3n multinodo. El host vLLM principal abre un socket XPUB ZeroMQ y lo vincula a TODAS las interfaces. Si bien el socket siempre est\u00e1 abierto para implementaciones multinodo, solo se utiliza al realizar paralelismo tensorial en varios hosts. Cualquier cliente con acceso de red a este host puede conectarse a este socket XPUB a menos que su puerto est\u00e9 bloqueado por un firewall. Una vez conectados, estos clientes arbitrarios recibir\u00e1n los mismos datos transmitidos a todos los hosts vLLM secundarios. Estos datos son informaci\u00f3n interna del estado de vLLM que no es \u00fatil para un atacante. Al conectarse a este socket muchas veces y no leer los datos publicados, un atacante tambi\u00e9n puede causar una denegaci\u00f3n de servicio al ralentizar o incluso bloquear al publicador. Este problema se ha corregido en la versi\u00f3n 0.8.5.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":7.5,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":3.9,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-770\"}]}],\"references\":[{\"url\":\"https://github.com/vllm-project/vllm/commit/a0304dc504c85f421d38ef47c64f83046a13641c\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/vllm-project/vllm/pull/6183\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/vllm-project/vllm/security/advisories/GHSA-9f8f-2vmf-885j\",\"source\":\"security-advisories@github.com\"}]}}"
  }
}

ghsa-9f8f-2vmf-885j

Vulnerability from github

Published

2025-04-29 14:50

Modified

2025-04-30 17:26

Severity ?

7.5 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Summary

Data exposure via ZeroMQ on multi-node vLLM deployment

Details

Impact

In a multi-node vLLM deployment, vLLM uses ZeroMQ for some multi-node communication purposes. The primary vLLM host opens an XPUB ZeroMQ socket and binds it to ALL interfaces. While the socket is always opened for a multi-node deployment, it is only used when doing tensor parallelism across multiple hosts.

Any client with network access to this host can connect to this XPUB socket unless its port is blocked by a firewall. Once connected, these arbitrary clients will receive all of the same data broadcasted to all of the secondary vLLM hosts. This data is internal vLLM state information that is not useful to an attacker.

By potentially connecting to this socket many times and not reading data published to them, an attacker can also cause a denial of service by slowing down or potentially blocking the publisher.

Detailed Analysis

The XPUB socket in question is created here:

https://github.com/vllm-project/vllm/blob/c21b99b91241409c2fdf9f3f8c542e8748b317be/vllm/distributed/device_communicators/shm_broadcast.py#L236-L237

Data is published over this socket via MessageQueue.enqueue() which is called by MessageQueue.broadcast_object():

https://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/device_communicators/shm_broadcast.py#L452-L453

https://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/device_communicators/shm_broadcast.py#L475-L478

The MessageQueue.broadcast_object() method is called by the GroupCoordinator.broadcast_object() method in parallel_state.py:

https://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/parallel_state.py#L364-L366

The broadcast over ZeroMQ is only done if the GroupCoordinator was created with use_message_queue_broadcaster set to True:

https://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/parallel_state.py#L216-L219

The only case where GroupCoordinator is created with use_message_queue_broadcaster is the coordinator for the tensor parallelism group:

https://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/parallel_state.py#L931-L936

To determine what data is broadcasted to the tensor parallism group, we must continue tracing. GroupCoordinator.broadcast_object() is called by GroupCoordinator.broadcoast_tensor_dict():

https://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/parallel_state.py#L489

which is called by broadcast_tensor_dict() in communication_op.py:

https://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/communication_op.py#L29-L34

If we look at _get_driver_input_and_broadcast() in the V0 worker_base.py, we'll see how this tensor dict is formed:

https://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/worker/worker_base.py#L332-L352

but the data actually sent over ZeroMQ is the metadata_list portion that is split from this tensor_dict. The tensor parts are sent via torch.distributed and only metadata about those tensors is sent via ZeroMQ.

https://github.com/vllm-project/vllm/blob/54a66e5fee4a1ea62f1e4c79a078b20668e408c6/vllm/distributed/parallel_state.py#L61-L83

Patches

No fix yet.

Workarounds

Prior to the fix, your options include: 1. Do not expose the vLLM host to a network where any untrusted connections may reach the host. 2. Ensure that only the other vLLM hosts are able to connect to the TCP port used for the XPUB socket. Note that port used is random.

References

Relevant code first introduced in https://github.com/vllm-project/vllm/pull/6183

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.2"
            },
            {
              "fixed": "0.8.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-30202"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-29T14:50:59Z",
    "nvd_published_at": "2025-04-30T01:15:51Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nIn a multi-node vLLM deployment, vLLM uses ZeroMQ for some multi-node communication purposes. The primary vLLM host opens an `XPUB` ZeroMQ socket and binds it to ALL interfaces. While the socket is always opened for a multi-node deployment, it is only used when doing tensor parallelism across multiple hosts.\n\nAny client with network access to this host can connect to this `XPUB` socket unless its port is blocked by a firewall. Once connected, these arbitrary clients will receive all of the same data broadcasted to all of the secondary vLLM hosts. This data is internal vLLM state information that is not useful to an attacker.\n\nBy potentially connecting to this socket many times and not reading data published to them, an attacker can also cause a denial of service by slowing down or potentially blocking the publisher.\n\n### Detailed Analysis\n\nThe `XPUB` socket in question is created here:\n\nhttps://github.com/vllm-project/vllm/blob/c21b99b91241409c2fdf9f3f8c542e8748b317be/vllm/distributed/device_communicators/shm_broadcast.py#L236-L237\n\nData is published over this socket via `MessageQueue.enqueue()` which is called by `MessageQueue.broadcast_object()`:\n\nhttps://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/device_communicators/shm_broadcast.py#L452-L453\n\nhttps://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/device_communicators/shm_broadcast.py#L475-L478\n\nThe `MessageQueue.broadcast_object()` method is called by the `GroupCoordinator.broadcast_object()` method in `parallel_state.py`:\n\nhttps://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/parallel_state.py#L364-L366\n\nThe broadcast over ZeroMQ is only done if the `GroupCoordinator` was created with `use_message_queue_broadcaster` set to `True`:\n\nhttps://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/parallel_state.py#L216-L219\n\nThe only case where `GroupCoordinator` is created with `use_message_queue_broadcaster` is the coordinator for the tensor parallelism group:\n\nhttps://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/parallel_state.py#L931-L936\n\nTo determine what data is broadcasted to the tensor parallism group, we must continue tracing. `GroupCoordinator.broadcast_object()` is called by `GroupCoordinator.broadcoast_tensor_dict()`:\n\nhttps://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/parallel_state.py#L489\n\nwhich is called by `broadcast_tensor_dict()` in `communication_op.py`:\n\nhttps://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/distributed/communication_op.py#L29-L34\n\nIf we look at `_get_driver_input_and_broadcast()` in the V0 `worker_base.py`, we\u0027ll see how this tensor dict is formed:\n\nhttps://github.com/vllm-project/vllm/blob/790b79750b596043036b9fcbee885827fdd2ef3d/vllm/worker/worker_base.py#L332-L352\n\nbut the data actually sent over ZeroMQ is the `metadata_list` portion that is split from this `tensor_dict`. The tensor parts are sent via `torch.distributed` and only metadata about those tensors is sent via ZeroMQ.\n\nhttps://github.com/vllm-project/vllm/blob/54a66e5fee4a1ea62f1e4c79a078b20668e408c6/vllm/distributed/parallel_state.py#L61-L83\n\n### Patches\n\nNo fix yet.\n\n### Workarounds\n\nPrior to the fix, your options include:\n1. Do not expose the vLLM host to a network where any untrusted connections may reach the host.\n2. Ensure that only the other vLLM hosts are able to connect to the TCP port used for the `XPUB` socket. Note that port used is random.\n\n### References\n\n* Relevant code first introduced in https://github.com/vllm-project/vllm/pull/6183",
  "id": "GHSA-9f8f-2vmf-885j",
  "modified": "2025-04-30T17:26:58Z",
  "published": "2025-04-29T14:50:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-9f8f-2vmf-885j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30202"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/6183"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/a0304dc504c85f421d38ef47c64f83046a13641c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Data exposure via ZeroMQ on multi-node vLLM deployment"
}

Action not permitted

cve-2025-30202

Vulnerability from cvelistv5

ghsa-9f8f-2vmf-885j

Vulnerability from github

Impact

Detailed Analysis

Patches

Workarounds

References

Tags