A vulnerability was found in zevorn rt-claw up to 0

rt-claw is a zevorn-authored, OpenClaw-inspired embedded AI-assistant runtime targeted at ESP32-class microcontrollers — think 'ChatGPT-on-a-dev-board' with tool-use, memory, and networking baked in. CVE-2026-16125 sits in the same claw/services/tools/net.c code path as the sibling advisories (16200/16201/16204), specifically the claw_net_get / claw_net_post helpers exposed to the LLM tool-invocation layer. Because those helpers accept an attacker-influenced URL with no allow-listing, the device can be coaxed into issuing HTTP requests to arbitrary hosts — the textbook CWE-918 SSRF shape. All versions up to and including 0.2.0 are affected; no fixed release exists as of disclosure.

The vendor-blessed CVSS 7.3 / HIGH is generous. Yes, the vector is AV:N/AC:L/PR:N/UI:N — unauthenticated network reach — but every metric that matters is C:L/I:L/A:L, because the *thing* being exploited is a solder-your-own hobby board, not an enterprise fleet. Score-inflation on GitHub-hosted micro-projects is standard; the practitioner-relevant read here is that this is a *product-fit* HIGH masquerading as an *enterprise-risk* HIGH. If you don't ship rt-claw firmware, this CVE does not belong in your Monday queue.

Why this verdict

• Installed-base collapse: rt-claw is a personal-project ESP32 runtime. Even generous estimates put enterprise deployment at effectively 0%, far below any exposure threshold that would justify HIGH.
• Role multiplier: low-value only. Deployment role spectrum is (a) hobbyist bench, (b) home-lab automation, (c) — nothing. There is no high-value canonical role (no IdP, no hypervisor, no CI runner, no DC) where this bug is *in* the trust-critical component. The role floor does not lift the verdict.
• Impact ceiling is C:L/I:L/A:L by vendor's own vector — SSRF against an ESP32 gives you a tiny-buffered LAN probe, not credential theft, not RCE, not domain takeover.
• No detection or KEV pressure: EPSS 0.00288, no KEV, no observed exploitation, no PoC campaign. Nothing is forcing this up the queue.
• Reachability requires internal LAN position because devices sit behind residential NAT. Any attacker positioned to talk to your ESP32 already has better targets on the same segment.

Why not higher?

Nothing about this bug touches an enterprise trust plane. The vendor CVSS 7.3 assumes the affected asset is worth defending like a server; it isn't. Without KEV, without a mass-exploitation vector, and without a domain/tenant/fleet blast radius, MEDIUM or HIGH would over-allocate scarce patch cycles.

Why not lower?

IGNORE is only appropriate when the software provably does not exist in your environment. Because rt-claw *can* be flashed onto ESP32 devices by curious engineers or lab teams and can be pointed at internal URLs from a corporate IoT VLAN, LOW keeps it visible as backlog hygiene for asset-inventory teams.

1. Inventory ESP32 / embedded-AI firmware in labs and OT segments — Ask hardware and IoT-lab teams whether anyone has flashed rt-claw, openclaw, or picoclaw variants. This is not a CMDB item today. No mitigation SLA at LOW — fold into your standard 365-day remediation window.
2. Segment IoT / hobbyist VLANs from management and metadata endpoints — Any SSRF-capable device on the same segment as router admin pages, printer web UIs, or cloud metadata IPs (169.254.169.254) is a pivot risk regardless of this specific CVE. Enforce egress ACLs from IoT segments to RFC1918 management ranges.
3. If rt-claw is in use, disable or allow-list the net_get / net_post tools in the LLM tool schema — Recompile the firmware with the network tools removed from the tool registry, or wrap them with a hostname allow-list. This is a source-level change — no vendor patch to consume.
4. Prioritize the sibling CVE-2026-16204 (code injection) over this one — If you run rt-claw at all, the tool_run_script_execute code-injection sibling is a materially worse bug than the SSRF and should drive the remediation decision.

Run on any Linux auditor workstation with network reach to the suspected device. Invoke as ./check-rtclaw.sh 192.168.1.42 — no privileges required. The script probes for the rt-claw HTTP surface and version-strings the firmware banner.

#!/usr/bin/env bash
# noisgate check for CVE-2026-16125 — zevorn rt-claw SSRF via claw_net_get/claw_net_post
# Usage: ./check-rtclaw.sh <device-ip> [port]
set -u
TARGET="${1:-}"
PORT="${2:-80}"
if [[ -z "$TARGET" ]]; then
  echo "usage: $0 <device-ip> [port]" >&2
  exit 2
fi

BANNER=$(curl -sS --max-time 5 "http://${TARGET}:${PORT}/" 2>/dev/null || true)
INFO=$(curl -sS --max-time 5 "http://${TARGET}:${PORT}/info" 2>/dev/null || true)
BLOB="${BANNER}${INFO}"

if [[ -z "$BLOB" ]]; then
  echo "UNKNOWN: no HTTP response from ${TARGET}:${PORT}"
  exit 3
fi

if echo "$BLOB" | grep -qiE 'rt-?claw|zevorn|openclaw'; then
  VER=$(echo "$BLOB" | grep -oiE 'rt-?claw[/ ]?v?[0-9]+\.[0-9]+(\.[0-9]+)?' | head -1 | grep -oE '[0-9]+\.[0-9]+(\.[0-9]+)?')
  if [[ -z "$VER" ]]; then
    echo "VULNERABLE: rt-claw fingerprint present, version undetermined (assume ≤ 0.2.0)"
    exit 1
  fi
  # naive semver compare vs 0.2.0
  if printf '%s\n0.2.0\n' "$VER" | sort -V | tail -1 | grep -qx "0.2.0"; then
    echo "VULNERABLE: rt-claw ${VER} (≤ 0.2.0, no fixed release)"
    exit 1
  else
    echo "UNKNOWN: rt-claw ${VER} — no known fix, treat as vulnerable pending vendor advisory"
    exit 3
  fi
fi

echo "PATCHED: no rt-claw fingerprint on ${TARGET}:${PORT}"
exit 0

Sources

1. GitHub — zevorn/rt-claw project
2. OffSeq Threat Radar — CVE-2026-16201 (sibling info-disclosure in same net.c)
3. OffSeq Threat Radar — CVE-2026-16200 (authz sibling)
4. OffSeq Threat Radar — CVE-2026-16204 (code-injection sibling)
5. OffSeq Threat Radar — CVE-2026-16196 (Sipeed PicoClaw SSRF, adjacent codebase)
6. CWE-918: Server-Side Request Forgery (MITRE)
7. GitHub Advisory Database (unreviewed advisories index)
8. CISA KEV Catalog (confirm non-listing)