Live Exposure Defense: From CVE to Confirmed Exposure in 12 Hours – See more

Back
New CVE Detected

CVE-2026-92971 – Unauthenticated Denial of Service – InternLM LMDeploy ≤ 0.17.0

Be the first to know when new zero-days emerge:

Subscribe to Email Alerts
Subscribe to RSS Feed

Summary

CVE-2026-92971 is a reachable assertion vulnerability (CWE-617) in InternLM’s LMDeploy, an open-source toolkit for serving large language models. The flaw resides in LMDeploy’s DistServe prefill/decode disaggregation feature, where an unauthenticated attacker can send a crafted request to a Decode node’s OpenAI-compatible API to crash the inference engine’s main loop. The issue affects LMDeploy through version 0.17.0 and carries a high severity rating (8.7).

Technical details

  • Root cause: LMDeploy’s DistServe Decode API endpoints (/v1/completions and /v1/chat/completions) accept a migration_request field directly from the external request body and pass it, with only shape-level Pydantic validation, into the internal prefill/decode (P/D) cache migration path — no verification is performed that the request originates from a trusted peer or that its contents are internally consistent.
  • Trigger conditions: An attacker submits a request to a Decode node with a migration_request whose remote_block_ids field is an empty list. When the Decode scheduler compares the (empty) remote block count against the number of locally allocated blocks, it raises an AssertionError ("prefill block ids (0) must equal to decode block ids (N)").
  • Attack vector: Network-based, requiring no authentication or user interaction — any client able to reach a LMDeploy Decode node’s HTTP API can trigger the condition.
  • Impact: The engine loop uses asyncio.wait(..., return_when=asyncio.FIRST_EXCEPTION) to supervise long-running tasks. The unhandled assertion cancels all pending tasks and terminates the entire engine loop rather than failing only the offending request, producing a persistent denial of service — the Decode node stops serving all subsequent inference requests (observed as EngineLoop wait_tasks failed, Engine main loop failed, and ENGINE_STOP_ERROR events) until the process/container is manually restarted.

Affected software

  • InternLM LMDeploy (PyPI package lmdeploy) versions up to and including 0.17.0, specifically deployments using the DistServe prefill/decode disaggregation feature with the OpenAI-compatible serving API exposed.

Severity

  • CVSS Score: 8.7 (High)
  • CVSS v4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
  • An alternate CVSS v3.1 scoring of 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) has also been published for this issue, reflecting the same network-based, unauthenticated availability-only impact.

Mitigation and recommended actions

  • Immediate: As of publication, no official patched LMDeploy release has been issued for this issue. A fix is under active development on the upstream InternLM/lmdeploy repository (tracked via a pull request addressing issue #4965) that rejects DistServe-internal fields (migration_request, with_cache, preserve_cache) on public endpoints unless the request is authenticated as internal proxy traffic, and that isolates migration failures to the individual request instead of terminating the whole engine loop. Security teams should monitor the LMDeploy GitHub repository and upgrade as soon as a release incorporating this fix becomes available.
  • If no patch is available:
    • Do not expose DistServe Decode node OpenAI-compatible endpoints (/v1/completions, /v1/chat/completions) directly to untrusted networks or the public internet; restrict access to the DistServe proxy and internal cluster networks only, using network segmentation, firewall rules, or an authenticating reverse proxy/API gateway in front of Decode nodes.
    • Enforce authentication/allow-listing so that only the trusted DistServe proxy component can reach Decode node endpoints, since these nodes are not designed to accept direct untrusted client traffic.
    • Monitor engine health endpoints and logs for repeated AssertionError, EngineLoop wait_tasks failed, or ENGINE_STOP_ERROR events, and implement automated restart/alerting for the Decode engine process to reduce downtime from potential exploitation.

References

Are you exposed?

Get a free report of your organization’s exposure to this CVE and threat

  • Mapping of all Assets with this Technology
  • Identification of potentially exposed assets to this CVE
  • Confirmation of verified exploitable assets
Get Exposure Report

How IONIX’s External Exposure Management Platform Detects and Validates
Zero-Days to Shrink MTTR

1

Map your entire attack surface (continously)

IONIX uses multi-factor discovery methods, including DNS analysis, certificate mapping, metadata inspection, and more, to automatically map every internet-facing asset across your environment. This includes cloud instances, third-party platforms, shadow IT, and even forgotten infrastructure that traditional tools miss.

2

Monitor for new CVEs

Dozens of threat intel feeds using agentic technology are continuously analyzed to detect the appearance of proof-of-concept code, exploit kits, and indicators of active targeting. IONIX goes further by applying AI to proactively evaluate whether emerging vulnerabilities are likely to be exploited, even before PoCs go public.

3

Identify Potential External Exposures

Not all CVEs matter. IONIX filters vulnerabilities by asking attacker-centric questions: Can it be reached from the internet? Does it require authentication? Is it being exploited in the wild? This dramatically reduces noise and focuses teams on threats that can actually be weaponized.

4

Create Safe, Scalable Exploit Validations

IONIX transforms real-world PoCs into safe, non-intrusive test payloads that can be run in production environments without disruption. These simulations are precisely targeted to the systems that are vulnerable, ensuring rapid validation without unnecessary load.

5

Execute Exploit Validations

By combining context about software stack, versioning, exposure status, and reachability, IONIX ensures that only the right payloads are executed against the right assets, maximizing efficiency and minimizing risk.

6

Drive Fast and Actionable Remediation

Results are routed through integrations with ticketing, SOAR, and SIEM tools. Issues are written in plain language, bundled into remediation clusters, and prioritized based on asset criticality, exploitability, and blast radius. This shortens mean time to remediation (MTTR) and empowers teams to act with confidence.

Are you exposed?

Get a free report of your organization’s exposure to this CVE and threat

  • Mapping of all Assets with this Technology
  • Identification of potentially exposed assets to this CVE
  • Confirmation of verified exploitable assets
Get Exposure Report
Close

Subscribe to Threat Center RSS

Copy/paste the link below into your preferred RSS reader or follow these instructions to subscribe to Slack alerts.

Open RSS feedSlack setup instructions

Close

Get Real-Time CVE Alerts to Your Email

Be the first to know when new zero-days emerge