What is the CVSS score of CVE-2026-7304?

CVE-2026-7304 has a CVSS 3.1 base score of 9.8 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.3%.

How to fix or mitigate CVE-2026-7304?

Within 24 hours, audit all SGLang 5.10 deployments to identify instances with --enable-custom-logit-processor flag enabled and immediately disable the flag if it is set. Within 7 days, implement network segmentation to isolate SGLang inference infrastructure from production systems, apply firewall rules restricting access to trusted internal networks only, and enable detailed logging of inference operations. Within 30 days, monitor for vendor security patches for SGLang, plan upgrade procedures for all affected deployments, and conduct a post-incident security assessment of any inference infrastructure that previously had the custom logit processor flag enabled.

SGLang CVE-2026-7304

EUVD-2026-30766 CRITICAL

Deserialization of Untrusted Data (CWE-502)

2026-05-18 certcc

GHSA-36m8-w8qf-g76p

RCE Python Deserialization Sglang

9.8

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

9.8 CRITICAL

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

vuln.today AI

9.8 CRITICAL

Once the opt-in feature is enabled, exploitation is unauthenticated network RCE with no interaction; the non-default config is a real-world limiter but does not alter base metrics, yielding full C/I/A impact.

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

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from NVD.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 23, 2026 - 18:01 vuln.today

CVE Published

May 18, 2026 - 10:39 nvd

UNKNOWN (no severity yet)

CVE Published

May 18, 2026 - 10:39 cve.org

CRITICAL 9.8

DescriptionCVE.org

SGLangs multimodal generation runtime is vulnerable to unauthenticated remote code execution when the --enable-custom-logit-processor option is enabled, as Python objects loaded via dill.loads() will be deserialized without validation.

AnalysisAI

Unauthenticated remote code execution in SGLang (the LLM/multimodal generation serving runtime) affecting version 5.10 arises when the non-default --enable-custom-logit-processor flag is set, allowing attacker-supplied Python objects to be deserialized via dill.loads() and execute arbitrary code on the inference host. No CISA KEV listing exists and SSVC records exploitation as 'none', but a public technical write-up (antiproof.ai, 'Three RCEs in SGLang') details the flaw and SSVC marks it automatable with total technical impact. EPSS is modest at 0.32% (55th percentile), consistent with a serious-but-conditional (feature-gated) issue rather than mass exploitation.

Technical ContextAI

SGLang is a high-performance serving/runtime engine for large language and multimodal models, exposing an HTTP API for generation requests. The 'custom logit processor' feature lets clients supply logic that shapes token sampling; to transport arbitrary Python callables it relies on dill, an extended pickle library. The root cause is CWE-502 (Deserialization of Untrusted Data): dill.loads() reconstructs arbitrary Python objects, and pickle/dill deserialization invokes object constructors and __reduce__ methods, giving an attacker code execution the moment a malicious blob is loaded without type/signature validation. The affected component is identified by CPE cpe:2.3:a:sglang:sglang:*:*:*:*:*:*:*:*, with EUVD naming sglang 5.10.

RemediationAI

No vendor-released patch version is identified in the available data, so the primary compensating control is to disable the vulnerable feature: run SGLang without --enable-custom-logit-processor (it is opt-in and off by default), which removes the untrusted dill.loads() path at the cost of losing client-supplied logit-processor functionality. Additionally restrict network exposure of the SGLang API by binding to localhost or placing it behind an authenticated reverse proxy/allowlist so untrusted clients cannot reach the generation endpoint, and monitor the project for a patched release before re-enabling the feature. Consult the upstream project (https://github.com/sgl-project/sglang) and the technical analysis at https://antiproof.ai/blog/three-rces-in-sglang/ for fix status; upgrade to a fixed version once the vendor publishes one, since disabling the feature is a mitigation rather than a code-level fix.