CVE-2026-119703 in xiaozhi-esp32-server
Summary
by MITRE • 10/30/2026
xiaozhi-esp32-server through 0.9.8 contains an authentication bypass vulnerability in WebSocketServer._handle_auth that allows remote unauthenticated attackers to skip Bearer HMAC token verification by spoofing the Device-ID header. Attackers supplying an allowlisted MAC-address-shaped device identifier can open an authenticated WebSocket session, issue voice-assistant commands, exchange audio, and read that device's conversation context.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in xiaozhi-esp32-server versions through 0.9.8 represents a critical authentication bypass flaw within the WebSocketServer._handle_auth module. This security defect allows remote unauthenticated attackers to circumvent the intended Bearer HMAC token verification mechanism by exploiting improper validation of the Device-ID header. The core technical failure lies in the server's logic for verifying client identity, where it relies on an allowlist of MAC-address-shaped device identifiers rather than strictly enforcing cryptographic authentication tokens for all connection attempts. By spoofing a Device-ID that matches one of these pre-approved MAC addresses, an attacker can trick the server into believing the connection originates from a trusted physical device, thereby bypassing the requirement to present a valid HMAC-signed token.
From a technical perspective, this flaw stems from a misconfiguration or logical error in how the authentication state is established during the WebSocket handshake process. The system appears to prioritize static identity verification via MAC address spoofing over dynamic cryptographic proof of possession for certain code paths or configurations. This allows an attacker who can observe network traffic or guess valid MAC addresses associated with deployed devices to inject a forged header value that satisfies the allowlist check without possessing the private keys required to generate legitimate HMAC signatures. Consequently, the server establishes an authenticated session state for the malicious connection, treating it as if it were from a genuine, authorized hardware endpoint.
The operational impact of this vulnerability is severe, granting attackers full control over the voice-assistant functionality associated with the targeted device ID. Once inside the authenticated WebSocket session, adversaries can issue arbitrary commands to the AI assistant, effectively taking over its interactive capabilities. Furthermore, they gain the ability to exchange audio data bidirectionally, which facilitates eavesdropping on private conversations or injecting malicious audio prompts. Critically, attackers can also read the conversation context and history stored by the server for that specific device ID, leading to significant privacy violations and potential exposure of sensitive personal information. This level of access undermines the fundamental trust model of IoT voice assistants, where users expect their interactions to be secure and private.
This vulnerability aligns with CWE-287 Improper Authentication, as the system fails to properly verify the identity of a user prior to granting access to protected resources. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, specifically in the context of using valid credentials or identities that have been spoofed or misappropriated within an IoT ecosystem. The exploitation path resembles common patterns seen in other embedded systems where MAC address filtering is incorrectly used as a primary security control rather than a supplementary measure alongside strong cryptographic authentication.
Mitigation strategies should focus on immediate remediation and long-term architectural improvements. Users of xiaozhi-esp32-server versions up to 0.9.8 are advised to upgrade to the latest patched version where this logic has been corrected to enforce strict HMAC verification regardless of Device-ID values. For environments unable to update immediately, network-level controls such as IP whitelisting or TLS mutual authentication can provide a compensating control by restricting who can reach the WebSocket endpoint. Developers must also review their authentication modules to ensure that identity spoofing via header manipulation is not possible and that cryptographic proofs are mandatory for all session establishments. Future implementations should avoid relying on MAC addresses for access control decisions, as these are easily spoofed at the network layer, and instead rely exclusively on robust token-based or certificate-based authentication mechanisms.