A security vulnerability has been detected in JingDong JD Cloud Box AX6600 4

CVE-2026-11413 is a stack-based buffer overflow in the set_macfilter function inside /sbin/jdcweb_rpc on the JingDong JD Cloud Box AX6600, disclosed on 2026-06-06. The record and public mirrors describe the affected target as firmware 4.5.3.r4546 and score it with PR:L, which means the published attack model assumes the attacker already has a valid low-privilege account on the device's management surface.

The vendor-style 8.8/HIGH score is technically defensible in a lab because an authenticated network attacker can plausibly drive memory corruption to full device compromise. In enterprise reality, that overstates urgency: this is a niche consumer/SMB router, typically LAN-side only, and the attack precondition is already a meaningful compromise stage. Public exploit code keeps it out of backlog-junk territory, but the attacker-position requirement and limited enterprise population pull it down to MEDIUM.

Why this verdict

• Down from 8.8 because PR:L means post-auth: the attacker needs valid credentials or an authenticated session before touching the vulnerable path.
• Down again because exposure is narrow: this is a JD Cloud consumer/SMB router, not a mainstream enterprise platform deployed across thousands of corporate nodes.
• Down again because management-plane reachability is usually limited: in modern deployments the admin UI tends to sit on LAN/VPN space, not broad internet exposure.
• Back up slightly because a public exploit exists: once an attacker has access, the barrier to testing and weaponization is lower than a source-only or theoretical memory-corruption bug.
• Back up slightly because router compromise is strategically useful: a successful hit can alter DNS, firewalling, and traffic visibility at the edge.

Why not higher?

This does not deserve HIGH or CRITICAL unless you know these routers are broadly deployed and their management planes are reachable by attackers at scale. The published vector's PR:L requirement is a hard reality check: authenticated remote on an edge appliance is materially less urgent than unauthenticated internet RCE.

Why not lower?

This is not backlog fluff because the flaw is memory corruption on a router control binary with public exploit material already referenced by NVD. If you do run these devices, a compromised low-privilege account can plausibly become full device takeover, which is too dangerous for a LOW/IGNORE bucket.

1. Restrict management-plane reachability — Move the AX6600 admin surface behind VPN, dedicated management VLANs, or host-based ACLs so only trusted admin stations can reach it. For a MEDIUM verdict there is no noisgate mitigation SLA, so do this at the next practical change window while you track firmware remediation.
2. Rotate and minimize router accounts — Because the exploit path assumes PR:L, kill shared credentials, remove stale users, and rotate admin and support passwords now. There is no noisgate mitigation SLA for MEDIUM, but this directly attacks the most important prerequisite and should not wait for firmware news.
3. Watch for router config drift — Alert on DNS, firewall, WAN-management, and account changes on these devices, plus unexpected reboots of jdcweb_rpc-adjacent services. Use this as a detection backstop until you can verify patched firmware and complete remediation within the remediation window.
4. Segment branch and home-office edge devices — Treat these routers as semi-trusted appliances and prevent them from reaching core management networks except where explicitly needed. Again, no noisgate mitigation SLA applies at MEDIUM, but segmentation cuts blast radius immediately.

Run this on the target AX6600 over SSH or local shell, ideally as root or an admin-capable shell user with read access to /sbin/jdcweb_rpc and firmware metadata. Example: sh check_cve_2026_11413.sh. It checks whether the device appears to be an AX6600 on firmware 4.5.3.r4546 and whether the vulnerable binary exposes set_macfilter; because no authoritative fixed version was found, anything else is reported as PATCHED only relative to the published affected build, not as a vendor-confirmed safe version.

#!/bin/sh
# check_cve_2026_11413.sh
# Detect likely exposure to CVE-2026-11413 on JingDong JD Cloud Box AX6600
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

get_version() {
  for f in /etc/openwrt_release /etc/os-release /etc/version /proc/version; do
    [ -r "$f" ] || continue
    v=$(grep -Eo '4\.5\.3\.r4546|4\.5\.[0-9]+\.r[0-9]+' "$f" 2>/dev/null | head -n 1)
    if [ -n "$v" ]; then
      echo "$v"
      return 0
    fi
  done
  return 1
}

get_model() {
  for f in /tmp/sysinfo/model /proc/device-tree/model /etc/board.json /etc/openwrt_release; do
    [ -r "$f" ] || continue
    m=$(strings "$f" 2>/dev/null | grep -Ei 'AX6600|JD Cloud Box|JingDong|JDCloud' | head -n 1)
    if [ -n "$m" ]; then
      echo "$m"
      return 0
    fi
  done
  return 1
}

BIN="/sbin/jdcweb_rpc"
MODEL="$(get_model || true)"
VERSION="$(get_version || true)"
HAS_BIN=0
HAS_FUNC=0

if [ -x "$BIN" ] || [ -r "$BIN" ]; then
  HAS_BIN=1
  if strings "$BIN" 2>/dev/null | grep -q 'set_macfilter'; then
    HAS_FUNC=1
  fi
fi

if [ -z "$MODEL" ] && [ "$HAS_BIN" -eq 0 ]; then
  echo "UNKNOWN - unable to confirm AX6600 model or locate $BIN"
  exit 2
fi

if [ "$HAS_BIN" -eq 1 ] && [ "$HAS_FUNC" -eq 1 ] && [ "$VERSION" = "4.5.3.r4546" ]; then
  echo "VULNERABLE - AX6600 indicators present, $BIN exports set_macfilter, firmware appears to be 4.5.3.r4546"
  exit 1
fi

if [ -n "$VERSION" ] && [ "$VERSION" != "4.5.3.r4546" ]; then
  echo "PATCHED - firmware is not the specifically published affected build (found: $VERSION). Note: no vendor-confirmed fixed version was available in reviewed sources."
  exit 0
fi

if [ "$HAS_BIN" -eq 1 ] && [ "$HAS_FUNC" -eq 0 ]; then
  echo "PATCHED - $BIN present but set_macfilter symbol/string not observed"
  exit 0
fi

echo "UNKNOWN - insufficient evidence to map this device to the published vulnerable build"
exit 2

Sources

1. NVD CVE-2026-11413
2. Tenable CVE-2026-11413 mirror
3. CVE.org record page
4. VulDB CVE entry
5. VulDB submission reference
6. Public exploit archive referenced by NVD
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS overview