Naxclow IoT Devices CVE-2026-50101

Attacker must first obtain the per-device server-side relay credential through some exposure path - examples implied by the description include intercepting it during device boot (when it is re-issued from the server), extracting it from device firmware/storage, or capturing it from a backend leak; the CVE itself does not specify the acquisition channel. Once obtained, no further conditions apply: the credential is valid indefinitely, requires no user interaction, no authentication on the victim's account, and is unaffected by factory reset or re-onboarding. Limiting factors are therefore primarily the difficulty of initial credential acquisition (reflected as AC:H) rather than any per-victim configuration; affected devices are Naxclow Smart Doorbell X3, X Smart Home, V720, and ix Cam in any firmware version.

The CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H) yields 9.2, but AC:H reflects a real precondition: the attacker must first obtain the credential through some 'exposure path' (firmware extraction, MITM during onboarding, cloud-side leak, supply-chain interception). Once obtained, however, exploitation is trivial, persistent, and survives every defensive action a victim can take - which is the dimension raw CVSS understates. No EPSS score, KEV listing, or POC indicator is included in the supplied intelligence, so probabilistic exploitation risk is unknown; this should be treated as a design-level supply-chain trust issue rather than a mass-exploitation bug. ICS-CERT (CISA) coordination via ICSA-26-162-02 signals this is a vendor-acknowledged systemic issue rather than a speculative finding.

An attacker who obtained a relay credential during a prior network compromise, firmware analysis of a discarded unit, or interception of cloud traffic can replay that credential to the Naxclow relay service from anywhere on the internet, registering as the legitimate device and silently streaming video, capturing audio, or injecting frames toward the owner's app. The victim sees the device functioning normally and has no UI affordance to invalidate the credential - even returning the doorbell to factory state and re-pairing it leaves the attacker's foothold intact. No public exploit code is identified, but the technique requires only a standard relay client once the credential is in hand.