CVE-2021-3577

What it actually does

This vulnerability allows an unauthenticated attacker with adjacent network access to execute code on affected Motorola-branded Binatone Hubble camera devices. The flaw is categorized as an authorization bypass: the device exposes functionality that should require authentication or authorization, but an attacker on the same local network can reach it directly and trigger code execution. Successful exploitation can give the attacker control over the camera firmware/runtime environment, enabling access to video/audio streams, configuration data, credentials stored on the device, and the ability to modify or disrupt device operation.

Why it matters to the business

Compromise of affected cameras can lead to unauthorized viewing or recording, loss of privacy, device outages, and use of cameras as footholds for broader attacks inside the local network. Because exploitation is weaponized and the EPSS score is elevated, exposed devices on shared, guest, consumer, or poorly segmented networks should be treated as high priority even though the issue is not currently listed in CISA KEV. Organizations using these devices in offices, care facilities, retail locations, or home-office environments may face privacy, safety, compliance, and reputational consequences if cameras are accessed or manipulated.

How an attack unfolds

An attacker first gains access to the same network segment as an affected camera, such as through Wi-Fi access, a compromised device, guest network abuse, or physical proximity to the local network. The attacker discovers Binatone/Motorola Hubble camera devices using network scanning or service discovery, then sends crafted unauthenticated requests to the vulnerable service exposed by the camera firmware. Because the vulnerable functionality does not properly enforce authorization, the device processes the request and executes attacker-controlled commands or code. After execution, the attacker may establish persistence where possible, retrieve camera configuration and credentials, access live streams, pivot to other internal targets, or add the device to an IoT botnet for scanning, proxying, or denial-of-service activity.

How to fix it

Upgrade affected camera firmware to a vendor-fixed release where available through the official Motorola/Binatone/Hubble update mechanism. The provided advisory data does not include exact fixed version numbers, so administrators should verify current firmware against the vendor’s support portal or management application and apply the latest available firmware for each affected model: Halo+, Comfort 85 Connect, MBP3855, Focus 68, Focus 72R, CN28, CN50, Comfort 40, Comfort 50 Connect, MBP4855, MBP3667, MBP669 Connect, and Lux 64. If fixed firmware is unavailable or the device is end-of-life, remove the device from production use or isolate it on a dedicated network/VLAN with no access to sensitive systems. Restrict camera access to trusted management stations only, disable UPnP and unnecessary remote-access features, block inbound access from untrusted networks, rotate any associated account and Wi-Fi credentials, and ensure the camera is not reachable from guest networks or the internet.

How to confirm the fix worked

Confirm that every affected camera model is inventoried and running the latest vendor-provided firmware. Validate exposure by scanning local network segments for the affected models and confirming that camera management or media services are not reachable from guest, user, or untrusted VLANs. Attempt access only through documented authenticated interfaces and verify unauthenticated requests cannot invoke administrative or command-execution behavior. Review firewall, wireless, and NAC policies to confirm the cameras are isolated. Where possible, perform a credentialed device configuration review to verify remote access, UPnP, default credentials, and unnecessary services are disabled.

Typical attack path

1. Obtain access to the same local or wireless network as the vulnerable camera.
2. Scan the local subnet for affected Motorola/Binatone Hubble camera models or open embedded-device services.
3. Fingerprint the device firmware/model to confirm it matches an affected product family such as Halo+, Comfort, Focus, CN, MBP, or Lux camera lines.
4. Send a crafted unauthenticated request to the vulnerable camera service to bypass authorization and trigger code execution.
5. Run commands on the embedded device to enumerate files, network settings, credentials, and camera configuration.
6. Optionally download a payload using common embedded Linux utilities such as wget, curl, tftp, or busybox.
7. Maintain access, monitor video/audio streams, disrupt the camera, or use the camera as a pivot point into the local network.

How to detect it

Look for evidence that an attacker reached the camera from an untrusted local-network source and caused it to execute commands or download payloads. Useful sources include DHCP lease logs, wireless association logs, router/firewall logs, DNS logs, NAT logs, IDS/IPS telemetry, IoT network monitoring, and any camera management or syslog output if enabled. Hunt for unusual inbound connections to camera IP addresses from guest Wi-Fi clients, unmanaged endpoints, or devices that do not normally administer cameras. Review outbound connections from cameras to unfamiliar external IPs or domains, especially HTTP, HTTPS, FTP, TFTP, Telnet, SSH, IRC, or high-numbered ports. Check for signs of embedded Linux payload staging such as use of wget, curl, tftp, busybox, chmod, or execution from /tmp, /var/tmp, /dev/shm, or similar writable directories. Investigate camera-initiated scanning of RFC1918 address space, repeated connection attempts to many internal hosts, unexpected DNS queries, sudden traffic spikes, unexplained reboots, configuration changes, password resets, or unknown processes. Because this is an adjacent-network vulnerability, correlate suspicious camera activity with wireless access events, guest network use, rogue access points, and recently connected unmanaged devices.

• wget http://
• curl http://
• tftp -g
• busybox wget
• busybox nc
• chmod +x /tmp/
• /tmp/
• /var/tmp/
• /dev/shm/
• /bin/sh -c
• /bin/busybox
• telnetd
• dropbear
• nc -l
• /etc/init.d/
• Hubble
• Binatone
• Motorola
• Halo+
• Comfort 85 Connect
• Focus 68
• Focus 72R
• CN28
• CN50
• Comfort 40
• Comfort 50 Connect
• MBP3855
• MBP4855
• MBP3667
• MBP669 Connect
• Lux 64

What your security team should do

• Immediately inventory all Motorola/Binatone Hubble camera models across corporate, branch, lab, retail, and home-office networks.
• Prioritize remediation for cameras on shared Wi-Fi, guest networks, flat LANs, or locations where untrusted users can gain local network access.
• Apply the latest vendor firmware or replace devices where no fixed firmware is available.
• Segment cameras onto an isolated IoT network with strict egress controls and no direct access to sensitive internal systems.
• Block internet exposure and disable UPnP or automatic port-forwarding on networks hosting these cameras.
• Rotate Hubble account credentials, local device credentials, and Wi-Fi credentials if compromise is suspected.
• Monitor for unusual outbound connections from cameras, especially downloads of binaries, connections to unknown external IPs, or scanning of internal subnets.
• Review DHCP, DNS, firewall, wireless controller, and router logs for historical signs of camera compromise.
• Treat unexpected reboots, configuration changes, unknown firmware behavior, or high outbound traffic from a camera as potential compromise indicators.
• If exploitation is suspected, isolate the device, preserve logs where available, capture network traffic, factory reset or reflash firmware, and replace the device if trust cannot be restored.