Anyone on the Internet Can Ring Your Doorbell

Published 2026‑05‑06 – 39 min read

---

Thesis

The Smart Doorbell X3, marketed on Temu and backed by the Naxclow platform, is not a single vulnerable gadget but a platform‑wide failure of authentication, key management, and secure onboarding. By chaining together a handful of predictable identifiers, a hard‑coded signing secret, and plaintext credential exposure, an attacker can silently steal any device, impersonate it in live video calls, and harvest the homeowner’s Wi‑Fi keys with only a screwdriver and a UART adapter.

---

Key Findings

1. Platform‑wide silent takeover (Critical)

• Two signed HTTP POSTs—confirm and bind—are sufficient to reassign any doorbell to an attacker’s account.
• The backend never verifies that the request originates from the current owner or from the device itself.
• Because device IDs are sequential (1e2023XXXXXX) and the signature algorithm uses a static secret, an attacker can enumerate the entire fleet and hijack each unit in minutes.

2. One‑shot credential lift (Critical)

• A signed request to the signaling‑config endpoint returns the device’s permanent relay password (devToken).
• No additional authentication is required; the server trusts only the forged SHA‑1 signature.
• Possession of this token lets an attacker register on the relay as the target device, effectively becoming the doorbell.

3. Live impersonation of a doorbell (Critical)

• With the leaked devToken, an attacker can:
  1. Register on the relay as the victim device.
  2. Send a forged “doorbell pressed” alert, causing the owner’s phone to ring.
  3. Answer the call and stream arbitrary MJPEG video and two‑way audio.
• The real doorbell stays online and never knows it has been replaced.

4. Persistent per‑device passwords (Critical)

• devToken and the account‑side cliToken are stored server‑side and never rotate, even after factory reset or rebinding.
• Once lifted, they remain valid for the lifetime of the device record, rendering any later patch ineffective.

5. Wi‑Fi credentials leak via UART (High)

• During boot the firmware prints the home SSID, PSK, and derived WPA keys to the UART console.
• The UART header is exposed on the front panel; gaining access requires only a screwdriver and a few seconds of patience.
• This single foothold grants full LAN compromise.

6. Unencrypted media and signaling (High)

• The P2P video/audio stream is sent in clear MJPEG and PCM packets after NAT hole‑punching.
• Call‑setup messages expose device ID, account ID, public/private IPs, NAT ports, and both long‑lived tokens in plaintext.
• Anyone on the path can capture live video/audio without breaking encryption.

7. Predictable device identifiers (High)

• Device IDs follow the pattern 1e2023XXXXXX where 1e is a locally administered MAC prefix, 2023 is a batch tag, and the final six hex digits are a simple counter.
• The enumeration space is trivially searchable, enabling fleet‑wide attacks.

8. Unauthenticated device‑code minting (High)

• A signed request with a known batch prefix returns the next free sequential ID.
• The minted ID is not bound to the requesting account until a separate bind step, allowing attackers to grow the namespace at will.

9. Unauthenticated alert delivery (Medium)

• The alert endpoint accepts a device ID, an image, and a forged signature. No further checks are performed.
• An attacker can ring any owner’s phone with a custom image, effectively spoofing a visitor.

10. Hard‑coded signing salt (Medium)

• The signature is a truncated SHA‑1 over alphabetically‑sorted parameters plus a constant string (sercret).
• The same constant appears on every device; once recovered, it enables forging of any request on the platform.

11. Plain HTTP control plane (Medium)

• All control‑plane traffic (device‑to‑backend alerts, token fetches) uses HTTP on port 80, even though the same host serves TLS on 443.
• No TLS termination on the device side means traffic can be intercepted or modified trivially.

12. Verbose UART debug shell (Medium)

• The production firmware drops into an interactive RT‑Thread shell exposing commands such as device_code, write_device_code, fal read, and printenv.
• These commands allow arbitrary flash reads, firmware dumping, and even overwriting the device’s identity without authentication.

---

Implications

1. User privacy is shattered – An attacker can watch the front door and converse with the homeowner while pretending to be a visitor.
2. Physical security is compromised – By reassigning a doorbell, the attacker can silence the real device, preventing the homeowner from receiving legitimate alerts.
3. Network security collapses – The UART‑exposed Wi‑Fi keys give immediate LAN access, turning a single IoT device into a gateway for ransomware, credential theft, or lateral movement.
4. Vendor remediation is nearly impossible – The firmware lacks an OTA partition; even if Naxclow released a patched image, existing units cannot receive it over the air. A hardware recall would be the only reliable fix.
5. Scale of impact – Because the same firmware and backend serve multiple rebadged brands, the vulnerability likely affects dozens of listings on Temu and possibly other Chinese marketplaces.

---

Counter‑Perspectives & Mitigation Paths

Issue	Practical Mitigation
Static signing secret	Rotate the secret server‑side and embed a per‑device secret during manufacturing. Use HMAC‑SHA256 with a device‑unique key stored in secure flash.
Plaintext tokens	Issue short‑lived session tokens that are refreshed on each call and bind them to a TLS‑protected channel.
UART debug exposure	Remove the debug console from production firmware or lock it behind a password protected bootloader. Disable JTAG/UART pins in the final silicon package.
Unencrypted media	Enforce SRTP or DTLS for the P2P leg; at minimum encrypt the video payload with a key derived from the per‑session handshake.
Predictable IDs	Use a true random 128‑bit UUID for each device; do not expose the generation counter.
OTA partition missing	Add a dedicated download partition and a secure bootloader that verifies signed images before flashing.
HTTP control plane	Switch all device‑to‑backend communication to HTTPS with certificate pinning.
Unauthenticated bind/confirm	Require the current owner’s token (or a proof‑of‑possession challenge) before allowing a device to be rebound.

Even with these patches, the existing deployed fleet remains vulnerable because the hardware cannot receive OTA updates. Users should isolate such devices on a guest VLAN, disable any local network access beyond the internet, and consider replacing them with hardware that supports secure OTA and encrypted media.

---

Disclosure Timeline

• 2026‑04‑01 – Initial lab testing on owned units.
• 2026‑04‑29 – Coordinated disclosure sent to Naxclow via discovered email addresses and the in‑app feedback form.
• 2026‑05‑06 – Publication of this sanitized report after one week with no substantive response.
• 2026‑05‑07 – Naxclow acknowledged the report and opened an internal review (see email in the image above).

---

Takeaways for Practitioners

1. Treat every UART header as a backdoor – Even cheap MCUs expose full memory when a console is left enabled.
2. Never trust a static “signature” – If the secret is baked into firmware, the whole protocol collapses to an integrity check, not authentication.
3. Per‑device credentials must rotate – Long‑lived passwords that survive factory reset are a recipe for perpetual compromise.
4. Encrypt everything that traverses the internet – Plain HTTP, clear‑text media, and exposed STUN parameters give attackers a free data stream.
5. Vendor‑side OTA is not optional – Without a path to push fixes, any discovered flaw becomes a permanent field‑wide risk.

---

Final Thoughts

The Smart Doorbell X3 illustrates how a single insecure design decision—a hard‑coded signing salt—can cascade into a suite of systemic failures when combined with poor key management, exposed debug interfaces, and an unauthenticated onboarding flow. The result is a platform where anyone on the internet can ring, hijack, or silently steal a front‑door camera. Until the vendor either recalls the hardware or provides a secure OTA mechanism, the safest advice remains: segregate, monitor, and replace.

---

For the full technical dump, firmware extraction scripts, and a proof‑of‑concept client, please contact me through the coordinated disclosure channel.