EUVD-2026-86410
GHSA-9vx9-rfcq-648m
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain adjacent network/radio proximity
-
DeliveryDevice enters pairing mode
-
ExploitInject OS command into pairing field
-
ExecutionExecute system commands unauthenticated
-
ImpactFull device compromise and LAN foothold
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization OS command sanitization, avoid shell exec
MITRE ATT&CK
2 techniques across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the attacker to be on an adjacent network / within wireless proximity of a eufy Omni C20 or Omni X10 Pro (AV:A) and to interact during the device pairing process, which is the specific feature carrying the CWE-78 command-injection flaw. AT:P and AC:H reflect that the device must be in the pairing window and that reliable exploitation demands specific timing/conditions. No authentication (PR:N) and no user interaction (UI:N) are needed once the device is pairing. Limiting factors: attacker cannot reach the device over the open internet, must have local/radio adjacency, and the pairing window must be active - significantly narrowing realistic opportunity versus the raw 9.0 score. |
| Impact | The vendor CVSS 4.0 score of 9.0 (CRITICAL) is tempered by two limiting metrics that separate this from a wormable network flaw: AV:A (adjacent, not AV:N) and AC:H combined with AT:P, meaning the attacker must be within radio/local-network proximity AND catch the device in the specific pairing window. PR:N/UI:N correctly indicate no authentication or victim interaction is required once those preconditions are met. Impact is genuinely severe - CWE-78 OS command injection yields VC:H/VI:H/VA:H on the device plus SC:H/SI:H/SA:H subsequent-system impact, consistent with full compromise of the robot and a foothold on the home/LAN it sits on. On exploitation signals: no EPSS score, no CISA KEV listing, and no public POC are present in the input, so this is 'no public exploit identified at time of analysis' - a real defect worth patching but not evidence of active or automatable mass exploitation. Net: a legitimately high-impact bug whose real-world risk is throttled by the adjacent-access, pairing-window, and high-complexity requirements, so it is a prioritize-but-not-emergency issue for the affected consumer IoT population rather than an internet-facing wormable threat. |
| Exploit ScenarioDerived | An attacker within wireless/adjacent-network range of a eufy Omni C20 or X10 Pro waits for or induces the device to enter pairing mode, then injects OS commands into a pairing-handshake field to run arbitrary system commands on the robot without any credentials. No public exploit code is identified, and success depends on proximity plus catching the pairing window (AC:H/AT:P). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 24, 2026
Command injection in the pairing process of eufy Omni C20 and Omni X10 Pro robot vacuums lets an unauthenticated attacker on an adjacent network or within wireless proximity run arbitrary system commands on the device during pairing. The vendor rates this CRITICAL at CVSS 4.0 9.0 (AV:A/AC:H/AT:P/PR:N/UI:N, all-high impact including subsequent-system impact), and CISA ICS published advisory ICSA-26-267-02; the practical bar is higher than the score suggests because the attacker must be radio/local-adjacent and catch the device inside an active pairing window. No public exploit code was identified at time of analysis, and the flaw is not confirmed actively exploited (not in CISA KEV).
RemediationAI
No vendor-released patch is identified in the available data: the CPE records for eufy Omni C20 and Omni X10 Pro carry wildcard versions and the single reference is the CISA ICS advisory ICSA-26-267-02 (https://www.cisa.gov/news-events/ics-advisories/icsa-26-267-02), which should be checked directly for a firmware update or vendor statement before assuming none exists. Until fixed firmware is confirmed and applied, the actionable compensating controls are: (1) perform initial pairing only in a controlled RF environment where no untrusted wireless clients are present, and re-pair from a factory-reset state if a device was paired in an exposed location - trade-off is operational inconvenience but it removes the attacker's adjacency requirement during the vulnerable window; (2) keep the vacuum in pairing/provisioning mode for the shortest possible time and confirm the device has exited pairing mode afterwards, since AC:H/AT:P means exploitability depends on that window being open - trade-off is that a pairing failure requires starting over; (3) segment the device onto a dedicated IoT SSID/VLAN with client isolation and mDNS/UPnP discovery disabled so injected commands cannot pivot to trusted hosts (the SC:H/SI:H/SA:H metrics imply scope change) - trade-off is that some app features and local integrations may break; (4) enforce egress firewall rules on the IoT VLAN so the vacuum can reach only required cloud endpoints, and monitor that segment for anomalous outbound connections or unexpected shell-like traffic - trade-off is ongoing log review and potential cloud feature loss; (5) if the device is in a sensitive environment (office, small business, or home office with sensitive assets), power it off or disconnect it from the network until a patched firmware version is confirmed. Because the flaw is unauthenticated (PR:N) and requires no user interaction (UI:N) while pairing is active, do not rely on user education or app-side prompts as a control.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause class is CWE-78, OS command injection, occurring specifically in the device pairing/provisioning workflow of the eufy Omni C20 and Omni X10 Pro. During pairing, the vacuum accepts configuration input over its local wireless provisioning interface (the AV:A vector indicates Wi-Fi/Bluetooth-range adjacency rather than internet reachability) and fails to neutralize shell metacharacters before that input reaches a system-level command execution path. Because the CVSS 4.0 vector is PR:N and UI:N, no credentials and no legitimate user action on the app or device are required once pairing is in progress, but AC:H and AT:P encode the real friction: reliable exploitation depends on timing and on the device being in the pairing state. The SC:H/SI:H/SA:H subsequent-system metrics indicate a scope change - successful injection can extend beyond the vacuum itself to systems or accounts the device is paired with or trusted by on the local network. The CPE entries (cpe:2.3:a:eufy:omni_c20 and cpe:2.3:a:eufy:omni_x10_pro with wildcard versions) show that no fixed firmware release is enumerated for either model.
Know when Omni C20 gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Adjacent pairing-window access with reliability caveats gives AV:A/AC:H, no auth (PR:N); OS command exec fully compromises the device and pivots to the network, so S:C with C/I/A:H.
Primary rating from Vendor (icscert).
CVSS VectorVendor: icscert
Lifecycle Timeline
2DescriptionCVE.org
The affected products are vulnerable to command injection attack that could allow an unauthenticated attacker to execute system commands during the pairing process.
Executive ViewAI
A critical command-injection flaw in eufy Omni C20 and Omni X10 Pro robot vacuums allows an attacker within wireless proximity to execute arbitrary system commands on the device during its pairing window, without any credentials. Any organization that has deployed these units - in offices, lobbies, or connected facilities - should treat them as potentially compromiseable endpoints on the network until the vendor ships a fix, though the attack requires the attacker to be physically nearby and to catch the device mid-pairing. Leadership should care because no vendor patch exists yet, remediation depends on procedural controls and network segmentation rather than a simple update, and a compromised vacuum provides a foothold into the corporate network.
No vendor-released patch identified at time of analysis. Interim mitigations: place affected vacuums on an isolated IoT network segment with no access to corporate resources; disable or strictly schedule pairing so devices are never left in an active pairing state unattended; restrict physical and wireless proximity to the devices (lock rooms, limit visitor access, control RF coverage); monitor the IoT segment for unexpected outbound connections; and maintain an asset inventory with a documented exception until a vendor fix is available.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
OS command injection occurs when an application passes unsanitized user input directly into system shell commands.
Improper TLS certificate validation in the eufy Omni C20 robot vacuum allows an attacker who has already obtained a man-
Hard-coded credentials embedded in the Eufy Omni C20 robot vacuum (all versions per CPE cpe:2.3:a:eufy:omni_c20) let an
Exploit-DB