A PS5 gamepad, Claude AI and a romo vacuum — and suddenly 7,000 cameras were live

Controlling a vacuum with a gamepad uncovered a backend bug that briefly exposed thousands of DJI Romos

Sammy Azdoufal set out to do something harmless and oddly charming: drive his new DJI Romo robot vacuum with a PS5 DualSense. Instead, a few lines of AI-assisted network analysis turned that personal project into an accidental global privacy discovery – he found a backend permission validation bug that gave access to telemetry, camera feeds, microphones, 2D floor plans and rough locations for more than 7,000 DJI Romo units across multiple countries.

• What happened: An experiment to control a Romo with a DualSense led Sammy to use Claude Code to parse MQTT traffic. The authentication token he extracted worked beyond his device.
• Immediate result: DJI pushed a patch for affected devices within days after being notified, admitting an MQTT permission validation issue that “allowed theoretical potential for unauthorized access to live video of ROMO device.”
• The uncomfortable bit: microphones and cameras on a vacuum – and server-side permissions that make one token too powerful – mean a single mistake exposes whole fleets, not just one gadget.

Why this matters more than a hacker prank

We live in an era when cheap cameras, microphones and network stacks are stuffing mundane appliances with the same telemetry that used to be limited to phones and laptops. That’s useful when a device genuinely needs spatial awareness — but it’s also a one-fault-to-many risk if the server-side access controls aren’t airtight. Azdoufal didn’t break any firmware on the Romo; he interrogated the cloud interaction. Back-end permission validation is a boring line in an engineering spec until it isn’t.

Two things make this worse than a lone misguided bug. First, the vulnerability used MQTT, a lightweight protocol designed for IoT messaging. If the server accepts an overly permissive token, every device speaking that same broker can be enumerated and probed. Second, Azdoufal used Claude Code — an AI-assisted toolchain — to automate token discovery and traffic inspection. That makes this vulnerability trivially scalable for anyone with modest skill and the right prompts.

The PR line and the part they hope you don’t repeat aloud

DJI moved — within days — and issued a patch to the affected vacuums, and the company told reporters the hole was a “backend permission validation issue affecting MQTT-based communication between the device and the server” that could, in theory, allow unauthorized access to live video. That’s accurate and sobering. But there are two things the PR glosses over.

• Scope uncertainty: DJI says it patched affected devices, but the researcher says some vulnerabilities remain unaddressed and DJI promises more fixes “within weeks.” That gap — between patch and full remediation — is where opportunists operate.
• Data stewardship: The company hasn’t publicly detailed whether any of the accessed footage or logs were stored, exfiltrated or reviewed. An admission of “theoretical potential” doesn’t tell owners whether their homes were recorded or copied.

The broader pattern: robovacs and privacy have a history

This isn’t novel. In 2024, flaws in Ecovacs vacuums let attackers access cameras, harass owners and weaponize voice features. The pattern repeats: convenience features (cameras, mics, home mapping) ship before adversarial thinking is finished. The result is the same — a product designed for tidy floors becomes a surveillance vector for tidy homes.

The question nobody in the press release is answering

Why does a robot vacuum need a continuously accessible microphone and camera feed that the cloud can wake and route? If the answer is “for remote diagnostics and mapping,” then lock down the endpoints: issue narrowly scoped tokens, rotate credentials, require per-device attestation. If the answer is “for features,” remove the feature until it can be implemented securely. That’s the operational trade-off DJI is dodging in public statements.

What to watch

• DJI’s follow-up disclosure and patch notes — look for CVE numbers, precise affected firmware versions and a timeline for the remaining fixes they promised “within weeks.”
• Independent audits or third-party security write-ups — real reassurance comes from an outside review, not just patched binaries and a blog post.
• Whether DJI offers notification to owners whose devices were accessible; and whether regulators or consumer bodies ask for forensic evidence about data access.

If you own a Romo or similar IoT device, update firmware immediately and consider disabling cloud features you don’t actively use. Also, ask manufacturers why a camera or mic is needed and demand clear data-use and breach-notification policies.

TL;DR

A hobbyist trying to drive his Romo with a DualSense used Claude to inspect MQTT traffic and accidentally discovered a backend permission bug that exposed telemetry, cameras, microphones and floorplans for thousands of devices. DJI patched the obvious hole quickly but admits further fixes are coming; the episode is a reminder that cloud-side auth mistakes turn single devices into global surveillance networks. Watch DJI’s technical notes, independent audits and any formal disclosure about whether data was accessed or stored — that will tell us whether this was a close call or something worse.