GPU VulnDB

Database/AI/ML frameworks & serving

SGLang: unauthenticated pickle deserialization on /update_weights_from_tensor gives code execution

UnscoredCVE-2026-86793AI/ML frameworks & servingcurated

Impact

An SGLang server that runs without auth keys configured accepts pickled tensor payloads on /update_weights_from_tensor and unpickles them. The SafeUnpickler policy meant to contain this is bypassable because builtins.import and builtins.getattr remain resolvable, so a pickle REDUCE opcode reaches arbitrary callables. The result is code execution as the serving process, which on a GPU node means the account that owns the model weights, the CUDA context and whatever cluster credentials the pod carries. On a shared fleet that is a foothold on a node holding other tenants' work, and the process usually cannot be restarted without dropping in-flight inference.

Who can reach it

Anyone who can reach the SGLang HTTP endpoint, no authentication required when no auth keys are set. In most deployments that is the cluster network, and a serving port exposed beyond it makes this internet-reachable.

What to do

Set SGLang's auth key so the weight-update endpoints require a token, and keep the serving port off any network wider than the trusted control path; treat /update_weights_from_tensor as an administrative interface. Upgrade to a release carrying the unpickler fix once the project publishes one - the record does not name a fixed version, so do not assume the installed build is patched. Applying either change means restarting the serving process, so drain the replica first.

References

Related entries

All AI/ML frameworks & serving entries

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.