CVE-2026-116017 in xiaozhi-esp32-serverinfo

Summary

by MITRE • 10/24/2026

Xiaozhi-esp32-server before 0.9.8 contains an insecure direct object reference vulnerability in the manager-api DeviceController.getAddressBook handler that allows authenticated users to read other users' device address books. Attackers with a normal or self-registered account can request /device/address-book/{macAddress} with another user's device MAC to obtain contact MACs, aliases, call permissions, and owner user IDs.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 10/24/2026

The vulnerability identified in Xiaozhi-esp32-server versions prior to 0.9.8 represents a critical failure in access control mechanisms within the manager-api component. Specifically, this flaw resides in the DeviceController.getAddressBook handler, which is designed to retrieve address book information associated with specific hardware devices. The core technical issue stems from an insecure direct object reference (IDOR), where the application relies solely on the MAC address provided by the client as a unique identifier for data retrieval without verifying that the requesting user has legitimate ownership or administrative rights over that particular device. This architectural oversight allows any authenticated user, including those with standard self-registered accounts, to bypass authorization checks and access sensitive information belonging to other users in the system.

From an operational perspective, this vulnerability enables a significant breach of data confidentiality for multiple entities within the ecosystem. An attacker can exploit this flaw by crafting HTTP requests to the endpoint /device/address-book/{macAddress}, substituting the macAddress parameter with the MAC address of any device registered under another user's account. Upon successful exploitation, the server returns comprehensive details about that device's address book. This data includes contact MAC addresses, custom aliases assigned to contacts, call permission settings, and crucially, the owner user IDs associated with those contacts. The exposure of owner user IDs is particularly dangerous as it can facilitate further enumeration attacks or social engineering efforts by revealing the identity structure within the platform.

This vulnerability aligns directly with CWE-639, which categorizes issues related to authorization bypass through direct object references where insufficient checks are performed on resource identifiers provided by users. In terms of offensive security frameworks, this behavior is consistent with MITRE ATT&CK technique T1078, specifically the Valid Accounts sub-technique, as it leverages legitimate credentials to access unauthorized resources. It also reflects aspects of data exfiltration where sensitive internal information is retrieved through manipulated input parameters rather than exploiting a code execution flaw. The lack of server-side validation against an authorized user-to-device mapping table or session context allows for horizontal privilege escalation in the context of data visibility, even if vertical privilege escalation to administrative functions is not directly achieved by this specific vector.

To mitigate this vulnerability, developers must implement strict object-level authorization checks within the getAddressBook handler. The system should verify that the authenticated user's identity matches the owner ID associated with the requested device MAC address before returning any data. This can be achieved by maintaining a secure mapping table or database relationship between users and their authorized devices, ensuring that API endpoints only serve resources explicitly assigned to the requesting account. Additionally, implementing rate limiting on this endpoint can help mitigate automated scanning attempts by malicious actors seeking to enumerate valid user IDs through error responses or timing differences. Upgrading to version 0.9.8 or later is essential as it addresses these authorization gaps and enforces proper access control policies for device-related data retrieval operations.

Responsible

VulnCheck

Reservation

10/24/2026

Disclosure

10/24/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

medium

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!