SecMate found four vulnerabilities in arduino-tuyaopen [2], Tuya’s Arduino framework for connected devices. The issues affect DNS parsing, Tuya Data Point handling, Wi-Fi credential storage, and UDP packet reception: CVE-2026-28519, CVE-2026-28521, CVE-2026-28520, and CVE-2026-28522.

The bugs are in reusable framework libraries. They do not form one exploit chain, and the evidence does not support a claim that every TuyaOpen device is affected.

All four issues were fixed in commit 54ac201 on February 25, 2026 [6]. The fixes later shipped in the 1.2.1 release line [8].

Vulnerability Map

Affected Code and Use Cases

The vulnerable implementations referenced in this post are from public repository code around commit eaec2c903e2e629f9c53da789c39e12ea226d0b2 [2]. Public history places the affected paths between August and November 2024, with fixes landing on February 25, 2026 [3] [4] [5] [6].

arduino-tuyaopen ships as an Arduino board package for targets including t2, t3, t5, ln882h, and esp32 [2]. The relevant libraries are used for captive-portal DNS handling, UDP packet reception, Wi-Fi connection fallback, and Tuya cloud DP processing.

At a reachability level, the DNS and UDP issues are adjacent-network issues: the attacker must be on the same LAN or AP-side network path as the device. The WiFiMulti issue is a local Wi-Fi/provisioning issue: the device must consume attacker-controlled AP or Wi-Fi credential data. The TuyaIoT DP issue is a device-control-path issue: attacker-controlled DP event data must reach the device through the Tuya cloud path.

A product does not inherit all four attack paths by default. Exposure depends on whether the affected library is present in the firmware and connected to the corresponding attacker-controlled input.

Recommendations

• Update arduino-tuyaopen to the 1.2.1 release line or later, or to a commit containing 54ac201.
• If TuyaOpen libraries were vendored into firmware, check whether the February 25, 2026 fixes are present.
• If firmware exposes captive-portal DNS handling, reject malformed or oversized QNAME inputs before copying into fixed buffers.
• If firmware uses WiFiUDP, test receive paths under allocation failure and low-memory conditions.
• Treat Wi-Fi provisioning data and Tuya DP indexes as untrusted unless the application enforces bounds before calling framework helpers.

Timeline

Takeaway

The common issue is not Tuya cloud. It is memory safety in reusable firmware framework code. DNS helpers, UDP receive paths, Wi-Fi provisioning helpers, and cloud-event accessors often become part of product firmware.

The highest-confidence impacts are same-network memory corruption where the DNS helper is exposed, denial of service in UDP receive paths under low-memory conditions, and memory-safety failures in helper APIs that downstream firmware may treat as safe building blocks.

For the full list of our disclosures, see our disclosure page at secmate.dev/disclosures.

References

• [1] Tuya. “Tuya Developer Platform.” Documentation

• [2] Tuya. “arduino-tuyaopen repository.” Repository

• [3] Tuya. “add ble&wifi libraries (b6d68ec, August 6, 2024).” Commit

• [4] Tuya. “add http mqtt (89be820, November 21, 2024).” Commit

• [5] Tuya. “Update TuyaIoT libraries (53bf5bc, August 27, 2024).” Commit

• [6] Tuya. “Fix security issues (54ac201, February 25, 2026).” Commit

• [7] Tuya SRC. “Announcement 32.” Announcement page

• [8] Tuya. “1.2.0 to 1.2.1 comparison.” Repository diff

The SecMate Team