A vulnerability has been found in D-Link DCS-935L 1

CVE-2026-13545 is a command injection (CWE-77) in the D-Link DCS-935L cloud-connected day/night Wi-Fi camera, firmware 1.10.01, inside the function sub_400E40. The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H says network-reachable, low-complexity, requires *authenticated low-privilege access* — so a logged-in user (typically the configured camera owner or anyone with HTTP basic-auth credentials) can inject shell metacharacters into a parameter that ultimately lands in a system()/popen() call, yielding code execution as the embedded web daemon — typically root on these MIPS/ARM SOHO cameras.

D-Link's HIGH (8.8) rating is *technically defensible* — it's an authenticated network RCE that gives root on the device. But it ignores deployment reality: the DCS-935L is a consumer baby-monitor camera, end-of-life since the mydlink Home cloud shutdown on 2022-12-30, almost never deployed in enterprise networks, and the prerequisite of valid credentials means the attacker either already owns the camera account or is brute-forcing default admin/admin. For an enterprise fleet of 10,000 hosts, this CVE is a MEDIUM at best — and only because some shadow-IT employee may have plugged one into a corporate VLAN.

Why this verdict

• Authentication required (PR:L) — attacker needs valid camera credentials, knocking out drive-by mass exploitation. Default-credential carelessness is the only realistic credential source.
• Role multiplier — low-value endpoint: the DCS-935L is canonically a consumer device. On a workstation-equivalent IoT role the chain ends at *root on one camera*. There is no high-value-role variant (no DC, no hypervisor, no IdP analog) — installed-base share in high-value enterprise roles is effectively 0%. Floor stays at MEDIUM.
• End-of-life device, no patch path — D-Link has already retired the cloud service (2022-12-30); there will be no firmware fix. This is a *replace-the-device* problem, not a patch problem.
• Negligible enterprise exposure — DCS-935L rarely appears in corporate asset inventories; when it does, it is shadow IoT on guest/IoT VLANs.
• No active exploitation, no KEV listing, EPSS <1% at disclosure.

Why not higher?

HIGH would require either fleet-scale blast radius or active exploitation. Neither applies: the device is a single-tenant consumer endpoint, no campaign is targeting CVE-2026-13545 specifically, and the authentication prerequisite blocks worm-scale propagation that the related unauthenticated D-Link DSL router CVEs enabled in early 2026.

Why not lower?

LOW or IGNORE would be wrong because the device runs as root, the bug is a genuine unauthenticated-equivalent in practice when default creds are unchanged (which is the realistic owner-population), and a compromised camera makes an excellent internal pivot and DDoS botnet node. Any organization that actually has one of these on its network needs to act.

1. Inventory and physically retire all DCS-935L devices — There is no patch and there will never be one. Treat this as an asset-removal exercise — find them via DHCP logs (D-Link OUIs 00:0F:3D, 28:10:7B, 90:8D:78, B0:C5:54), NAC quarantine, and physical sweep, then unplug. Per the noisgate MEDIUM SLA, no formal mitigation deadline applies — this rolls into the 365-day remediation window, but in practice complete removal within 30 days is achievable and recommended.
2. Force network isolation on any DCS-935L that cannot be immediately removed — Put the device on a dedicated IoT VLAN with no east-west reach to corporate subnets and outbound egress restricted to a deny-all default. This neutralizes both the post-exploit pivot and Mirai-class C2.
3. Rotate camera credentials and disable WAN exposure — If any DCS-935L is internet-reachable via port forwarding, kill the forward immediately. Set a long unique password on the camera's web UI to block the default-credential path that turns PR:L into effectively PR:N.
4. Add IDS coverage for HNAP brute force and shell-metacharacter injection — Deploy Suricata/Snort rules targeting /HNAP1/ POSTs containing ;, |, ` `, $(` in parameter values. Cheap signal for a low-noise endpoint class.

Run on an auditor workstation with network reach to the candidate device. Invocation: ./check.sh 192.168.1.50 — supply the camera IP. Requires curl; no special privileges. Returns VULNERABLE if the device fingerprints as a DCS-935L on firmware 1.10.01 (or any version, since none are patched), PATCHED is never returned (no patch exists), UNKNOWN if unreachable or fingerprint inconclusive.

#!/usr/bin/env bash
# noisgate check for CVE-2026-13545 — D-Link DCS-935L command injection
# Usage: ./check.sh <camera-ip>
# Exit: 0=VULNERABLE, 1=UNKNOWN, 2=PATCHED (will never return — no patch exists)
set -u
TARGET="${1:-}"
if [ -z "$TARGET" ]; then
  echo "Usage: $0 <camera-ip>" >&2
  exit 1
fi

# Fingerprint via HNAP1 SOAP action — DCS-935L responds with model+firmware
RESP=$(curl -sS -m 5 -o - -H 'SOAPAction: "http://purenetworks.com/HNAP1/GetDeviceSettings"' \
  -X POST "http://${TARGET}/HNAP1/" 2>/dev/null)

if [ -z "$RESP" ]; then
  # Try HTTPS as fallback
  RESP=$(curl -skS -m 5 -H 'SOAPAction: "http://purenetworks.com/HNAP1/GetDeviceSettings"' \
    -X POST "https://${TARGET}/HNAP1/" 2>/dev/null)
fi

if [ -z "$RESP" ]; then
  echo "UNKNOWN — host unreachable or not speaking HNAP"
  exit 1
fi

if echo "$RESP" | grep -qi 'DCS-935L'; then
  FW=$(echo "$RESP" | grep -oiE '1\.[0-9]+\.[0-9]+' | head -n1)
  echo "VULNERABLE — DCS-935L detected (firmware: ${FW:-unknown}). No patch exists. RETIRE THE DEVICE."
  exit 0
fi

echo "UNKNOWN — device did not identify as DCS-935L"
exit 1

Sources

1. GitHub Advisory Database — CVE-2026-13545
2. CVE.report — D-Link DCS-935L
3. OpenCVE — DCS-935L vulnerabilities
4. CVE Details — DCS-935L firmware version list
5. TheHackerWire — sister CVE-2026-12174 DCS-935L format string
6. D-Link End of Life Policy
7. D-Link mydlink Home EOL announcement (Dec 2022)
8. The Hacker News — Jan 2026 D-Link DSL router active exploitation context