← Back to Feed CACHED · 2026-10-06 23:45:04 · CACHE_KEY CVE-2026-16125
CVE-2026-16125 · CWE-918 · Disclosed 2026-07-18

SSRF via unsanitized URL in claw_net_get/claw_net_post in zevorn rt-claw

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Someone left the front door open on a dollar-store robot that nobody bought

CVE-2026-16125 is an SSRF (CWE-918) in zevorn rt-claw ≤0.2.0, a C-based open-source AI assistant framework designed for resource-constrained embedded microcontrollers like the ESP32. The vulnerable functions claw_net_get and claw_net_post in claw/services/tools/net.c accept an attacker-influenced url argument without validation, letting a remote caller force the device to make arbitrary outbound HTTP requests. Affected versions are 0.1 and 0.2.0. No patched version exists — the maintainer has not responded to the disclosure (GitHub issue #134).

The vendor CVSS of 7.3 HIGH is technically defensible in a vacuum — it's unauthenticated, remote, low-complexity, no user interaction. But it wildly overstates the real-world risk to any enterprise. This project has 13 GitHub stars and 3 forks. It runs on hobbyist IoT boards, not on anything in your asset inventory. The CVSS v4.0 re-score already dropped it to 6.9 MEDIUM, and once you account for the near-zero installed base and the trivial blast radius of an SSRF from a $1 microcontroller, the practical severity for an enterprise defender is LOW.

"Hobbyist embedded AI toy with 13 GitHub stars — not in your fleet, not your problem."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Locate an exposed rt-claw instance

The attacker must find a running rt-claw device that accepts network connections. The device is typically an ESP32 or similar MCU on a local WiFi/IoT segment. The attacker either needs to be on the same network or the device must be inadvertently exposed to the internet — an extremely unlikely scenario for a hobbyist project with near-zero deployments.
Conditions required:
  • rt-claw device is deployed and network-reachable
  • Attacker has network adjacency or device is internet-facing
Where this breaks in practice:
  • Project has 13 GitHub stars — probability of any enterprise running this is effectively zero
  • Embedded IoT devices are typically on isolated VLAN/IoT segments, not routable from the internet
  • No Shodan/GreyNoise/Censys fingerprints exist for this software
Detection/coverage: No scanner plugins, Nuclei templates, or vulnerability scanner checks exist for rt-claw.
STEP 02

Influence the url parameter via tool-call interface

The SSRF is in the AI assistant's HTTP tool functions (claw_net_get/claw_net_post). The attacker must craft input — likely through the assistant's chat/prompt interface — that causes the LLM to invoke the network tool with an attacker-controlled URL. This is essentially a prompt-injection-to-SSRF chain, adding a layer of indirection and unreliability.
Conditions required:
  • Attacker can interact with the rt-claw AI assistant's input interface
  • The LLM-based tool-calling pipeline passes attacker-controlled URLs without sanitization
Where this breaks in practice:
  • Requires prompt injection to succeed — LLM tool-calling is non-deterministic
  • The assistant may refuse or rewrite URLs depending on system prompt and model behavior
  • No known weaponized tool or framework targets this specific chain
STEP 03

SSRF fires from embedded device

The rt-claw device makes an outbound HTTP request to an attacker-specified destination. This could target internal services reachable from the device's network position (e.g., cloud metadata endpoints at 169.254.169.254, internal APIs, or other IoT devices on the same segment). Impact is bounded by CVSS C:L/I:L/A:L — partial confidentiality, integrity, and availability impact.
Conditions required:
  • Device has outbound HTTP capability (WiFi or Ethernet connected)
  • Target internal services are reachable from the device's network segment
Where this breaks in practice:
  • Embedded devices typically have minimal network access — no credentials, no domain membership, no access to enterprise resources
  • Cloud metadata endpoints are irrelevant for bare-metal MCUs
  • Blast radius is limited to whatever a $1 microcontroller can reach on its VLAN
Detection/coverage: Network monitoring/IDS could detect anomalous outbound requests from IoT devices, but no signatures exist for this specific SSRF.
03 · Compensating Control

1
LOW 2.5→IGNORE 0.0
SEVERITY REDUCED
Remove rt-claw from any network-connected deployment — If you somehow have rt-claw running in your environment (R&D lab, maker space, IoT prototype bench), disconnect it from production networks. As a LOW-severity finding, there is no noisgate mitigation SLA — treat this as backlog hygiene. The software has no patch and the maintainer is unresponsive, so removal is the only definitive remediation.
2
LOW 2.5→IGNORE 0.0
SEVERITY REDUCED
Isolate IoT/embedded devices on a dedicated VLAN with no internal routing — Standard IoT network segmentation prevents any SSRF from an embedded device from reaching enterprise resources. This is a baseline hygiene control you should already have. Even without this specific CVE, IoT devices should never share a network segment with production infrastructure.
3
LOW 2.5→IGNORE 0.0
SEVERITY REDUCED
Block outbound HTTP from IoT segments at the firewall — If embedded devices don't need arbitrary outbound HTTP, block it at the perimeter/internal firewall. This breaks the SSRF chain entirely regardless of the application-layer vulnerability.
What doesn't work
  • WAF or reverse proxy in front of rt-claw — the SSRF is outbound (the device makes requests), not inbound request smuggling. A WAF inspecting inbound traffic doesn't help.
  • Patching — no patch exists. The maintainer has not responded. You cannot remediate by upgrading.
  • Input validation at the LLM layer — prompt engineering or system-prompt hardening might reduce SSRF trigger probability but is not a reliable security control for a code-level vulnerability.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone observed. Not listed in CISA KEV. No campaigns, no threat actor attribution, no mentions in threat intel feeds.
Proof-of-ConceptThe advisory states "the exploit has been disclosed to the public and may be used," likely referring to the GitHub issue #134 on the zevorn/rt-claw repo. No standalone PoC repos found on GitHub or pocindex.io. No Nuclei template, ExploitDB entry, or Metasploit module exists.
EPSS Score0.00495 (~0.5th percentile) — bottom of the distribution, confirming negligible exploitation probability.
KEV StatusNot listed. No CISA KEV entry. No BOD 22-01 deadline applies.
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L — unauthenticated remote SSRF, but all three impact metrics are Low. CVSS v4.0 rescored to 6.9 MEDIUM.
Affected Versionsrt-claw 0.1 and 0.2.0. No other versions exist. No distro packages — this is source-only from GitHub.
Fixed VersionNone. The maintainer has not responded to the disclosure. No patch, no workaround issued by the project.
Installed Base / ExposureGitHub repo has 13 stars, 3 forks. No Shodan, Censys, GreyNoise, or FOFA fingerprints. No known enterprise deployments. This is a hobbyist embedded AI framework for $1 microcontrollers.
Disclosure Date2026-07-18 — disclosed via GitHub issue and picked up by VulDB/NVD.
Reporter / OrgNot attributed to a named researcher or organization in available advisories. Appears to be a VulDB-originated disclosure.

Sources.

  1. NVD / OpenCVE — CVE-2026-16125
  2. CyberStrike CVE Detail — CVE-2026-16125
  3. zevorn/rt-claw GitHub Repository
  4. OSV — CVE-2026-16125
  5. CWE-918: Server-Side Request Forgery
  6. Exploit Intel — zevorn Vulnerabilities
  7. Threat Radar — rt-claw Advisories
05 · The Call

Final Verdict
↓ DOWNGRADED to LOW (2.5/10)

Why this verdict

  • Near-zero installed base kills practical risk. 13 GitHub stars and 3 forks. This is a hobbyist project for $1 ESP32 boards. The probability that any host in a 10,000-seat enterprise fleet runs rt-claw is effectively 0%. No scanner will ever flag this because the software isn't in enterprise environments.
  • Role multiplier: no high-value role applies. rt-claw is an embedded AI chatbot framework for microcontrollers. It is not an identity provider, hypervisor, CI/CD system, backup tool, database, security agent, network appliance, or SCADA controller. It occupies none of the high-value-role categories. The HIGH floor does not apply — 0% of installs serve any enterprise-critical function.
  • SSRF blast radius is trivial. Even if exploited, the SSRF fires from a resource-constrained MCU on an IoT VLAN. The device has no domain credentials, no access to enterprise data stores, and no trust relationships. C:L/I:L/A:L on a $1 microcontroller means the worst case is probing adjacent IoT devices — not domain takeover, not data exfiltration, not supply-chain compromise.
  • Exploitation chain has a non-deterministic step. The attacker must succeed at prompt injection against the AI assistant's LLM to trigger the SSRF — this is unreliable and not weaponizable at scale. No known tooling exists for this chain.
  • EPSS confirms negligible threat. At 0.5%, EPSS places this in the bottom tier of exploitation likelihood. No KEV listing, no campaigns, no threat actor interest.

Why not higher?

The unauthenticated remote vector and public disclosure warrant a non-zero score, but every real-world signal — installed base, exploitation data, blast radius, high-value-role analysis — points to negligible enterprise risk. Upgrading to MEDIUM would imply this belongs in a 365-day remediation window, which overstates its priority relative to actual enterprise vulnerabilities competing for the same patching cycles.

Why not lower?

A working SSRF with a public exploit in software that has no patch does exist in the wild, even if the software itself is obscure. IGNORE would mean no documentation, which isn't appropriate for a CVE with a valid CWE and a confirmed exploit path. If an enterprise somehow runs rt-claw (e.g., an R&D lab prototyping IoT assistants), they should know about it.

06 · Verification

Crowdsourced verification payload.

Run this on any host where you suspect rt-claw might be compiled or installed. It checks for the presence of the rt-claw binary or source tree. No special privileges required. Example: bash check_cve_2026_16125.sh

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_16125.sh
# Checks for the presence of zevorn rt-claw <= 0.2.0 (CVE-2026-16125)
# SSRF in claw_net_get/claw_net_post in claw/services/tools/net.c
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

VULN_FILE="claw/services/tools/net.c"
ALT_FILE="claw/tools/tool_net.c"
FOUND=0

# Check 1: Look for rt-claw source trees
for search_dir in /opt /home /root /srv /usr/local/src "$HOME"; do
  if [ -d "$search_dir" ]; then
    while IFS= read -r -d '' match; do
      echo "[!] Found rt-claw source tree: $(dirname "$match")"
      FOUND=1
    done < <(find "$search_dir" -maxdepth 6 -name "net.c" -path "*/claw/*tools/*" -print0 2>/dev/null || true)
  fi
done

# Check 2: Look for compiled rt-claw binaries
for bin_name in rt-claw rt_claw claw; do
  if command -v "$bin_name" &>/dev/null; then
    echo "[!] Found rt-claw binary in PATH: $(command -v "$bin_name")"
    FOUND=1
  fi
  while IFS= read -r -d '' match; do
    echo "[!] Found rt-claw binary: $match"
    FOUND=1
  done < <(find /usr/local/bin /opt -maxdepth 4 -name "$bin_name" -type f -print0 2>/dev/null || true)
done

# Check 3: Look for rt-claw in running processes
if pgrep -f 'rt.claw' &>/dev/null; then
  echo "[!] rt-claw process detected running"
  FOUND=1
fi

if [ "$FOUND" -eq 1 ]; then
  echo "VULNERABLE — rt-claw <= 0.2.0 detected (no patched version exists)"
  exit 0
else
  echo "PATCHED — no rt-claw installation found on this host"
  exit 1
fi