CVE-2026-111623 in xiaozhi-esp32-server-java
Summary
by MITRE • 10/16/2026
Xiaozhi-esp32-server-java through 6.1.0 contains an authentication bypass vulnerability that allows unauthenticated attackers to obtain valid device WebSocket tokens by requesting /api/device/ota with any MAC address. Attackers can open a victim device's WebSocket channel to read private role system prompts, write conversation history, consume LLM/STT/TTS credentials, and overwrite device metadata.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in Xiaozhi-esp32-server-java versions through 6.1.0 represents a critical authentication bypass flaw within the Over-The-Air (OTA) update mechanism of the IoT ecosystem. This security defect stems from an insufficient validation process on the server side when handling requests directed to the /api/device/ota endpoint. Specifically, the application fails to verify whether the requesting entity possesses valid administrative credentials or legitimate device authorization before issuing WebSocket tokens. By exploiting this logic error, unauthenticated attackers can interact with the OTA interface using any arbitrary MAC address, effectively tricking the system into generating and returning a valid authentication token for that specified device identifier without requiring prior login or proof of ownership.
From a technical perspective, the core issue lies in the misconfiguration of access control policies surrounding dynamic resource generation. The server treats the provided MAC address as sufficient identity verification rather than treating it merely as an identifier to be validated against existing authorized devices and user permissions. This allows an external actor to forge requests that appear legitimate from the network layer up through the application logic, resulting in the issuance of session tokens that grant full administrative privileges over the targeted IoT device. The absence of cryptographic signing or challenge-response mechanisms for this specific endpoint further exacerbates the risk, enabling straightforward exploitation via standard HTTP clients without specialized tools.
The operational impact of this vulnerability is severe and multifaceted, affecting both data confidentiality and system integrity. Once an attacker obtains a valid WebSocket token through the OTA endpoint, they gain persistent access to the victim device's communication channel. This unauthorized access permits the reading of private role system prompts, which may contain sensitive configuration details or proprietary logic used by the AI assistant. Furthermore, attackers can manipulate conversation history, potentially injecting malicious instructions or altering logs for forensic evasion. The ability to consume LLM (Large Language Model), STT (Speech-to-Text), and TTS (Text-to-Speech) credentials allows adversaries to incur significant financial costs on behalf of the victim while depleting service quotas. Additionally, overwriting device metadata can lead to persistent compromise by altering firmware version checks or other integrity measures, facilitating further attacks such as downgrade exploits or permanent denial of service.
This vulnerability aligns with CWE-287, which describes Improper Authentication, specifically where an actor is able to bypass authentication mechanisms due to flawed logic in the access control implementation. In terms of offensive security frameworks, this exploit maps directly to MITRE ATT&CK technique T1078, Valid Accounts, as it involves obtaining legitimate credentials through system misconfiguration rather than credential theft or brute force. It also relates to T1496, Resource Hijacking, due to the potential for consuming cloud-based AI services and associated costs without authorization. The ability to modify device metadata further connects to T1578, Modify Cloud Compute Infrastructure, highlighting the breadth of control an attacker gains over the IoT asset lifecycle.
Mitigation strategies must prioritize immediate patching to version 6.1.0 or later where this flaw has been addressed by implementing strict authentication checks on all OTA-related endpoints. Administrators should enforce mutual TLS (mTLS) for device-to-server communications to ensure that only devices with valid certificates can initiate connections, thereby rendering MAC address spoofing ineffective. Additionally, implementing rate limiting and anomaly detection on the /api/device/ota endpoint can help identify and block automated exploitation attempts. For environments where immediate patching is not feasible, network-level segmentation should be employed to restrict access to this API from untrusted networks, ensuring that only authorized management subnets can interact with device provisioning services. Regular audits of IoT authentication flows are essential to prevent similar logic flaws in other endpoints within the application architecture.