Realtek Jungle SDK version v2

CVE-2021-35394 is an unauthenticated command-injection flaw in Realtek Jungle SDK's diagnostic component MP Daemon, usually compiled as UDPServer. The vulnerable code exists across old Realtek AP/router SDK lines, including Jungle v2.x through v3.4.14B; Realtek's own advisory names affected branches including rtl819x-SDK-v3.2.x, v3.4.x, v3.4T, v3.4T-CT, and rtl819x-eCos-v1.5.x. When UDPServer is running and reachable, a single crafted UDP payload to port 9034 can inject shell commands as the device's privileged service account.

The vendor's 9.8 baseline is technically fair for *reachable* targets: no auth, no user interaction, trivial payload, full device takeover. But the real-world severity comes down one notch because UDPServer is not universally running, is often bound to the device LAN side, and in some firmware images is just an artifact unless another component launches it. That friction narrows exposed population materially, even though KEV status, high EPSS, and large botnet activity keep this well above routine IoT backlog noise.

Why this verdict

• Started from vendor 9.8. Unauthenticated network RCE with one UDP packet deserves a critical baseline in a lab.
• Pulled down for attacker position reality. The attacker still needs network path to UDP/9034, and many deployments place these devices behind NAT, on LAN-only segments, or both.
• Pulled down again for exposure fraction. ONEKEY explicitly says some firmware auto-starts UDPServer, some launch it only indirectly, and some never run it at all; vulnerable code presence is not equal to reachable service.
• Pushed back up for exploitation evidence. KEV listing, Mirai-family campaigns, and Unit 42's 134 million observed exploit attempts mean exposed targets are getting hammered at scale.
• Pushed up for blast radius of the asset class. Even if this usually lands on a router/repeater/camera rather than a domain controller, edge devices are persistent, privileged network positions with weak telemetry and strong botnet value.

Why not higher?

Because this is not 'every vulnerable host is one packet from compromise.' The exposed population is materially narrower than the CVSS implies: UDPServer may be LAN-only, may not run by default, and may exist as dead code on some images. That compounding friction is enough to move it out of CRITICAL for broad enterprise prioritization.

Why not lower?

Because the friction ends the moment you find a reachable instance. For exposed devices this is trivial, unauthenticated, and heavily weaponized; CISA KEV and multiple vendor detections remove any doubt that attackers care. A reachable vulnerable router on the edge is too operationally valuable to dismiss as medium-grade embedded noise.

1. Block UDP/9034 at every trust boundary — Deny inbound and east-west access to UDP 9034 on router, IoT, camera, repeater, and gateway segments. Because this CVE is KEV-listed and exploited in the wild, deploy this immediately, within hours on perimeter firewalls, campus ACLs, SD-WAN policy, and NAC quarantine rules.
2. Isolate suspect Realtek-based devices — Move affected OEM devices to tightly scoped VLANs with no direct internet reachability and only the minimum management paths required. Do this immediately, within hours for any device you cannot quickly confirm as patched or non-running.
3. Hunt for UDPServer and open UDP listeners — Search firmware, running process lists, and passive network telemetry for UDPServer, MP Daemon, and UDP 9034 listeners; prioritize downstream OEM gear that does not obviously mention Realtek in the asset record. Because exposure is the key friction point, complete this triage immediately, within hours for internet-edge and branch-office gear.
4. Sinkhole known payload infrastructure and constrain egress — Observed exploitation commonly turns into downloader activity for Mirai/Gafgyt/Mozi-style binaries, so DNS sinkholing and strict outbound ACLs can break the second stage even if initial command execution lands. Apply these containment controls immediately, within hours on IoT/edge segments.
5. Prefer device replacement when vendor backports are opaque — Many downstream vendors never published transparent firmware provenance, and Realtek's fix model relies on OEM backports rather than a universal version bump. Where the OEM cannot prove its firmware includes the Realtek fix, treat replacement or decommission as the cleanest compensating action and start that process immediately, within hours for exposed assets.

Run this on the target device itself over SSH or serial shell, or against an extracted firmware rootfs mounted on a Linux analysis box. Invoke as sh verify-cve-2021-35394.sh on-device, or ROOTFS=/mnt/fw sh verify-cve-2021-35394.sh for offline analysis; root is recommended so the script can inspect processes, sockets, and init scripts.

#!/bin/sh
# verify-cve-2021-35394.sh
# Checks for likely exposure to CVE-2021-35394 on Realtek-based embedded Linux devices.
# Exit codes:
#   0 = PATCHED / not affected indicators found
#   1 = VULNERABLE / strong exposure indicators found
#   2 = UNKNOWN / insufficient evidence either way

set -u

ROOTFS="${ROOTFS:-/}"
PATH=/sbin:/bin:/usr/sbin:/usr/bin

say() { printf "%s\n" "$1"; }
exists() { command -v "$1" >/dev/null 2>&1; }

found_bin=""
running="no"
listening="no"
init_ref="no"
realtek_hint="no"

check_bins() {
  for p in \
    "$ROOTFS/bin/UDPServer" \
    "$ROOTFS/usr/bin/UDPServer" \
    "$ROOTFS/sbin/UDPServer" \
    "$ROOTFS/usr/sbin/UDPServer" \
    "$ROOTFS/bin/udpserver" \
    "$ROOTFS/usr/bin/udpserver" \
    "$ROOTFS/sbin/udpserver" \
    "$ROOTFS/usr/sbin/udpserver"; do
    if [ -f "$p" ]; then
      found_bin="$p"
      break
    fi
  done
}

check_processes() {
  if [ "$ROOTFS" = "/" ]; then
    if exists pidof && pidof UDPServer >/dev/null 2>&1; then
      running="yes"
      return
    fi
    if exists ps && ps 2>/dev/null | grep -E '[U]DPServer|[M]P[[:space:]_-]*Daemon' >/dev/null 2>&1; then
      running="yes"
      return
    fi
  fi
}

check_listeners() {
  if [ "$ROOTFS" = "/" ]; then
    if exists ss && ss -lunp 2>/dev/null | grep -E '(^|[[:space:]])9034([[:space:]]|$)' >/dev/null 2>&1; then
      listening="yes"
      return
    fi
    if exists netstat && netstat -lunp 2>/dev/null | grep -E '[:.]9034[[:space:]]' >/dev/null 2>&1; then
      listening="yes"
      return
    fi
  fi
}

check_init_refs() {
  for d in \
    "$ROOTFS/etc" \
    "$ROOTFS/etc/init.d" \
    "$ROOTFS/etc/rc.d" \
    "$ROOTFS/etc/rcS.d" \
    "$ROOTFS/etc_ro" \
    "$ROOTFS/etc_ro/init.d" \
    "$ROOTFS/etc/scripts"; do
    [ -d "$d" ] || continue
    if grep -R -E 'UDPServer|udpserver|9034|MP[[:space:]_-]*Daemon' "$d" >/dev/null 2>&1; then
      init_ref="yes"
      break
    fi
  done
}

check_realtek_hints() {
  for d in "$ROOTFS/etc" "$ROOTFS/bin" "$ROOTFS/usr/bin" "$ROOTFS/www"; do
    [ -d "$d" ] || continue
    if grep -R -i 'rtl819x\|realtek' "$d" >/dev/null 2>&1; then
      realtek_hint="yes"
      break
    fi
  done
}

report() {
  say "ROOTFS=$ROOTFS"
  say "FOUND_BINARY=${found_bin:-none}"
  say "RUNNING=$running"
  say "LISTENING_UDP_9034=$listening"
  say "INIT_REFERENCE=$init_ref"
  say "REALTEK_HINT=$realtek_hint"
}

check_bins
check_processes
check_listeners
check_init_refs
check_realtek_hints
report

# Strong vulnerable signal: binary exists and either runs, listens, or is referenced in startup paths.
if [ -n "$found_bin" ] && { [ "$running" = "yes" ] || [ "$listening" = "yes" ] || [ "$init_ref" = "yes" ]; }; then
  say "VULNERABLE"
  exit 1
fi

# If binary is absent and no listener exists, consider patched/not affected from this host's perspective.
if [ -z "$found_bin" ] && [ "$listening" = "no" ] && [ "$running" = "no" ]; then
  say "PATCHED"
  exit 0
fi

# Binary present but exposure uncertain, or listener seen without binary path clarity.
say "UNKNOWN"
exit 2

Sources

1. NVD CVE-2021-35394
2. Realtek AP-Router SDK advisory PDF
3. CISA Known Exploited Vulnerabilities entry
4. ONEKEY / IoT Inspector advisory
5. Unit 42 Realtek SDK exploitation analysis
6. HPE Threat Labs / Juniper exploitation write-up
7. FortiGuard outbreak alert
8. ProjectDiscovery nuclei template