Xoscar: unauthenticated code execution in the Xinference actor pool
Xoscar's actor pool deserializes every inbound TCP message with cloudpickle before it checks the message type, and before any authentication.
· VulnCheck · Research by Valentin Lobstein
Xoscar, the actor framework behind the Xinference model server, runs attacker code from any unauthenticated TCP message sent to its actor pool. VulnCheck published CVE-2026-49950 on October 13 with no fixed version available.
01What happened
VulnCheck published CVE-2026-49950 on October 13, 2026, after a 120-day coordinated disclosure deadline passed without a vendor fix. Valentin Lobstein found the flaw in Xorbits Xoscar, the Python actor and RPC framework that the Xinference model server uses to connect supervisors, workers and model pools. VulnCheck is the assigning CNA and rates the flaw 9.3 on CVSS 4.0.
02How it works
The actor pool's socket receive path hands raw bytes to cloudpickle.loads() before it checks what kind of message arrived. A Python pickle payload carrying a __reduce__ gadget therefore runs during deserialization. The channel has no authentication, no restricted unpickler and no class allowlist, so the one byte of protocol version read first is framing, not a security control.
03Who is affected
Every released version of Xoscar from 0.1.0 through 0.11.2 is affected, including the current release. VulnCheck reports that Xinference binds the actor pool to 0.0.0.0 in distributed mode, which puts the port within reach of an internal network, and that the pool process often runs as root on GPU nodes.
04What to do
Block network access to Xoscar actor pool ports at the host and network level, and keep Xinference workers on an isolated segment rather than one reachable from general internal traffic. Reduce the pool process away from root where the deployment allows it, and watch the Xoscar repository for a release above 0.11.2.
Questions people ask
- Am I affected if I run Xinference?
- Xinference users are exposed when the deployment runs in distributed mode, because VulnCheck reports the Xoscar actor pool binds to 0.0.0.0 by default and accepts unauthenticated messages. Anyone able to reach that TCP port on the internal network can run code in the pool process. Single-process local setups that never open the actor pool port to other hosts are not reachable the same way.
- Is there a patch for CVE-2026-49950 in Xoscar?
- No fixed version of Xoscar exists. The flaw affects every release from 0.1.0 through 0.11.2, and 0.11.2 is the current release, published on October 7, 2026. VulnCheck says its 120-day coordinated disclosure deadline passed without a vendor fix, so defenders have to rely on network controls and privilege reduction rather than an upgrade.
- How do I check whether my Xoscar actor pool is exposed?
- Defenders should look for Xoscar actor pool ports listening on all interfaces rather than loopback on each Xinference supervisor and worker host, then confirm from another host whether those ports accept connections. VulnCheck notes the pool often runs as root on GPU nodes, so any reachable port deserves treatment as a path to full host compromise.
- Does authentication on Xinference protect the actor pool?
- Authentication on the Xinference API does not protect the Xoscar actor pool. VulnCheck describes the actor pool channel as having no authentication of its own, no restricted unpickler and no class allowlist, so any peer that can open the TCP port is trusted. The only check before deserialization is a one-byte protocol version, which VulnCheck calls a framing check rather than a security control.
Sources 3 links, all fetched
- 1vulncheck.comVulnCheck Advisory
- 2vulncheck.comVulnCheck Write-Up
- 3github.comGitHub Advisory