TP-Link has fixed an unauthenticated remote-code-execution flaw in TL-WR940N hardware revision 6. Owners of that revision are affected when the router runs firmware older than the regional fixed build: V6_260528 for English and US devices, or V6_260527 for Japan.
The entry path is unusual. An attacker does not begin by signing in to the router or sending a request to its management page. A device on the LAN connects to a malicious Real Time Streaming Protocol server, and the server sends back a crafted RTSP message. The router’s connection-tracking module inspects that reply in the kernel, where improper memory handling can produce a stack buffer overflow, a crash, or code execution that compromises the router.
The hostile input arrives inside a permitted session
RTSP supports setup and control of streamed media. Like other connection-tracking helpers, the router’s RTSP module examines application-layer traffic so it can understand related network flows. That inspection makes the router more than a passive forwarder: it parses a server response even though the conversation began with an outbound connection from a LAN client.
According to TP-Link, CVE-2026-12935 is triggered when a LAN client initiates a connection to an attacker-controlled RTSP server. The server returns a specially crafted message, and the router’s RTSP conntrack module handles it incorrectly. The resulting stack-based buffer overflow occurs in a kernel module, not in the client application that opened the stream.
That distinction changes the exposure model. Blocking unsolicited inbound management traffic does not close this path. The attacker needs a client behind the router to connect to the malicious server, which the CVSS vector records as user interaction, but the attacker needs no router account. A link, media application, embedded device, or other client behavior could supply the outbound leg; TP-Link’s public advisory does not specify the delivery method.
Figure details
A LAN client starts an outbound RTSP session to an attacker-controlled server. The server sends a crafted RTSP reply through the established flow. The TL-WR940N v6 router's RTSP connection-tracking module parses the reply in the kernel, where a stack buffer overflow can crash the device or permit code execution. Defenders close the exposure by verifying hardware revision 6 runs regional firmware EN or US V6_260528, or JP V6_260527, and by resolving any suspicious RTSP session followed by a router failure.
Code execution is possible, but exploitation is not confirmed
TP-Link rates the vulnerability 8.7 under CVSS 4.0 and says successful exploitation may cause denial of service or remote code execution, potentially resulting in full device compromise. The score’s PR:N element reflects that no privilege is required, while UI:P captures the need for a client to participate by starting the connection.
The advisory does not say that attackers are exploiting CVE-2026-12935 in the wild. It also does not provide a proof of concept, a byte-level signature, a named malicious server, or a post-exploitation artifact. Treat remote code execution as a vendor-confirmed impact, not as evidence that every crash or RTSP session represents compromise.
The affected scope is similarly precise. TP-Link names the TL-WR940N v6, not every router sold under the TL-WR940N name and not every TP-Link product with an RTSP helper. Hardware revision matters because firmware for another revision is not an interchangeable fix.
Inventory the chassis before trusting the firmware list
Start with the physical label or the router’s administration interface and record the exact model, hardware revision, region, and running firmware. Prioritize units labeled TL-WR940N Ver: 6.x. Do not infer revision from the product name alone, and do not install firmware intended for a different region or hardware release.
For revision 6, compare the running build with TP-Link’s fixed entry for that region. The advisory lists (EN)_V6_260528, (US)_V6_260528, and (JP)_V6_260527. Download firmware through the regional TP-Link support route linked by the advisory, apply it using the vendor’s instructions, then reconnect to the management interface and verify the running build rather than relying on the installer or a completed upload message.
If an immediate update is impossible, reduce exposure by controlling which clients can reach untrusted RTSP services and by segmenting cameras, media devices, and other systems that initiate streaming sessions. Network controls are containment, not a substitute for the fixed firmware: RTSP can be carried in ways that a simple port-only rule may miss, and the vendor does not present a configuration workaround as equivalent to its update.
Correlate RTSP traffic with router failure
Preserve router logs, firewall records, DNS history, flow telemetry, packet captures, DHCP assignments, and endpoint telemetry covering the vulnerable period before rebooting or updating where incident response permits. Search for LAN clients opening unexplained external RTSP sessions, commonly associated with TCP port 554, then correlate those sessions with an unexpected router restart, loss of forwarding, configuration change, or new outbound behavior from the router’s address.
Port 554 alone is neither required proof nor a reliable clearance condition. The vendor describes the protocol and crafted reply, not a universal destination port or signature. Where full packets are available, retain both directions of the session for analysis. Where only flow logs exist, document that the triggering server response cannot be reconstructed.
After a suspicious crash or unexplained configuration change, assume that installing fixed firmware cannot prove the earlier device state was clean. Reset or rebuild the router using trusted vendor firmware, restore only reviewed configuration, replace administrative credentials, verify DNS and remote-management settings, and inspect downstream clients for the behavior that initiated the session. Review exposure of credentials or traffic that crossed the router during the uncertain period.
Close on hardware, build, and an explained exposure window
Resolve the vulnerability task after every TL-WR940N is mapped to a hardware revision and region, every revision 6 unit reports the correct fixed build or has been retired, and unsupported or unreachable devices are accounted for. Resolve an incident investigation after suspicious RTSP sessions, router failures, configuration drift, and unexpected router-originated traffic have been resolved.
If telemetry does not cover the vulnerable interval, state that gap directly. A clean current configuration does not reconstruct an unlogged kernel crash. The defensible closing record is an exact hardware-and-firmware inventory, a verified running build, reviewed router configuration and credentials, and either sufficient network evidence to explain the exposure window or an explicit decision to rebuild and treat that history as uncertain.