CVE-2026-3989: 
Python vulnerability analysis and mitigation

CVE-2026-3989 is an insecure deserialization vulnerability in SGLang's replay_request_dump.py crash dump replay utility. The script uses Python's pickle.load() without validation on user-supplied .pkl files, allowing an attacker who can supply a malicious pickle file to achieve arbitrary code execution on the machine running the script. It affects all SGLang versions containing replay_request_dump.py, including versions 0.5.5 through 0.5.9 (the latest at time of disclosure). The vulnerability was discovered on February 4, 2026 by Igor Stepansky (Orca Security) and CVE-2026-3989 was assigned on March 11, 2026 by CERT/CC (case VU#665416). It carries a CVSS v3.1 base score of 7.8 (High) (Orca Security, CERT/CC).

The root cause is CWE-502 (Deserialization of Untrusted Data): the read_records() function in replay_request_dump.py calls pickle.load() directly on any .pkl file provided via --input-file or --input-folder, with no validation, allowlisting, or integrity checking. Python's pickle protocol encodes arbitrary object reconstruction instructions, including calls to any Python callable such as os.system or subprocess.Popen, via the __reduce__ method. An attacker crafts a malicious .pkl file whose deserialization triggers an arbitrary shell command; the attack vector is local (AV:L) and requires user interaction (UI:R) — specifically, an operator must manually run the script against the malicious file. The attack scenario involves either write access to the crash dump directory (e.g., /data/sglang_crash_dump/) or social engineering to convince an operator to replay a supplied file. A PoC developed by CERT/CC researcher Christopher Cullen uses eval() as the callable and returns a valid {'requests': []} structure post-execution, making the compromise invisible to the operator (Orca Security, GitHub PR #20904).

Successful exploitation results in full arbitrary code execution with the privileges of the user running the replay_request_dump.py script, impacting confidentiality, integrity, and availability at the HIGH level. In typical SGLang deployments — containerized GPU inference nodes running inside Kubernetes pods or Docker containers — this could expose model weights, inference data, API credentials, and GPU workloads. The compromise could also serve as a pivot point into the surrounding cluster environment, enabling lateral movement to other services or infrastructure (Orca Security).

A functional proof-of-concept for CVE-2026-3989 was developed by CERT/CC researcher Christopher Cullen and shared during coordinated disclosure. No in-the-wild exploitation has been observed as of the time of publication. The EPSS score is approximately 0.024% (0.000240), reflecting low observed exploitation probability. The vulnerability is not listed in the CISA KEV catalog. Weaponization requires minimal effort given the trivial nature of pickle deserialization exploits, but the local attack vector and required user interaction significantly constrain the exploitable population compared to the companion CVEs (CVE-2026-3059 and CVE-2026-3060) (Orca Security, CERT/CC).

1. Identify the target: Determine that the target environment uses SGLang with --crash-dump-folder configured, producing .pkl crash dump files in a known directory (e.g., /data/sglang_crash_dump/).
2. Craft a malicious pickle payload: Create a Python script that generates a malicious .pkl file using the __reduce__ method to execute an arbitrary command while returning a valid {'requests': []} structure to avoid detection:

import pickle
class POC:
    def __reduce__(self):
        payload = ("(__import__('pathlib').Path('poc_marker.txt').write_text('pickle payload executed\\n', encoding='utf-8'), {'requests': []})[1]")
        return (eval, (payload,))
with open('malicious.pkl', 'wb') as f:
    pickle.dump(POC(), f)

3. Plant the malicious file: Place malicious.pkl in the crash dump directory via write access to the directory, or deliver it to the operator via social engineering (e.g., "can you replay this crash dump?").
4. Wait for operator execution: The operator runs the replay script against the malicious file:

python3 replay_request_dump.py --input-file /data/sglang_crash_dump/malicious.pkl

5. Achieve code execution: pickle.load() processes the file and executes the attacker's payload immediately upon deserialization, before any application-level logic runs. The script continues normally, concealing the compromise (Orca Security, CERT/CC).

• File System: Unexpected files created in the working directory of the replay_request_dump.py script (e.g., poc_marker.txt, reverse shell scripts, or dropped binaries); new or modified .pkl files in crash dump directories with unusual timestamps or ownership; unexpected cron jobs or scheduled tasks created by the user running the script.
• Process: Unusual child processes spawned by the Python interpreter running replay_request_dump.py (e.g., /bin/sh, curl, wget, nc, python3 -c); unexpected outbound network connections from the process.
• Logs: Shell history or audit logs showing execution of replay_request_dump.py with externally supplied or recently modified .pkl files; auditd records of execve calls from the Python process to unexpected binaries.
• Network: Outbound connections to unknown external IPs originating from the SGLang host shortly after script execution (Orca Security).

A fix was merged into the SGLang main branch on March 27, 2026 via PR #20904, replacing the unsafe pickle.load() call in replay_request_dump.py with a SafeUnpickler that enforces an allowlist/denylist to block known RCE gadget chains (e.g., os.system, subprocess.Popen, eval, exec). This fix is included in the v0.5.10 release. Users should upgrade to SGLang v0.5.10 or later immediately. As a workaround prior to upgrading, operators should never run replay_request_dump.py against .pkl files from untrusted sources or shared directories with weak permissions, and should restrict write access to crash dump directories to trusted principals only. Note that SafeUnpickler may be bypassable via advanced gadget chains; the SGLang team is pursuing a longer-term migration to msgpack or HMAC-signed serialization for all pickle usage across the codebase (GitHub PR #20904, SGLang v0.5.10).

The vulnerability was disclosed publicly by Orca Security researcher Igor Stepansky on March 11, 2026, alongside two higher-severity companion CVEs (CVE-2026-3059 and CVE-2026-3060, both CVSS 9.8). The disclosure noted that SGLang maintainers did not respond to coordinated disclosure efforts through GitHub Security Advisories or direct CERT/CC outreach — including CISA assistance — prior to publication. Coverage appeared in The Hacker News, SecurityOnline, SAPInsider, and CyberSecBrief, framing the findings as part of a broader systemic problem with unsafe pickle deserialization in AI/ML infrastructure. CERT/CC researcher Christopher Cullen publicly thanked the SGLang community for their post-disclosure remediation efforts and encouraged the project to join CERT/CC's coordination platform for future vulnerability handling (Orca Security, The Hacker News, GitHub PR #20904).