Database/AI/ML frameworks & serving
SGLang (`/update_weights_from_tensor`): Unsafe deserialization of the `serialized_named_tensors` argument
Impact
Unsafe deserialization of the serialized_named_tensors argument
Who can reach it
Network to the SGLang HTTP API
What to do
Upgrade past 0.4.6; the weight-update endpoint must not be tenant-reachable
Fleet impact
How widespread
Very common - SGLang is the main vLLM alternative for high-throughput LLM serving on neoclouds; affects 0.4.6 through <0.5.4
Cost to remediate
daemon-restart - upgrade to 0.5.4+ and roll every serving replica
Why it hits the whole fleet
update_weights_from_tensor pickle-deserializes attacker input with no authentication, giving unauthenticated remote code execution on every SGLang serving process reachable on the network
References
Related entries
- Jupyter Core (Windows): Config read from a shared writable pathCVE-2025-30167 · Jupyter Core (Windows)High
- llama-index-core: Predictable hardcoded cache directoryCVE-2025-7647 · llama-index-coreHigh
- Keras (HDF5 path): Code execution from crafted `.h5`/`.hdf5` model despite safe modeCVE-2025-9905 · Keras (HDF5 path)High
- Keras: Code execution from crafted `.keras` archive despite safe modeCVE-2025-9906 · KerasHigh
- MLflow (artifact handler): Directory traversalCVE-2026-2033 · MLflow (artifact handler)High
- Jupyter Server (Origin validation): `re.match` used for Origin validationCVE-2026-40110 · Jupyter Server (Origin validation)High
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.