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 malformed allocation length vulnerability which leads to denial of service.

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-2025-14299.

Vulnerability Details

This vulnerability is very similar to CVE-2025-0918, it is found in the same logic in the same function.

In the HTTP Server implementation of TAPO devices, the http_recv_block function (in the main binary) is used to retrieve HTTP packets from the network into memory. It accepts a pointer to a buffer and the size of said buffer as parameters, and copies the HTTP content into this buffer. This function is called on multiple occasions in the HTTP parser subsystem.

int http_recv_block(httpd_context* context, void* buf, size_t buflen) {
  int err;
  
  if (context->is_https == 1) {
    // ...
    while (err = tpssl_read(context->ssl_handle, buf, buflen), err < 1) {
      // Error handling
    }
  } else {
    err = recv(context->sockfd, buf, buflen, 0);
    // Error handling
  }
  
  return err;
}

One case is in http_read_content. This function is responsible for handling the first bytes of the content. Because the HTTP protocol dictates that the headers are in a line-by-line format, the full length of the headers cannot be known in advance. Thus, due to the required buffering, this part of the parser might have read into the content, and this case must be handled appropriately.

The content is originally stored in the context->main_buffer of 0x1000 bytes, and the region between context->buffered_data_start and context->buffered_data_end are the bytes that were already received, but not yet parsed.

The expected content length is already communicated in HTTP, so the application must process exactly content_len bytes. If this main_buffer is too small to contain both the headers and the content, a new buffer is allocated (content_buf/content_buffer). Both main_buffer and content_buf size are defined by a pointer to the end of the buffer (main_buffer_end/content_buffer_end).

http_read_content() {
  if (content_len >= (int)context->main_buffer_end - (int)buffered_data_start) {
    begin = (char *)malloc(content_len + 1);
    ...
  }
}

In the allocation in http_read_content, in case the Content-Length field requires a larger size than the current buffer has, if the attacker provides an overly large value, which cannot be allocated in memory, the malloc fails and returns a null pointer. This leads to an assertion later in the control flow, because context->content_buf gets set to 0.

A crashing PoC is as simple as:

curl -k 'https://192.168.100.2' -X POST -H 'Content-Length: 2000000000'

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 states that the vulnerability is a duplicate and has been fixed.
• 2026.02.11. TASZK asks for the matching CVEs.
• 2026.03.04. TP-Link confirms vulnerability as CVE-2025-0918. This is inaccurate, the correct CVE is CVE-2025-14299 (https://www.tp-link.com/us/support/faq/4849/).
• 2026.04.06. TASZK communicates notice of release to TP-Link.
• 2026.04.28. Advisory released.