An attacker sending a malformed HTTP POST request over LAN to a TP-Link Smart camera device can trigger the vulnerability described here.
This report describes a stack buffer overflow, which leads to denial of service and may potentially lead to remote code execution.
The vulnerability we are disclosing in this advisory affected a wide range of TP-Link devices, including TAPO Smart Cameras. A TP-Link Security Advisory released in April 2026 contains this vulnerability as CVE-2026-34124.
Vulnerability Details
We identified a stack buffer overflow vulnerability in the way te HTTP server of TAPO devices handles GET requests.
http_parser() {
path = ...; // points into the raw HTTP request line, with the first '?' or ' ' zeroed
path_len = strlen(path);
if (path_len >= 80) { // [1]
// ... bail out, HTTP 414
}
ret = realpath(path, context->path); // [2]
if (ret == NULL) {
strcpy(context->path,boundary);
}
}
The size of the context->path buffer is 80 bytes, and the implementation makes sure that the incoming path is no longer than that at [1].
However, realpath, when called at [2] can write more than that, for example when it expands a symbolic link.
The following request triggers this bug, for example:
curl -k -vv --path-as-is https://${HOST}/sys/class/mmc_host/mmc0/mmc0:0001/block/mmcblk0/queue/write_same_max_bytes
This path resolves to /sys/devices/platform/f0420000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/queue/write_same_max_bytes, which is 101 bytes long, instead of the 75 characters in the request.
Since attacker control over the byte values written is restricted in this case, the impact conservatively is classified as denial of service. Of course, many other expandable paths that satisfy the overflow length requirement may exist, so higher impact exploitability may also be possible.
Affected Devices
- verified: TAPO C520WS
- potentially: TP-Link smart devices using the TAPO architecture
Timeline
- 2025.12.12. Vulnerability reported to TP-Link PSIRT by email.
- 2026.02.04. TP-Link acknowledges the report.
- 2026.03.04. TP-Link states that they were unable to reproduce the issue and asks for more information.
- 2026.03.04. TASZK provides update explaining the errors in TP-Link’s triage and how to trigger the vulnerability correctly. TASZK also explains that DoS might not be the maximum impact and more detailed triage is advisable.
- 2026.03.05. TP-Link asks for a 3 week extension, does not confirm any TASZK analysis, does not provide any explanation (or evidence of any analyis) of the determined impact.
- 2026.03.06. TASZK confirms that a 3 week extension will be granted for vulnerabilities where a CVE assignment and/or Advisory correction will happen.
- 2026.03.20. TP-Link communicates that this vulnerability (along with some reported at the time) has been fixed and wishes TASZK to provide a black box analysis of a new firmware image. TP-Link does not confirm which submitted vulnerabilities will receive a CVE and/or Advisory correction but ask for another arbitrary extension for only 1 vulnerability.
- 2026.03.23. TASZK confirms that the 3 week extension will be granted if the list of vulnerabilities that are receiving a CVE and/or Advisory correction will be shared, otherwise no other extension will be granted.
- 2026.03.26-04.01. TP-Link attempts to get in touch via several non-official channels, including an attempt to show up at our offices in person uninvited. TP-Link requests additional delay for different vulnerabilities.
- 2026.04.02. End date of original 90 day + 3 week embargo. TASZK highlights that the PSIRT keeps sending plaintext emails with sensitive vulnerability information, points out that non-PSIRT channels are considered out-of-bounds for coordinated disclosure and confirms that embargo windows will not be extended further. TASZK volunteers a 24h notice to TP-Link for advisory release.
- 2026.04.02. TP-Link releases advisory for the vulnerability: https://www.tp-link.com/us/support/faq/5047/
- 2026.04.06. TASZK communicates notice of release to TP-Link.
- 2026.04.28. Advisory released.