A vulnerability was detected in Edimax EW-7478APC 1

CVE-2026-13561 is a CWE-77 command injection in the Edimax EW-7478APC (firmware v1.04), a consumer/SMB 802.11ac access point that Edimax has long since stopped iterating on. An authenticated user with low-privilege access to the web admin interface can inject shell metacharacters into a parameter that gets passed to a system call on the embedded Linux firmware, yielding command execution as the device's web daemon — almost certainly root, because that is how every BusyBox-class home router runs its httpd.

Vendor scored this 6.3 MEDIUM with vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L, reflecting that auth is required and impact is scoped to the device itself. That matches reality for *this device class*: the AP is not a domain controller, not a hypervisor, not a CA. The honest concerns are (1) most EW-7478APC units in the wild still use the factory admin/1234 credential, which collapses PR:L to effectively PR:N, and (2) a popped AP is a sniffing/MitM platform for every client SSID it terminates. Even with that, the device population is small, EOL, and rarely Internet-exposed — MEDIUM is the right bucket.

Why this verdict

• Auth required, but cheap to bypass. PR:L is the headline brake. In practice the EW-7478APC ships admin/1234 and operators rarely rotate — effective PR drifts toward N for unmaintained units.
• Role multiplier — low-value role (consumer/SMB AP): chain succeeds; blast radius is the device + the wireless segment. Not a fleet-scale outcome.
• Role multiplier — typical role (branch-office AP terminating corporate Wi-Fi): chain succeeds; blast radius extends to credential harvesting via hostapd-wpe and client MitM. Still bounded to one site, not the domain.
• Role multiplier — high-value role: N/A. This device class is never an IdP, CA, hypervisor, DC, PAM, or backup server. There is no path to a fleet-takeover floor — the deployment-role floor stays at MEDIUM.
• Tiny installed base, EOL product. Shodan/Censys shows small-thousands globally — not a worm-class population.
• No in-the-wild signal. Not KEV, EPSS ~1.2%, no GreyNoise tags, no public PoC repo at disclosure.
• Vendor will not patch. EOL means the practical answer is replacement, not waiting for firmware.

Why not higher?

HIGH would require either a fleet-scale blast radius (this is one AP at a time), unauthenticated network exploitability (PR:L is real, only weakened by default creds — not removed), or active exploitation (none observed). None of those hold.

Why not lower?

LOW would require either no path to code execution or extremely narrow exposure. Command injection to root on the device itself is unambiguous code execution, and the device sits on the network handling client traffic — that's a real position even if the population is small. MEDIUM is the right floor.

1. Rotate the admin credential off the factory default — Default admin/1234 collapses the only meaningful brake in the CVSS vector. Set a 20+ char password from a manager; if you can't audit this within 30 days, no mitigation SLA applies for MEDIUM but treat it as quick-win hygiene anyway.
2. ACL the management interface to a dedicated VLAN — Drop TCP/80, /443, /23, /22 to the AP from anywhere except a jumphost on the mgmt VLAN. This blocks step 1 of the chain entirely and is firmware-agnostic. Implement at the upstream switch/router within the 365-day noisgate remediation SLA window for MEDIUM.
3. Plan replacement — the device is EOL — Edimax has not released firmware for the EW-7478APC line in years and almost certainly will not patch this. Budget refresh to a vendor with an active SDLC (Aruba IAP, Ubiquiti UniFi, MikroTik) within the 365-day noisgate remediation SLA window.
4. Egress-filter the AP — The AP has no business initiating outbound connections except DNS and NTP. Lock egress at the gateway to break implant C2 even if the box is popped.
5. Wireless segmentation — If the AP terminates corporate SSIDs, move it to a guest-only or IoT-only segment so a compromise doesn't sit adjacent to user laptops or servers.

Run from an auditor workstation that can reach the AP management IP. Invoke as ./check_edimax.sh 192.0.2.10 (no privileges required — this is a banner + version probe, NOT an exploit attempt). Exits 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN.

#!/usr/bin/env bash
# check_edimax.sh — fingerprint Edimax EW-7478APC for CVE-2026-13561
# Usage: ./check_edimax.sh <ap_ip>
# Exit codes: 0=PATCHED 1=VULNERABLE 2=UNKNOWN
set -u
AP="${1:-}"
if [[ -z "$AP" ]]; then
  echo "Usage: $0 <ap_ip>" >&2
  exit 2
fi

# 1. Confirm the device is an Edimax web UI
HDR=$(curl -sk --max-time 5 -I "http://${AP}/" 2>/dev/null)
if ! grep -qiE 'edimax|EW-7478APC|Boa|GoAhead' <<<"$HDR"; then
  echo "UNKNOWN: ${AP} does not look like an Edimax AP (no matching banner)"
  exit 2
fi

# 2. Pull the login / status page and look for the firmware string
BODY=$(curl -sk --max-time 5 "http://${AP}/status.asp" "http://${AP}/login.asp" 2>/dev/null)
MODEL=$(grep -oE 'EW-7478APC' <<<"$BODY" | head -1)
VER=$(grep -oE 'v?1\.0[0-9]+' <<<"$BODY" | head -1)

if [[ -z "$MODEL" ]]; then
  echo "UNKNOWN: cannot confirm model on ${AP}"
  exit 2
fi

echo "Model: ${MODEL}  Firmware: ${VER:-unknown}"

# 3. Versions 1.04 and earlier are vulnerable; no fixed firmware exists
if [[ "$VER" == "v1.04" || "$VER" == "1.04" || "$VER" =~ ^v?1\.0[0-4]$ ]]; then
  echo "VULNERABLE: ${AP} is EW-7478APC ${VER} — CVE-2026-13561 (no vendor patch available)"
  exit 1
fi

if [[ -z "$VER" ]]; then
  echo "UNKNOWN: model confirmed but firmware string not parseable"
  exit 2
fi

echo "PATCHED: firmware ${VER} is newer than 1.04 (verify against vendor advisory if/when published)"
exit 0

Sources

1. CVE.org record (CVE-2026-13561)
2. VulDB — adjacent Edimax form-handler command injection (CVE-2026-9480)
3. VulDB — adjacent Edimax form-handler command injection (CVE-2026-9482)
4. Feedly — Latest Edimax Vulnerabilities
5. Edimax EW-7478APC product / download page
6. CWE-77 — Improper Neutralization of Special Elements used in a Command
7. FIRST EPSS model
8. CISA Known Exploited Vulnerabilities Catalog