SGLang Unauthenticated RCE Exploited at NEAR AI: Detection and Hardening Guide for AI Inference Infrastructure

This week brought a stark reminder that AI inference infrastructure is now a first-class attack surface. NEAR AI disclosed that an attacker exploited an unauthenticated remote code execution (RCE) vulnerability in SGLang, a widely deployed open-source LLM inference engine, to execute arbitrary code on one of the company's production inference servers. The fallout: data exposure affecting 18 AI agents and approximately 100 users — including requests processed in NEAR AI's confidential mode, which runs workloads inside a Trusted Execution Environment (TEE).

That last point deserves emphasis. Confidential mode with TEE isolation is specifically designed to protect sensitive prompts and data even from the infrastructure operator. Yet an attacker with code execution on the host inference server could observe requests being processed that day. TEEs protect data in use from the host OS and hypervisor — but they are not a magic shield against a compromised inference pipeline, side-channel visibility, or an attacker positioned at the right layer of the stack. If your organization runs SGLang, vLLM, or any open-source inference server exposed to network traffic, this incident is your wake-up call.

As of this writing, no CVE identifier has been formally assigned to the SGLang flaw in the public reporting. Defenders should track the SGLang GitHub repository and security advisories for a patched release and monitor The Hacker News' original reporting for updated technical details.

Technical Analysis

What is SGLang and Why It Matters

SGLang is a high-performance, open-source serving framework for large language models. It is used by AI providers, research labs, and enterprises to serve models at scale — typically exposing an HTTP API (commonly on ports like 30000) that accepts generation requests, manages KV cache, schedules GPU workloads, and streams responses. Because inference servers must accept arbitrary input from network clients and translate it into engine operations, they sit in a uniquely dangerous position: internet- or tenant-facing, running with access to expensive GPU hardware, sensitive prompt data, and frequently with broad internal network reach.

The Attack Chain (Defender's Perspective)

Based on NEAR AI's disclosure, the attack chain looked like this:

1. Unauthenticated network access — The attacker reached the SGLang server endpoint without any credentials. This is the critical failure mode: the vulnerability required no authentication, meaning any client that could route to the inference API could attempt exploitation.
2. Arbitrary code execution in the SGLang process context — The flaw allowed the attacker to run code on the host. Inference engines like SGLang typically run as a Python process (often via sglang.launch_server or python -m sglang), frequently in containers but sometimes with privileged GPU access and host mounts.
3. Visibility into in-flight inference requests — With code execution on the server, the attacker could observe requests being processed that day — including requests marked as confidential mode. Data belonging to 18 agents and ~100 users was exposed.
4. TEE boundary implications — Confidential computing protects workload memory from the host via hardware isolation (e.g., Intel TDX, AMD SEV-SNP, NVIDIA Confidential Computing GPUs). However, if the inference orchestration layer outside the enclave is compromised — or if an attacker can observe request routing, metadata, or pre-/post-enclave processing — the confidentiality guarantee erodes. The NEAR AI incident demonstrates that TEE deployment does not compensate for an unpatched, network-exposed application-layer RCE.

Affected Products and Platforms

• SGLang open-source inference engine — all deployments running the vulnerable version prior to the vendor fix. Organizations should inventory any host or container running sglang, sglang-router, or images such as lmsysorg/sglang.
• Linux hosts and GPU clusters — SGLang deployments are predominantly Linux-based (bare metal, Docker, Kubernetes GPU node pools).
• AI-as-a-Service providers and internal LLM platforms — any multi-tenant inference endpoint is at elevated risk because unauthenticated RCE in a shared serving layer collapses tenant isolation.

Exploitation Status

• Confirmed active exploitation in the wild. This is not theoretical — NEAR AI has confirmed a production breach via this flaw.
• No public CVE assigned yet (as of disclosure). Track the SGLang project's security releases.
• No CISA KEV listing at time of writing, but given confirmed exploitation, organizations should treat this with KEV-equivalent urgency.
• The exploit requires only network reachability to the SGLang API port — no credentials, no user interaction. This is the highest-urgency exploitation class.

Detection & Response

The most reliable behavioral signal of post-exploitation on an inference server is the SGLang/Python server process spawning unexpected child processes (shells, downloaders, reconnaissance tools) and anomalous network activity originating from the inference host. Inference servers are predictable workloads — any shell execution under the serving process is a strong anomaly.

Sigma Rules

---
title: SGLang Inference Server Spawning Shell or Command Interpreter
id: 3f8a1c42-7b6e-4d29-a915-2e4c6f8b0d31
status: experimental
description: Detects the SGLang inference server process (or its Python parent) spawning a shell or command interpreter, consistent with post-exploitation activity following remote code execution against the inference API.
references:
  - https://thehackernews.com/2026/11/sglang-rce-exploit-breaches-near-ai.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/11/20
tags:
  - attack.execution
  - attack.t1059
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'sglang'
      - 'sgl::'
      - 'sglang.launch_server'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate model loading scripts or health checks invoked by SGLang operators
  - Container entrypoint wrappers that launch helper utilities
level: high
---
title: Suspicious Command Execution on AI Inference Hosts
id: 8c2d5e91-4a7f-4b38-9c64-1f3a7d5e9b20
status: experimental
description: Detects execution of reconnaissance, download, or reverse-shell utilities from non-interactive service accounts or Python parent processes on GPU/inference hosts, a common pattern after unauthenticated RCE against inference engines such as SGLang.
references:
  - https://thehackernews.com/2026/11/sglang-rce-exploit-breaches-near-ai.html
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
date: 2026/11/20
tags:
  - attack.execution
  - attack.t1059.004
  - attack.command_and_control
  - attack.t1105
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/python'
      - '/python3'
      - '/python3.10'
      - '/python3.11'
      - '/python3.12'
  selection_cmd:
    CommandLine|contains:
      - 'curl '
      - 'wget '
      - 'base64 -d'
      - '/dev/tcp/'
      - 'nc -e'
      - 'ncat -e'
      - 'chmod +x'
      - 'id &&'
      - 'whoami &&'
  condition: selection_parent and selection_cmd
falsepositives:
  - Model download pipelines (huggingface-cli, automated weight fetching) - filter on known model registry domains
  - Package installation during container builds
level: high
---
title: Inbound Connection to SGLang Default Serving Port From Untrusted Source
id: 5b1e9f37-2d8c-4a46-b7e3-9f0c4a8d2e61
status: experimental
description: Detects inbound network connections to the default SGLang serving port (30000) where such traffic is unexpected, indicating potential external probing or exploitation attempts against exposed inference APIs.
references:
  - https://thehackernews.com/2026/11/sglang-rce-exploit-breaches-near-ai.html
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/11/20
tags:
  - attack.initial_access
  - attack.t1190
  - attack.discovery
  - attack.t1046
logsource:
  category: firewall
  product: linux
detection:
  selection:
    DestinationPort:
      - 30000
      - 30001
    Action: 'allowed'
  filter_authorized:
    SourceIP|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: selection and not filter_authorized
falsepositives:
  - Load balancer health checks from untagged IP ranges - tune the authorized CIDR list to your environment
  - Legitimate public inference APIs intentionally exposed to the internet
level: medium

KQL Hunt — Microsoft Sentinel / Defender

Even though SGLang runs on Linux, most enterprises ingest Linux auditd/Syslog and firewall telemetry into Sentinel, and Defender for Endpoint on Linux populates DeviceProcessEvents. This query hunts for inference-server processes spawning shells or download tools:

let InferenceParents = dynamic(["sglang", "python", "python3", "vllm", "sglang-router"]);
let SuspiciousChildren = dynamic(["sh", "bash", "dash", "zsh", "curl", "wget", "nc", "ncat", "perl", "socat"]);
union isfuzzy=true
(DeviceProcessEvents
    | where TimeGenerated > ago(7d)
    | where InitiatingProcessFileName has_any (InferenceParents)
        or InitiatingProcessCommandLine has_any ("sglang", "launch_server")
    | where FileName has_any (SuspiciousChildren)
    | project TimeGenerated, DeviceName, FileName, ProcessCommandLine,
              InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName),
(Syslog
    | where TimeGenerated > ago(7d)
    | where Facility == "auth" or SyslogMessage has_any ("sglang", "30000")
    | where SyslogMessage has_any ("bash", "curl", "wget", "/dev/tcp", "nc -e")
    | project TimeGenerated, HostName, ProcessName, SyslogMessage)
| order by TimeGenerated desc

Velociraptor VQL Hunt

Use this artifact across your GPU/inference fleet to identify SGLang processes with anomalous child processes or unexpected outbound connections:

-- Hunt for SGLang inference processes with suspicious children or network connections
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'sglang|launch_server'
   OR (Name =~ '^(sh|bash|dash|curl|wget|nc|ncat|perl)$'
       AND Ppid IN (
         SELECT Pid FROM pslist() WHERE CommandLine =~ 'sglang|launch_server'
       ))

-- Enumerate listeners on default SGLang ports and flag unexpected exposure
SELECT Pid, Name, LocalAddress, LocalPort, RemoteAddress, RemotePort, Status
FROM netstat()
WHERE LocalPort in (30000, 30001) OR Name =~ 'sglang'

Remediation / Verification Script (Bash)

Run this on Linux inference hosts (or as a Kubernetes DaemonSet job / Ansible playbook) to inventory SGLang deployments, check version exposure, and verify network controls:

#!/bin/bash
# SGLang RCE Exposure Verification & Hardening Script
# Security Arsenal - IR readiness check
echo "=== [1] Running SGLang processes ==="
ps aux | grep -iE 'sglang|launch_server' | grep -v grep || echo "No SGLang processes found"

echo "=== [2] Installed SGLang version ==="
python3 -c 'import sglang; print("sglang", sglang.__version__)' 2>/dev/null || pip show sglang 2>/dev/null || echo "sglang not installed in system python"

echo "=== [3] Container images containing SGLang ==="
(docker images 2>/dev/null | grep -i sglang) || (crictl images 2>/dev/null | grep -i sglang) || echo "No container runtime or no sglang images"

echo "=== [4] Listeners on default inference ports ==="
ss -tlnp 2>/dev/null | grep -E ':30000|:30001' || echo "No listeners on 30000/30001"

echo "=== [5] Suspicious child processes of Python/SGLang parents ==="
for pid in $(pgrep -f 'sglang|launch_server'); do
  echo "--- Children of PID $pid ---"
  ps --ppid "$pid" -o pid,comm,args 2>/dev/null
done

echo "=== [6] Recent outbound connections from inference processes ==="
for pid in $(pgrep -f 'sglang|launch_server'); do
  ls -l /proc/$pid/fd 2>/dev/null | grep -c socket | xargs -I{} echo "PID $pid has {} socket FDs"
done

echo "=== [7] Firewall check: is 30000 exposed publicly? ==="
(iptables -L INPUT -n 2>/dev/null | grep 30000) || (nft list ruleset 2>/dev/null | grep 30000) || echo "Review cloud security groups manually"

echo ""
echo "ACTION REQUIRED:"
echo "1. Upgrade SGLang to the latest patched release: pip install --upgrade sglang"
echo "2. Restrict port 30000 to authorized internal callers only (security groups / iptables)."
echo "3. Place inference APIs behind an authenticated gateway (mTLS or token auth proxy)."
echo "4. If any suspicious child processes or unknown sockets were found above, isolate the host and initiate IR."

Remediation

1. Patch immediately. Upgrade SGLang to the latest release containing the fix. Monitor the SGLang GitHub security advisories and the project's release notes. Treat this with CISA KEV-equivalent urgency given confirmed in-the-wild exploitation — do not wait for a KEV listing to act. A CVE assignment is expected; subscribe to the repo's security notifications so you catch it.

2. Remove unauthenticated network exposure. The defining characteristic of this flaw is that it requires no credentials. If your SGLang endpoint is reachable by anything other than authorized application callers, you are exposed. Place inference endpoints behind an authenticated reverse proxy (nginx/Envoy with mTLS or bearer-token enforcement) and restrict source IPs via security groups, network policies, or host firewall rules. Default port 30000 should never be internet-routable.

3. Segment inference workloads. GPU nodes should live in a dedicated network segment with egress filtering. Post-exploitation in the NEAR AI case benefited from the attacker's position on a server that could observe live request traffic. Deny outbound internet access from inference pods except to explicitly allowlisted model registries and telemetry endpoints.

4. Recalibrate TEE trust assumptions. If you rely on confidential computing (TDX, SEV-SNP, confidential GPUs) for tenant data protection, understand the boundary: TEEs protect enclave memory, not the surrounding orchestration layer. Audit what components sit outside the enclave — request routers, tokenizers, logging pipelines, schedulers — and treat them as part of your confidential data's attack surface. Remote attestation should be enforced so clients can verify they're communicating with a genuine, patched enclave.

5. Hunt retroactively. Because the attacker in this incident observed requests in flight, assume any SGLang server that was internet-reachable and unpatched may have been compromised. Run the detection queries above against at least 30 days of telemetry. Look for shells under the inference process, unexpected egress, new user accounts, modified systemd units, and container escape indicators.

6. Reduce blast radius. Run inference servers as non-root, in seccomp/AppArmor-confined containers, with read-only root filesystems and no host mounts. Drop all capabilities except those strictly required for GPU access. If a future RCE lands, these controls materially constrain the attacker.

7. Instrument your AI stack like production infrastructure. Many organizations deploy inference servers with far less telemetry than their web tier — no EDR, no auditd, no flow logs. That ends now. Linux GPU hosts need the same process, network, and file integrity monitoring as any other critical server.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub