The TL-WR940N v6 router contains a vulnerability in its RTSP connection tracking module that can lead to a…

CVE-2026-12935 is a stack-based buffer overflow (CWE-121) in the RTSP connection tracking kernel module of the TP-Link TL-WR940N v6 consumer wireless router. When a LAN-side client initiates a connection to a malicious RTSP server controlled by an attacker, specially crafted RTSP response data triggers improper memory handling in the kernel conntrack helper. Successful exploitation yields denial of service or full remote code execution as root on the device. Affected firmware spans all TL-WR940N v6 builds prior to (US)_V6_260528, (EU)_V6_260528, and (JP)_V6_260527. Only hardware revision v6 is impacted — no other TL-WR940N revisions or TP-Link models are named in the advisory.

TP-Link assigned a CVSS 4.0 score of 8.7 (High), which accurately reflects the theoretical impact — unauthenticated kernel-level RCE on a network device. However, for enterprise security teams managing fleet infrastructure, this score dramatically overstates operational risk. The TL-WR940N is a sub-$25 consumer 802.11n router with no enterprise management capabilities, no centralized deployment, and near-zero presence in managed corporate networks. The attack also requires user interaction: a LAN client must be lured into connecting to an attacker-controlled RTSP server, meaning this is not a scan-and-pop vulnerability. For the audience managing 10,000 enterprise hosts, this CVE is background noise unless you have unmanaged SOHO equipment at branch locations.

Why this verdict

• User interaction required: The CVSS vector includes UI:P — a LAN user must be socially engineered into opening an RTSP stream to an attacker-controlled server. This is not a remotely scannable, zero-click vulnerability.
• Consumer-grade device, not enterprise infrastructure: The TL-WR940N v6 is a budget home router. Enterprise networks running 10,000 managed hosts do not deploy this device in any infrastructure role. It has no centralized management, no SNMP fleet support, and no place in a managed network.
• Role multiplier: The TL-WR940N v6 is exclusively a consumer SOHO router. It does not occupy any high-value enterprise role (not a DC, hypervisor, IdP, PAM, backup server, CI/CD, or network edge appliance in the enterprise sense). Even in the worst case — a forgotten branch-office router — compromise is limited to a single LAN segment with no lateral path to domain infrastructure. Blast radius: single network segment. This does not trigger the high-value-role floor.
• No PoC, no exploitation, no KEV: Zero public exploit code, EPSS at 0.8%, and no threat intelligence reporting. The friction of building a working MIPS ROP chain for this specific firmware without a PoC is non-trivial.
• Narrow hardware scope: Only TL-WR940N hardware revision v6 is affected — not v1-v5, not any other TP-Link model. This further restricts the vulnerable population.

Why not higher?

A HIGH or CRITICAL rating would require either active exploitation, a broader enterprise deployment footprint, or a zero-click remote attack vector. None of these conditions are met. The TL-WR940N v6 is a consumer device with no meaningful enterprise presence, the attack requires user interaction, and there is no public exploit or KEV listing. The blast radius is confined to a single LAN segment behind a home router.

Why not lower?

Despite the consumer-device context, this is still a kernel-level RCE on a network device that processes all traffic for its LAN. If an organization does have unmanaged TL-WR940N v6 units at remote worker homes or small branch offices, a compromise could enable traffic interception and DNS hijacking for all users on that segment. The lack of any security controls on the device (no ASLR, no stack canaries) makes exploitation reliable once an attacker invests in offset research. LOW would understate the impact for the small population that is actually affected.

1. Audit asset inventory for TL-WR940N v6 units — Search your CMDB, NAC logs, and DHCP fingerprinting for TL-WR940N devices. If you have zero, close this ticket. If you find units at branch offices or remote-worker homes, prioritize firmware updates within the noisgate 365-day remediation window.
2. Block outbound RTSP (TCP 554) at the perimeter — If your firewall or proxy does not already block outbound RTSP, add a deny rule. This eliminates the attack vector entirely by preventing LAN clients from reaching attacker-controlled RTSP servers. This is a permanent hardening measure regardless of this CVE.
3. Update affected routers to patched firmware — Flash the appropriate regional firmware: (US)_V6_260528, (EU)_V6_260528, or (JP)_V6_260527. For unmanaged consumer devices, this may require coordinating with remote workers. Target completion within the noisgate 365-day remediation window.
4. Replace consumer routers with managed equipment — Long-term, replace any TL-WR940N units with enterprise-managed access points or SD-WAN appliances that support centralized firmware management and security monitoring.

Run this from any Linux/macOS workstation that can reach the router's management interface (default 192.168.0.1). Requires curl and network access to the router's web UI. Pass the router IP as the first argument: bash check_wr940n.sh 192.168.0.1

#!/usr/bin/env bash
# check_wr940n.sh — Check TL-WR940N v6 firmware for CVE-2026-12935
# Usage: bash check_wr940n.sh <router_ip>
# Requires: curl, grep
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

ROUTER_IP="${1:-192.168.0.1}"
TIMEOUT=10

echo "[*] Checking TL-WR940N at ${ROUTER_IP} for CVE-2026-12935..."

# Attempt to pull firmware version from the router's status page
# TL-WR940N v6 exposes version info at the system status page
RESPONSE=$(curl -sk --max-time "${TIMEOUT}" "http://${ROUTER_IP}/" 2>/dev/null || true)

if [ -z "${RESPONSE}" ]; then
  echo "[!] Could not connect to router at ${ROUTER_IP}"
  echo "UNKNOWN"
  exit 2
fi

# Check if this is a TL-WR940N
if ! echo "${RESPONSE}" | grep -qi 'WR940N'; then
  echo "[!] Device at ${ROUTER_IP} does not appear to be a TL-WR940N"
  echo "UNKNOWN"
  exit 2
fi

# Try to extract firmware version string
# Common patterns: "3.18.1 Build 260528" or similar
FW_VERSION=$(echo "${RESPONSE}" | grep -oiE '[0-9]+\.[0-9]+\.[0-9]+ Build [0-9]+' | head -1 || true)

if [ -z "${FW_VERSION}" ]; then
  echo "[!] Could not extract firmware version. Check manually."
  echo "[!] Log into http://${ROUTER_IP} -> System Tools -> Firmware Upgrade"
  echo "UNKNOWN"
  exit 2
fi

echo "[*] Detected firmware: ${FW_VERSION}"

# Extract build date (YYMMDD format)
BUILD_DATE=$(echo "${FW_VERSION}" | grep -oE '[0-9]{6}$' || true)

if [ -z "${BUILD_DATE}" ]; then
  echo "[!] Could not parse build date from firmware version"
  echo "UNKNOWN"
  exit 2
fi

# Patched builds are 260527 (JP) or 260528 (US/EU) and later
if [ "${BUILD_DATE}" -ge 260527 ] 2>/dev/null; then
  echo "[+] Firmware build ${BUILD_DATE} is at or above patched version (260527/260528)"
  echo "PATCHED"
  exit 0
else
  echo "[-] Firmware build ${BUILD_DATE} is BELOW patched version (260527/260528)"
  echo "VULNERABLE"
  exit 1
fi

Sources

1. TP-Link Security Advisory for CVE-2026-12935
2. THREATINT CVE-2026-12935 Record
3. TP-Link Product Security Advisories
4. TP-Link TL-WR940N v6 Firmware Downloads
5. VulnCheck Initial Access — TL-WR940N Research
6. CVE Details — TL-WR940N Firmware
7. NVD — CVE-2025-6151 (related TL-WR940N buffer overflow)