Someone left the front door of a Roomba open, but only for the three seconds it takes to shake hands
CVE-2026-93289 is an OS command injection (CWE-78) in the Eufy Omni C20 and Omni X10 Pro robot vacuums running firmware prior to 1.6.4. An unauthenticated attacker within adjacent-network range (WiFi/Bluetooth proximity) can inject system commands during the device's initial pairing sequence — the brief window when the vacuum connects to a home WiFi network via the Eufy mobile app. Successful exploitation yields root-level command execution on the vacuum's embedded Linux SoC. CISA tracked this under ICS advisory ICSA-26-267-02, alongside two sibling CVEs: CVE-2026-93291 (CVSS 9.4, improper cert validation / MitM) and CVE-2026-93290 (CVSS 5.5, hardcoded credentials leaking map data). All three are fixed in firmware 1.6.4.
The vendor's CVSS 3.1 score of 7.5 HIGH is mathematically correct for the vector AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, and the CVSS 4.0 bump to 9.0 CRITICAL reflects the downstream impact modifiers. But both scores dramatically overstate the real-world risk to any enterprise security team. This is a *consumer robot vacuum cleaner*. It is not a server, not a network appliance, not an identity provider, and not a component that appears on asset inventories of organizations managing 10,000 hosts. The attack requires physical or wireless proximity to the device and the device must be actively in pairing mode — a window measured in seconds. No enterprise defender should lose sleep over this.
4 steps from start to impact.
Attacker achieves adjacent-network position
AV:A (Adjacent), meaning the attacker needs Layer 2 adjacency — either connected to the same home WiFi segment or close enough for direct wireless communication during pairing. This is not remotely exploitable over the internet.- Physical proximity to the target premises
- Target premises has an Eufy Omni C20 or X10 Pro on the network
- Enterprise networks almost never host consumer robot vacuums
- Even if present, the device would typically be on an isolated IoT/guest VLAN in any managed environment
- Attacker must physically be near the vacuum — think 'in the break room'
44:A6:E5:xx, C8:B2:9B:xx) would flag consumer IoT on corporate segments.Victim initiates pairing mode on the vacuum
AC:H precisely because of this timing dependency.- A user must be actively pairing the vacuum at the moment of attack
- Attacker must be monitoring for the pairing broadcast
- Pairing happens once during initial setup — a window of 30-120 seconds
- The attacker has no way to force the device into pairing mode remotely
- Re-pairing requires a physical factory reset button press on the device
Command injection during pairing handshake
PR:N) and no user interaction beyond the pairing initiation is needed (UI:N). The injected commands execute as root on the vacuum's ARM-based embedded Linux system. No public PoC or weaponized tool exists for this vulnerability.- Successful interception of or participation in the pairing handshake
- Knowledge of the injectable parameter (not publicly documented)
- No public PoC or exploit code exists
- The injectable parameter and protocol details have not been disclosed by Somerset Recon
- Reverse-engineering the pairing protocol requires firmware extraction and analysis
Root shell on the robot vacuum
S:U (Unchanged) — the compromise is confined to the vacuum itself. Impact is rated C:H/I:H/A:H on the device: the attacker can exfiltrate mapping data, use the vacuum's microphone/camera (if equipped), brick the device, or attempt lateral movement from the vacuum's network position. However, the vacuum is a low-powered IoT device with limited network capabilities.- Successful command injection in step 3
- The vacuum is an isolated IoT endpoint with no credentials to other systems
- Lateral movement from a vacuum to domain-joined hosts is a non-trivial post-exploitation challenge
- The device has minimal attack surface toward the rest of the network
The supporting signals.
| In-the-wild exploitation | None observed. Not listed in CISA KEV. No reports of active exploitation from CISA, vendor, or threat intel feeds. CISA advisory states no known public exploitation. |
|---|---|
| Proof-of-concept | None public. No PoC repositories, blog posts, or exploit code have been published. The injectable parameter and protocol specifics remain undisclosed. Researcher Jared of Somerset Recon reported the finding to CISA but has not released technical details. |
| EPSS score | Not yet scored — model evaluation in progress per FIRST.org. Given the adjacent-network vector and IoT-specific scope, expect a low percentile once scored. |
| KEV status | Not listed as of 2026-09-25. Given the adjacent-network-only vector and consumer IoT scope, KEV listing is unlikely. |
| CVSS vector interpretation | CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — Adjacent network, high complexity (pairing window), no auth needed, scope unchanged (device-only impact). CVSS 4.0 rates it 9.0 due to subsequent system impact modifiers, but this inflates the consumer-IoT reality. |
| Affected versions | Eufy Omni C20 firmware < 1.6.4, Eufy Omni X10 Pro firmware < 1.6.4 |
| Fixed version | Firmware 1.6.4 for both models, available via the Eufy mobile app OTA update |
| Scanning / exposure data | These are consumer WiFi-connected IoT devices with no internet-facing attack surface. They do not listen on routable ports. Shodan/Censys/GreyNoise exposure is zero — the attack vector is local/adjacent only. |
| Disclosure timeline | Disclosed 2026-09-24 via CISA ICS Advisory ICSA-26-267-02. Sibling CVEs: CVE-2026-93291 (CVSS 9.4, cert validation), CVE-2026-93290 (CVSS 5.5, hardcoded creds). |
| Reporting researcher | Jared of Somerset Recon reported all three CVEs to CISA. |
Sources.
Why this verdict
- Adjacent-only vector:
AV:Ameans the attacker must be on the same Layer 2 network or within wireless range of the vacuum. This is not remotely exploitable over the internet. For an enterprise fleet, this eliminates all external threat actors and limits the attack surface to physical insiders — a massive reduction in reachable population. - Pairing-window timing dependency:
AC:Hreflects that exploitation is only possible during the brief (30-120 second) pairing handshake. The attacker cannot trigger pairing remotely; they must be adjacent *and* a user must be actively setting up the vacuum. This is an extremely narrow race condition that cannot be reliably weaponized at scale. - No PoC, no exploitation, no KEV: Zero public exploit code exists. The injectable parameter and protocol details are undisclosed. No threat actor has been observed exploiting this. EPSS is not yet scored but will almost certainly land in the bottom decile.
- Role multiplier: The Eufy Omni C20 / X10 Pro is a *consumer robot vacuum cleaner*. It does not occupy ANY high-value enterprise role — it is not an identity provider, hypervisor, CI/CD component, backup system, database, network edge appliance, EDR agent, SIEM, or OT controller. In a fleet of 10,000 managed hosts, the installed base of Eufy robot vacuums is effectively 0%. Even in the rare case one appears on a corporate network (cleaning service, smart office pilot), it would be on an isolated IoT/guest VLAN. The blast radius is strictly host-level (the vacuum itself) with
S:Uscope. The high-value-role floor does NOT apply — this component is definitionally a low-value-role device. No deployment scenario produces domain-takeover, fleet-compromise, or supply-chain outcomes. - Scope unchanged, device-only impact: Even full compromise yields root on a low-powered ARM embedded Linux device running vacuum firmware. There are no domain credentials, no lateral-movement tooling, and no privileged network position to leverage. The worst realistic outcome is exfiltration of room mapping data — a privacy issue, not an enterprise security incident.
Why not higher?
The CVSS math gives 7.5 because it evaluates the vulnerability in isolation — an adjacent unauthenticated attacker gets full CIA impact. But CVSS doesn't account for the fact that this is a consumer robot vacuum with zero enterprise footprint, zero internet exposure, and exploitation only during a seconds-long pairing window. Nothing about this vulnerability threatens enterprise infrastructure, identity systems, or data at scale. Raising it would require evidence of enterprise deployment or a realistic pivot path, neither of which exists.
Why not lower?
Despite the consumer-device irrelevance, the underlying vulnerability is real — unauthenticated command injection yielding root. If an organization *does* have these devices on a flat network (e.g., a smart-building pilot), the compromised vacuum could theoretically serve as a network foothold. The adjacent-network constraint and pairing-window timing prevent an IGNORE rating; defenders with known Eufy inventory should still patch.
44:A6:E5, C8:B2:9B). This prevents Eufy devices from landing on managed segments in the first place. No mitigation SLA for LOW — standard network hygiene.- EDR on corporate endpoints — EDR doesn't run on embedded Linux IoT devices like robot vacuums. It would only help if the attacker pivoted to a managed host, which is a separate detection concern.
- WAF / reverse proxy — These devices don't expose web services. The attack vector is adjacent-network wireless during pairing, not HTTP.
- Vulnerability scanners (Nessus, Qualys) — Standard enterprise vuln scanners do not have plugins for Eufy robot vacuum firmware. They won't detect this CVE on your network.
Crowdsourced verification payload.
Run this on any workstation connected to the same network segment you want to audit. It scans the local ARP table for MAC addresses matching known Eufy/Ampak OUI prefixes. Requires no special privileges on Linux/macOS (arp -a is unprivileged); on Windows, run from a standard Command Prompt. Invoke with: python3 eufy_check.py
#!/usr/bin/env python3
"""CVE-2026-93289 - Eufy Omni C20 / X10 Pro Network Presence Check
Scans local ARP table for Ampak Technology OUI prefixes used by Eufy IoT devices.
Outputs VULNERABLE (Eufy devices found), PATCHED (N/A), or UNKNOWN.
NOTE: This script detects device PRESENCE, not firmware version.
Firmware must be verified via the Eufy mobile app.
"""
import subprocess, sys, re, platform
# Ampak Technology OUI prefixes (used by Eufy/Anker IoT devices)
EUFY_OUIS = [
"44:a6:e5", "c8:b2:9b", "10:27:f5", "d8:1c:14",
"ac:c1:ee", "48:a4:93", "38:01:46",
]
def get_arp_table():
try:
if platform.system() == "Windows":
out = subprocess.check_output(["arp", "-a"], text=True)
else:
out = subprocess.check_output(["arp", "-a"], text=True)
return out.lower()
except Exception as e:
print(f"[!] Could not read ARP table: {e}", file=sys.stderr)
return None
def main():
arp = get_arp_table()
if arp is None:
print("UNKNOWN - could not read ARP table")
sys.exit(2)
found = []
for line in arp.splitlines():
for oui in EUFY_OUIS:
# Match colon, dash, or dot-separated MACs
oui_dash = oui.replace(":", "-")
if oui in line or oui_dash in line:
found.append(line.strip())
break
if found:
print("VULNERABLE - Potential Eufy/Ampak IoT device(s) detected on this network segment:")
for f in found:
print(f" {f}")
print("\nAction: Verify device identity and firmware version via Eufy mobile app.")
print("If firmware < 1.6.4, update immediately. Isolate on IoT VLAN.")
sys.exit(1)
else:
print("PATCHED - No Eufy/Ampak OUI devices found in local ARP table.")
print("Note: This checks presence only. Devices on other VLANs won't appear.")
sys.exit(0)
if __name__ == "__main__":
main()