Skip to content
eastbaycyber

CVE-2026-7301: Critical Unauthenticated RCE in SGLang

CVSS · Critical
9.8
In CISA KEV
No
Published
Nov 11
Patch SLA & TriageVector: Network
24 to 48 hours

Critical CVSS (9.8) reachable over network.

Exposure:
Control:
CVSS v3.1 Blast RadiusScore: 9.8
Decode Vector & Sub-Scores →
CVE explainers 11 min read
Security Research Desk Source-checked
Auto-checked against the official CVE record · Human-reviewed after publishing · Updated 2026-11-11
▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief

TL;DR - CVE-2026-7301 is a CVSS 9.8 unauthenticated network RCE in SGLang’s multimodal scheduler. - SGLang v0.5.5 and later are affected when the scheduler socket is reachable by an attacker. - No official fixed version was confirmed; restrict the socket immediately and investigate exposed hosts.

CVE-2026-7301 is a critical SGLang vulnerability involving unsafe Python pickle deserialization in the multimodal generation scheduler. An attacker who can reach the scheduler’s ZeroMQ ROUTER socket may execute arbitrary code without authentication or user interaction.

Organizations operating AI infrastructure should treat any publicly reachable or broadly accessible SGLang scheduler as a priority exposure. For related background, see our non-human identity definition and recent AI and infrastructure vulnerability digest.

What Is the Root Cause?

The root cause is deserialization of attacker-controlled data with Python pickle. Pickle is intended for trusted Python object serialization, not for parsing untrusted network input. A malicious pickle object can invoke attacker-selected callables during deserialization, including through a crafted __reduce__ method.

The vulnerable communication path is the multimodal runtime scheduler’s ZeroMQ ROUTER socket. Incoming messages are processed without sufficient authentication, integrity protection, or a restricted deserialization mechanism. If an attacker can reach the socket, the attacker may submit a malicious serialized object and trigger code execution before normal application-level validation can contain the input.

A simplified representation of the unsafe operation is:

import pickle

# Unsafe when message originates from an untrusted client
request = pickle.loads(message)

This is not merely an input-validation weakness. A successful exploit can execute operating-system commands with the privileges of the SGLang process. If the runtime runs as root, has access to model repositories, cloud credentials, mounted secrets, GPU devices, or internal services, the resulting compromise can extend beyond the inference process.

The exposure condition is equally important. The vulnerability is not automatically reachable in every SGLang deployment. Risk depends on whether the multimodal runtime is enabled, how the scheduler is bound, and whether firewall, container, Kubernetes, or cloud security controls permit attacker access to the scheduler socket.

AnalystImpact · assess the risk

What Happened?

CVE-2026-7301 affects the multimodal generation runtime in SGLang, an open-source framework for serving large language and multimodal models. The scheduler’s ZeroMQ ROUTER socket accepts network messages that are passed to Python’s unsafe pickle.loads() deserializer. A crafted pickle payload can execute arbitrary code in the context of the SGLang process.

The vulnerability is most dangerous when the scheduler binds to a network-reachable address, particularly --host 0.0.0.0, and the corresponding socket is accessible from an attacker-controlled network. The issue does not require credentials, user interaction, or a complex attack chain.

Field Assessment
CVE ID CVE-2026-7301
CVSS 9.8 Critical
CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Attack vector Network
Authentication required None
User interaction None
Affected component SGLang multimodal generation runtime scheduler
Affected versions SGLang v0.5.5 and later, when the affected runtime and exposure conditions apply
Patch available No official fixed version confirmed in the available advisory
CISA KEV Not listed at the time of assessment

The available research does not establish a fixed SGLang release. Defenders should avoid assuming that upgrading to the latest release resolves the issue unless the project explicitly identifies CVE-2026-7301 as fixed in that version.

Analyst’s Take: Reachability is the immediate decision point. An exposed scheduler combines unauthenticated network access with unsafe pickle deserialization, while the available advisory does not confirm a fixed release. Restrict the socket first, then investigate the host and verify any later upgrade against a CVE-specific project statement.

Who Needs to Act?

The primary affected product is the SGLang multimodal generation runtime. The technical disclosure identifies SGLang v0.5.5 and later as affected when the multimodal runtime is enabled and its scheduler socket is reachable by an attacker.

Organizations should prioritize systems with any of the following characteristics:

  • SGLang v0.5.5 or later is installed.
  • The multimodal generation runtime is enabled.
  • The scheduler is configured with --host 0.0.0.0.
  • The scheduler socket is published through Docker host networking, Kubernetes hostNetwork, a NodePort, a load balancer, or a public cloud security group.
  • The scheduler port is reachable from user networks, partner networks, CI/CD systems, or the public internet.
  • The process has access to model files, API keys, cloud credentials, customer data, internal APIs, or privileged host resources.

The available primary advisory does not provide a confirmed fixed version. It states that no official patch was available at publication. Consequently, this article cannot identify a definitive upgrade target without inventing a vendor claim. Treat any deployment in the affected version range as potentially vulnerable until the SGLang project publishes a release or advisory explicitly confirming the fix.

The related GitHub issue concerning unauthenticated pickle.loads on a TCP-bound ZeroMQ socket is relevant to the broader technical context, but it should not be treated as proof that a particular release fixes CVE-2026-7301. Confirm the fix against the project’s release notes, commit history, or a CVE-specific advisory before closing remediation tickets.

Why Is the CVSS Score 9.8?

The reported CVSS 3.1 vector is:

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

The components explain the maximum 9.8 score:

Metric Value Meaning
Attack Vector Network The attacker sends data over a network connection to the scheduler socket
Attack Complexity Low No unusual conditions or sophisticated prerequisites are described beyond reachability
Privileges Required None Authentication or an existing account is not required
User Interaction None No victim needs to open a file, approve a request, or perform another action
Scope Unchanged The direct impact remains within the vulnerable SGLang security authority
Confidentiality High Code execution may expose models, credentials, prompts, and data
Integrity High An attacker may modify services, files, models, or runtime behavior
Availability High An attacker may stop services, consume resources, or disrupt inference

The score assumes that the vulnerable scheduler is reachable. It does not mean every SGLang installation is internet-exploitable. A deployment that binds only to a protected interface and enforces strict network policy has a materially smaller attack surface, although the unsafe deserialization flaw still warrants remediation.

The practical impact can include host compromise, theft of API keys and cloud credentials, manipulation of served models, disruption of inference, abuse of GPU resources, cryptocurrency mining, and lateral movement into adjacent infrastructure. The final impact also depends on the operating-system account, container isolation, mounted volumes, service-account permissions, and egress controls.

Has CVE-2026-7301 Been Exploited?

No confirmed exploitation in the wild was identified in the supplied research. CVE-2026-7301 was not listed in the CISA Known Exploited Vulnerabilities catalog at the time of assessment. There is therefore no CISA date-added date, federal remediation deadline, required action, or ransomware-campaign designation associated with this CVE.

A missing KEV entry is not evidence that exploitation cannot occur or that no attacks have taken place. It only indicates that CISA had not included the CVE in its catalog at the time of lookup. Organizations with exposed SGLang schedulers should not downgrade the issue solely because it is not in KEV.

Public technical details are available through the Antiproof disclosure. The disclosure describes the unsafe pickle deserialization path, identifies the vulnerable source location and configuration conditions, and demonstrates the general malicious __reduce__ mechanism. This is publicly available exploit-enabling information, but the supplied material does not establish that a complete weaponized exploit for CVE-2026-7301 is publicly available.

The current assessment is therefore:

Question Status
Confirmed exploitation in the wild Not identified in the available sources
CISA KEV listed No
Public technical details Yes
Complete weaponized CVE-specific PoC confirmed No
Official fixed version confirmed No

Defenders should treat public exploit mechanics plus unauthenticated network reachability as sufficient reason to remove exposure immediately, regardless of current KEV status.

ResponderRunbook · act now

Detection Guidance

Start by identifying every SGLang deployment and determining whether the multimodal runtime is enabled. Inventory package versions, container images, process arguments, listening sockets, service exposure, and network paths. Pay particular attention to Kubernetes manifests, Helm values, Docker Compose files, cloud security groups, and host-network settings.

Useful host-level checks include:

# Identify SGLang processes and launch arguments
ps auxww | grep -i '[s]glang'

# Inspect listening TCP and UDP sockets
ss -lntup

# Search common deployment locations for risky host configuration
grep -RInE -- '--host[= ]+0\.0\.0\.0|hostNetwork:|hostPort:|NodePort|loadBalancer' \
  /etc /opt /srv /var/lib 2>/dev/null

The exact scheduler port is not specified in the supplied advisory, so defenders should not rely on one hard-coded port. Map the process arguments to the actual ZeroMQ endpoint and compare it with firewall and security-group rules. Review whether the endpoint is bound to 0.0.0.0, a public interface, a node address, or an internal-only address.

At the network layer, look for unexpected connections to the scheduler endpoint, especially from public IP addresses or networks that should not operate SGLang workers. A useful Zeek-style query, after replacing the placeholder port with the deployment’s actual scheduler port, is:

# Conceptual Zeek query: identify non-approved clients reaching the scheduler
conn.log
| where id.resp_p == <SGLANG_SCHEDULER_PORT>
| where id.orig_h !in <approved_scheduler_clients>
| summarize count(), min(ts), max(ts) by id.orig_h, id.resp_h, id.resp_p

For systems using Linux auditd, monitor the SGLang process for child-process creation and suspicious execution. The following rule is a starting point and must be adapted to the actual executable path and service account:

-w /path/to/sglang -p x -k sglang-exec

Then search for unexpected descendants or command execution near network activity:

ausearch -k sglang-exec -ts recent
journalctl --since "24 hours ago" | grep -Ei \
  'sglang|python|sh -c|bash -c|curl|wget|nc |socat|metadata'

Potential post-exploitation indicators include shells spawned by the SGLang or Python process, unexpected outbound connections, access to cloud metadata endpoints, modified model files, new persistence mechanisms, newly created users, altered SSH keys, and unusual GPU utilization. Because a successful exploit may execute arbitrary commands without a distinctive application error, absence of a known exploit string in logs does not prove that the host is clean.

If the scheduler was publicly reachable, preserve logs and investigate before simply rebuilding. Capture process trees, open connections, container metadata, filesystem changes, cloud audit logs, and identity-provider activity. Rotate credentials that were accessible to the process or mounted into the container.

Remediation and Patching

The immediate mitigation is to remove untrusted network access to the scheduler socket. Restrict the endpoint to the specific SGLang components that require it, using host firewalls, cloud security groups, Kubernetes NetworkPolicy, service mesh policy, or an equivalent control. Do not publish the scheduler through a public load balancer, and do not expose internal ZeroMQ ports through host networking unless the access path is tightly controlled.

Where operationally possible, bind the runtime to a protected interface rather than all interfaces:

# Example pattern: replace the address with a trusted, non-public interface
python -m sglang.launch_server \
  --host 127.0.0.1 \
  [other-required-options]

The exact launch command and scheduler options vary by SGLang deployment. If the scheduler must be reachable by separate workers, bind it to a private interface and allow only the workers’ addresses. A firewall rule should be explicit about both source and destination rather than relying on the service’s bind address alone:

# Example only: replace the interface, port, and approved subnet
sudo iptables -A INPUT -p tcp --dport <SGLANG_SCHEDULER_PORT> \
  ! -s <TRUSTED_WORKER_SUBNET> -j DROP

In Kubernetes, remove unnecessary public service exposure and restrict access with a network policy. The following is a pattern, not a drop-in manifest:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-sglang-scheduler
spec:
  podSelector:
    matchLabels:
      app: sglang
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: trusted-worker
      ports:
        - protocol: TCP
          port: <SCHEDULER_PORT>

The available advisory identifies SGLang v0.5.5 and later as affected and states that no official patch was available at publication. No definitive fixed version was confirmed in the supplied sources. Do not claim that a particular version resolves CVE-2026-7301 until the SGLang project or a trusted security advisory documents that fix.

Once an official fixed release is confirmed, upgrade using the deployment’s controlled package or image process. For a Python virtual environment, the command will generally follow this pattern:

python -m pip install --upgrade sglang==<CONFIRMED_FIXED_VERSION>
python -m pip show sglang

For a containerized deployment, update the image tag to the confirmed fixed release, redeploy, and verify the running image rather than only the manifest:

docker pull <official-sglang-image>:<CONFIRMED_FIXED_VERSION>
docker compose up -d --force-recreate
docker inspect <container> --format '{{.Config.Image}}'

These commands intentionally use a placeholder because the supplied research does not establish a fixed version. Do not substitute the latest available release without verifying that it contains the CVE-specific remediation.

After containment or upgrade, rotate secrets available to the SGLang process, review mounted volumes, rebuild potentially compromised hosts or containers, and validate that the scheduler is no longer reachable from untrusted networks. Apply least privilege to the service account, disable unnecessary egress, avoid running the runtime as root, and separate model-serving workloads from sensitive control-plane systems.

References

  1. NVD CVE record:
    https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-7301

  2. CVE record:
    https://www.cve.org/CVERecord?id=CVE-2026-7301

  3. Antiproof, “Three Remote Code Execution vulnerabilities in SGLang”:
    https://antiproof.ai/blog/three-rces-in-sglang/

  4. SGLang source tree:
    https://github.com/sgl-project/sglang/tree/main/python/sglang

  5. Related SGLang GitHub issue concerning unauthenticated pickle.loads on a TCP-bound ZeroMQ socket:
    https://github.com/sgl-project/sglang/issues/24618

  6. CISA Known Exploited Vulnerabilities catalog:
    https://www.cisa.gov/known-exploited-vulnerabilities-catalog

The available evidence supports treating CVE-2026-7301 as a critical exposure for reachable SGLang multimodal schedulers. The first action is to remove untrusted access to the scheduler and investigate any internet-exposed instance; then monitor the project for an official version that explicitly resolves the vulnerability.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Choosing a tool? Pricing and head-to-head guides

Last verified: 2026-11-11

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.