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 heap buffer overflow, which leads 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-34119.

Vulnerability Details

another overflow similar to CVE-2026-34118 was present within the main HTTP parser function. This vulnerability can be triggered when more than one receive is required to read the full contents of the body.

As described in the advisory for CVE-2026-34118, due to how HTTP works, the HTTP body/content might be received with the HTTP headers, because of the use of buffering. In this context, this means 0 requests to read the full contents of the body.

In contrast, one request is required, if a single additional request (in addition to the headers) is enough to receive the content_length bytes.

Finally, if more than one is required, the check at [1] is reached:

content_len = context->content_len;
if (content_len == 0) {
  context->content_parse_err = 1;
  return 0;
}
  /* Check if we fit inside the rest of the bytes */
begin = context->buffered_data_start;
context->content_parse_err = 0;
if (content_len < (int)context->main_buffer_end - (int)begin) {
  new_currptr = context->buffered_data_end;
  // ...
  // (set context fields)
}
else {
  /* Allocate new memory, because we do not fit into the range
     buffered_data_start ... end of the buffer */
  begin = (char *)malloc(content_len + 1);
  new_currptr = begin + ...;
  // ...
  // (memcpy already buffered contents)
  // (set context fields)
}
remaining_to_read = begin + (content_len - (int)new_currptr);
if ((int)remaining_to_read > 0) {
  bytes_read = http_recv_block(context,new_currptr,0x1000);
  ...
}
if (context->boundary != (char *)0x0) { // [1]
  // ...
  // (might pass through)
}
err = http__read_all_vulnerable(context); // [2]
// ... error handling

Depending on [1] (whether a multipart MIME was defined with a boundary string), after the first read for the content, we can reach either [2]. Both are vulnerable to a very similar issue:

undefined4 http__read_all_vulnerable(httpd_context *context)
{
  start_uptime = get_sys_uptime();
  content_len = context->parsed_content_len;
  bytes_remaining = (context->startptr + content_len) - context->startptr;
  while( true ) {
    if ((int)bytes_remaining < 1) {
      return 0;
    }
    bytes_read = http_recv_block(context,write_head,0x1000); // [4]
    // error handling; also overlong reads are bailed out
    uptime = get_sys_uptime();
    if (89 < uptime - start_uptime) break;
    write_head = context->endptr;
    if (bytes_read == 0) {
      content_len = (uint)context->startptr;
      content_len = (uint)(write_head + -content_len);
      context->parsed_content_len = content_len;
    }
    context->endptr = write_head + bytes_read;
    write_head[bytes_read] = '\0';
    write_head = context->endptr;
    bytes_remaining = (context->startptr + content_len) - context->startptr;
  }
  return 0xfffffffe;
}

Similarly to CVE-2026-34118, the content_len is fully user-controlled, so the recv at [4] reads at most 0x1000 bytes, depending on how much data is available within the kernel’s recv buffer at that moment. This can be controlled by controlling how the packet contents are chunked into TCP packets (or TLS packets), and introducing small delays to ensure that at different points in time, the buffer contains what the attacker expects, and hence the recv returns exactly as many bytes as needed.

The socket is blocking, and this means that the device waits for more content, and single packets can be sent with small delays, which will be processed with fully controlled data lengths. This would not be trivial if the socket was non-blocking.

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 and asks for extended PoC.
2026.02.11. TASZK responds with sending extended copy-paste PoCs and highlights that sufficient reproduction information was already contained in the original submission.
2026.03.04. TP-Link confirms vulnerability and asks for time extension. TP-Link also provides erroneous analysis for several other reported vulnerabilities.
2026.03.04. TASZK provides update explaining the errors in TP-Link’s assessment regarding other reported vulnerabilities, describing which CVE assignment and advisory detail assessments are incorrect.
2026.03.05. TP-Link again asks for a 3 week extension, does not confirm any TASZK analysis.
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) have 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.

CVE-2026-34119: TP-Link HTTP POST body heap buffer overflow

Vulnerability Details

Affected Devices

Timeline