Unsafe deserialization in lmsys sglang affects confidentiality, integrity, and availability

A security flaw has been discovered in lmsys sglang 0.4.6. Affected by this vulnerability is the function main of the file /update_weights_from_tensor. The manipulation of the argument serialized_named_tensors results in deserialization. The attack can be launched remotely. The exploit has been released to the public and may be exploited. The vendor was contacted early about this disclosure but did not respond in any way.

• lmsys sglang: version 0.4.6 is marked affected by the CNA record.
• Only 0.4.6 is directly confirmed in the affected data. The record provides no fixed version and does not establish that later or parallel release branches are unaffected.
• No default deployment status, additional deployment scope, or replacement package is confirmed in the affected data.

lmsys sglang processes network-supplied data in the main function of /update_weights_from_tensor. Manipulating the serialized_named_tensors argument causes the input to enter a deserialization path without sufficient validation that the resulting data is valid. At a high level, a remote attacker can submit specially crafted input to the affected processing path; the record states that exploitation does not require authentication and the supplied vector indicates no user interaction. The weakness is classified as CWE-502, with CWE-20 identifying improper input validation as a related weakness. The specific serialization format, payload structure, and deployment conditions required for the final impact have not been fully disclosed.

• The attack can be launched remotely over the network.
• The record and CNA analysis state that authentication is not required; the supplied vector also indicates no user interaction and low attack complexity.
• A public exploit or proof-of-concept has been reported, and VulDB states that technical details are publicly known.
• The available evidence does not name a campaign, victim, or specific compromise. Treat exploitation in the wild as unconfirmed by the CNA or vendor rather than inferring it from the existence of a public exploit.

• Remote input reaches the deserialization path in main within /update_weights_from_tensor.
• The flaw may cause partial confidentiality, integrity, and availability impact to the system hosting the SGLang process.
• The record states that the attack can be performed remotely without authentication, and the supplied vector indicates no user interaction.
• Impact beyond the affected process is not established; the record does not show that the flaw automatically grants host-level administration or propagates to other systems.
• Likely organizational consequences include exposure of data accessible to the service, altered inference results or weights, and service interruption. These are configuration-dependent possibilities, not a confirmed intrusion scenario.

The flaw may reduce:

• Confidentiality: data or information accessible to the process could be exposed if deserialization is exploited in that direction.
• Integrity: data, weights, or processing results could be altered.
• Availability: the process or service could be disrupted.

These are component-level impacts described by the CNA, not evidence that a specific organization has been compromised. Actual consequences depend on the process privileges, the data accessible to the deployment, and the network reachability of the affected function.

1. Identify and prioritize lmsys sglang installations running version 0.4.6, the only version directly confirmed as affected.
2. No specific patch or fixed release is provided by the CNA or vendor in the available evidence. Do not assume that a later version is safe without authoritative confirmation.
3. Until official guidance is available, restrict network access to the affected processing path and avoid exposing an unauthenticated endpoint where operationally feasible. This is a temporary risk-reduction measure, not a vendor-confirmed fix.
4. VulDB records that no specific countermeasure is known and mentions replacing the affected component with an alternative product. If isolation or exposure reduction is not feasible, assess replacement through the normal change-management process.
5. Monitor the CNA or vendor for updates covering a fixed release, additional affected branches, and deployment guidance.

1. Inventory servers, containers, and Python environments that install lmsys sglang, then verify the deployed version against the affected inventory.
2. Review deployment configuration to determine whether /update_weights_from_tensor is enabled, network reachable, or exposed without authentication.
3. Review network and application telemetry around this processing path, especially requests containing unusual or unexpected values for serialized_named_tensors. This is precautionary monitoring, not a vendor-confirmed IOC.
4. Correlate application errors, process restarts, changed outputs, or service interruptions with requests reaching the affected function.
5. The CNA provides no specific log signature, IOC, or detection rule. The absence of suspicious events does not establish that a system is safe.