Back to Intelligence

CVE-2026-93839: Critical LightLLM /pd_register Authentication Bypass — Detection and Remediation Guide

SA
Security Arsenal Team
September 18, 2026
10 min read

NVD has published CVE-2026-93839, a CVSS 9.8 (CRITICAL) vulnerability in LightLLM through version 1.2.0 — a high-performance LLM inference and serving framework that has seen rapid adoption in production AI stacks. The flaw is an authentication bypass in the /pd_register WebSocket endpoint: any unauthenticated, network-reachable attacker can register arbitrary inference nodes by supplying crafted JSON, because the endpoint performs no peer address validation.

The impact chain is ugly. Attackers can:

  1. Register a rogue node and receive full user prompts routed to their socket — a direct confidentiality breach of anything users send to the model (PII, credentials, source code, business data).
  2. Replace legitimate nodes to trigger denial of service against the inference cluster.
  3. Coerce the PD Master into issuing requests to internal network addresses — effectively a server-side request forgery primitive that turns your AI serving layer into a pivot point into otherwise segmented internal infrastructure.

If your organization runs self-hosted LLM inference with LightLLM — and given the 2025–2026 wave of on-prem AI adoption, many do — this needs to be treated with the same urgency as an internet-facing RCE. The attack requires no credentials, no user interaction, and no special positioning beyond network reachability.

Technical Analysis

Affected Product and Versions

  • Product: LightLLM (open-source LLM inference/serving framework)
  • Affected versions: All releases through 1.2.0
  • Component: /pd_register WebSocket endpoint on the PD (Prefill/Decode) Master service
  • CVE: CVE-2026-93839 — CVSS v3.1: 9.8 (CRITICAL), network-exploitable (AV:N), low attack complexity, no privileges required, no user interaction

How the Vulnerability Works

LightLLM's disaggregated serving architecture separates prefill and decode work across nodes, coordinated by a PD Master. New worker nodes announce themselves to the master via the /pd_register WebSocket endpoint. In versions through 1.2.0, that endpoint:

  • Does not require authentication before accepting a registration payload.
  • Does not validate the peer address of the connecting client against any allowlist or expected node inventory.
  • Accepts attacker-crafted JSON as a legitimate node registration.

From a defender's perspective, the attack chain looks like this:

  1. Reconnaissance: Attacker identifies exposed LightLLM PD Master services (commonly reachable on the framework's HTTP/WebSocket serving ports) via scanning or misconfigured ingress.
  2. Registration: Attacker opens a WebSocket connection to /pd_register and submits a crafted registration payload impersonating a worker node.
  3. Impact — one or more of:
    • Prompt interception: Traffic destined for inference is routed to the attacker's socket, disclosing complete user prompts in cleartext.
    • Node replacement / DoS: Legitimate node registrations are displaced, breaking serving capacity.
    • Internal SSRF: The PD Master is instructed to issue requests to attacker-specified internal addresses, enabling port scanning, metadata service access (e.g., cloud instance metadata at 169.254.169.254), and interaction with unauthenticated internal services.

Exploitation Status

As of publication, exploitation details are limited to the vulnerability description in the NVD record. There is no confirmed CISA KEV listing yet, but the combination of a trivial network-reachable bypass, no authentication requirement, and the rapid growth of exposed AI inference services on the public internet makes this a high-priority patch candidate before public proof-of-concept code appears. Treat it as likely-to-be-weaponized.

Detection & Response

The most reliable detection surfaces are: (1) inbound requests to the /pd_register endpoint from non-inventory hosts, (2) the LightLLM server process making unexpected outbound connections to internal addresses (SSRF), and (3) anomalous child processes under the LightLLM server indicating post-compromise activity.

Sigma Rules

YAML
---
title: LightLLM PD Register Endpoint Access From Unauthorized Source
description: Detects inbound requests to the LightLLM /pd_register WebSocket endpoint, which is vulnerable to unauthenticated node registration in CVE-2026-93839. Tune the filter to your known inference node IP inventory.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-93839
author: Security Arsenal
date: 2026/04/10
status: experimental
logsource:
  category: webserver
  product: linux
detection:
  selection:
    cs-uri-stem|contains: '/pd_register'
  filter_authorized_nodes:
    c-ip|startswith:
      - '10.10.20.'   # Replace with your authorized inference node subnets
      - '192.168.50.' # Replace with your authorized inference node subnets
  condition: selection and not filter_authorized_nodes
falsepositives:
  - Legitimate node registration from hosts not yet added to the inventory filter
level: high
---
title: LightLLM Server SSRF to Internal Address Ranges
description: Detects the LightLLM server process initiating network connections to RFC1918 or link-local addresses, consistent with CVE-2026-93839 abuse forcing the PD Master to issue requests to internal network addresses (including cloud metadata services).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-93839
  - https://attack.mitre.org/techniques/T1090/
author: Security Arsenal
date: 2026/04/10
status: experimental
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    Image|contains:
      - 'lightllm'
      - 'python'
    DestinationIp|startswith:
      - '169.254.'
      - '10.'
      - '192.168.'
      - '172.16.'
  filter_known_model_hosts:
    DestinationIp|startswith:
      - '10.10.20.'   # Replace with legitimate model/storage/peer subnets
  condition: selection and not filter_known_model_hosts
tags:
  - attack.exfiltration
  - attack.t1090
falsepositives:
  - Legitimate model weight downloads or intra-cluster traffic from hosts running lightllm under python
level: high
---
title: Suspicious Child Process Spawned by LightLLM Server
description: Detects shell or scripting interpreters spawned as children of a LightLLM serving process, indicating potential post-exploitation activity following node hijacking via CVE-2026-93839.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-93839
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/10
status: experimental
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains: 'lightllm'
  selection_child:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/python3'
  condition: selection_parent and selection_child
tags:
  - attack.execution
  - attack.t1059
falsepositives:
  - Wrapper scripts or health checks intentionally launched by the serving process
level: critical

Microsoft Sentinel / Defender KQL

This query hunts web/proxy logs ingested into Sentinel (via CEF/Syslog from your reverse proxy, load balancer, or WAF) for hits on the vulnerable endpoint, and pairs it with a network-level hunt for SSRF behavior from inference hosts:

KQL — Microsoft Sentinel / Defender
// Hunt 1: Inbound requests to the vulnerable /pd_register endpoint
let AuthorizedNodes = dynamic(["10.10.20.", "192.168.50."]); // Replace with your inference node subnets
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where RequestURL has "/pd_register" or AdditionalExtensions has "/pd_register"
| where not(SourceIP has_any (AuthorizedNodes))
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, RequestURL, RequestMethod, DeviceAction
| sort by TimeGenerated desc;

// Hunt 2: LightLLM hosts initiating connections to internal/metadata addresses (SSRF)
Syslog
| where TimeGenerated > ago(14d)
| where SyslogMessage has "lightllm"
| where SyslogMessage has_any ("169.254.169.254", "100.100.2.148", "metadata")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| sort by TimeGenerated desc;

// Hunt 3: New or unexpected WebSocket upgrade activity against inference servers
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where AdditionalExtensions has "Upgrade: websocket" or RequestURL has "/pd_"
| summarize ConnectionCount = count(), UniqueSources = dcount(SourceIP) by DestinationIP, DestinationPort
| where UniqueSources > 5  // Registration endpoints should see very few, stable source IPs
| sort by UniqueSources desc

Velociraptor VQL

Use this artifact across your inference fleet to inventory LightLLM processes and their live network connections, flagging connections to internal or link-local destinations that shouldn't exist under normal serving patterns:

VQL — Velociraptor
-- Hunt LightLLM processes and their network connections for SSRF indicators (CVE-2026-93839)
LET lightllm_procs = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'lightllm'
   OR Exe =~ 'lightllm'

LET suspicious_conns = SELECT Pid, Name, Status,
       Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort
FROM netstat()
WHERE Name =~ 'python|lightllm'
  AND Raddr.IP =~ '^(169\\.254\\.|10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.)'
  AND Status =~ 'ESTABLISHED|SYN'

SELECT * FROM lightllm_procs
UNION ALL
SELECT Pid, Name, Status AS CommandLine, format(format='%v:%v', args=[RemoteIP, RemotePort]) AS Exe,
       LocalIP AS Username, NULL AS CreateTime
FROM suspicious_conns

Verification and Hardening Script

Run this Bash script on LightLLM hosts to identify the installed version, flag vulnerable deployments, and apply compensating network controls while you schedule the upgrade:

Bash / Shell
#!/bin/bash
# CVE-2026-93839 — LightLLM verification and interim hardening
# Run as root or with sudo on each LightLLM host.

echo "=== [1] Identify installed LightLLM version ==="
if command -v pip3 >/dev/null 2>&1; then
    VER=$(pip3 show lightllm 2>/dev/null | awk '/^Version:/{print $2}')
    echo "Installed lightllm version: ${VER:-NOT FOUND}"
else
    VER=$(python3 -c 'import lightllm; print(lightllm.__version__)' 2>/dev/null)
    echo "Installed lightllm version (module): ${VER:-NOT FOUND}"
fi

if [ -n "$VER" ]; then
    # Vulnerable: all versions through 1.2.0
    if [ "$(printf '%s\n' "1.2.0" "$VER" | sort -V | head -n1)" = "$VER" ] && [ "$VER" != "1.2.1" ]; then
        if printf '%s\n%s\n' "$VER" "1.2.0" | sort -V -C; then
            echo "[!] VULNERABLE: lightllm $VER <= 1.2.0 is affected by CVE-2026-93839"
        fi
    fi
fi

echo ""
echo "=== [2] Check for exposed /pd_register listeners ==="
ss -tlnp 2>/dev/null | grep -iE 'lightllm|python' || echo "No lightllm listeners found via ss"

echo ""
echo "=== [3] Check recent access to /pd_register (common log locations) ==="
for LOG in /var/log/nginx/access.log /var/log/apache2/access.log /var/log/haproxy.log; do
    if [ -f "$LOG" ]; then
        echo "--- $LOG ---"
        grep -i 'pd_register' "$LOG" | tail -n 20
    fi
done

echo ""
echo "=== [4] Apply interim egress block to cloud metadata (SSRF mitigation) ==="
# Blocks the PD Master from reaching instance metadata services if abused for SSRF.
iptables -C OUTPUT -d 169.254.169.254 -j REJECT 2>/dev/null || \
    iptables -A OUTPUT -d 169.254.169.254 -j REJECT -m comment --comment "CVE-2026-93839 SSRF mitigation"
echo "Egress block for 169.254.169.254 applied (verify with: iptables -L OUTPUT -n)"

echo ""
echo "=== [5] Remediation: upgrade LightLLM ==="
echo "Run after change-window approval:"
echo "  pip3 install --upgrade lightllm"
echo "  # Verify the patched release notes explicitly reference CVE-2026-93839 / /pd_register auth"
echo ""
echo "=== [6] Compensating control: restrict PD Master ingress ==="
echo "Place the PD Master behind a reverse proxy or firewall that allows /pd_register"
echo "ONLY from your known inference node inventory. Example nftables rule:"
echo "  nft add rule inet filter input ip saddr != { 10.10.20.0/24, 192.168.50.0/24 } tcp dport <PD_PORT> drop"

Remediation

  1. Upgrade immediately. All LightLLM versions through 1.2.0 are affected. Upgrade to the first release after 1.2.0 that remediates the /pd_register authentication gap, and confirm in the project's release notes / GitHub security advisory that the fix adds authentication and peer address validation to node registration. Reference: NVD — CVE-2026-93839.
  2. Inventory exposure now. Enumerate every LightLLM PD Master in your environment — including shadow AI deployments stood up by data science teams outside change control. Confirm none are reachable from the internet or from untrusted internal segments. A CVSS 9.8 network-exploitable auth bypass on an internet-facing service is a patch-today event.
  3. Segment the inference control plane. The /pd_register endpoint and the PD Master's management interfaces should be reachable only from your known inference node inventory. Enforce this with host firewalls, security groups, or a reverse proxy allowlist. Node registration traffic should originate from a small, stable set of source IPs — anything else is anomalous by definition.
  4. Add authentication at the edge. Until patched, place an authenticating reverse proxy in front of the PD Master and require mTLS or signed tokens for the registration path.
  5. Constrain egress from inference hosts. Deny outbound access from PD Master nodes to link-local metadata addresses (169.254.169.254) and to internal segments the inference layer has no business reaching. This directly blunts the SSRF impact path even if registration is abused.
  6. Review logs retroactively. Query at least 30 days of proxy/WAF/host logs for requests to /pd_register from non-inventory sources and for PD Master connections to unexpected internal destinations. Prompt disclosure is silent — absence of a DoS event does not mean absence of compromise.
  7. Assess data exposure. If rogue registrations occurred, treat routed prompts as breached data. Evaluate regulatory obligations (PCI-DSS, HIPAA, GDPR) based on what user data traversed the inference layer during the exposure window.
  8. Monitor for CISA KEV inclusion. Given the severity and exploitability, track the CISA Known Exploited Vulnerabilities catalog; KEV listing would impose Binding Operational Directive remediation timelines for federal agencies and is a strong prioritization signal for everyone else.

Related Resources

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

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.