Xiaozhi ESP32 server: an OTA call hands out another device's token
A device token in Xiaozhi-esp32-server-java proves only which MAC address asked for it, and the OTA route gives one to anyone.
· VulnCheck · Research by hieuPenguinnn
CVE-2026-111623 lets an anonymous caller post a victim's MAC address to /api/device/ota in Xiaozhi-esp32-server-java and receive a working WebSocket token for that device. The token exposes the device's system prompt and provider credits.
01What happened
VulnCheck published CVE-2026-111623 for Xiaozhi-esp32-server-java on October 16, 2026 with a public date of October 15, crediting the finder hieuPenguinnn, and rates it 6.3 under CVSS 4.0. The write-up is a source review of release tag v6.1.0 and says runtime validation was not performed. No fix is recorded, and the project's GitHub security advisory count was zero when the finder looked.
02How it works
Four weaknesses line up. The OTA route carries the @SaIgnore annotation, so it needs no login. For a device already bound to a user, the handler returns a device token without checking that the caller is that device or that owner. The token is an HMAC over the normalized device id and a timestamp, with nothing tied to a user or a session, and it stays valid for 30 days by default. The WebSocket handshake then accepts any valid token for that MAC and binds the connection to the device and its owner.
03Who is affected
Versions through 6.1.0 are listed, but only where the operator set xiaozhi.device-auth.secret; the write-up excludes the default configuration that leaves the secret unset. An attacker needs the victim device's MAC address and network reach to the OTA endpoint and the dialogue service. Hobby and small-office deployments that exposed those ports to the internet are the realistic case.
04What to do
Keep the OTA endpoint and the dialogue service port off the public internet, and treat any LLM, speech-to-text or text-to-speech key configured on an exposed instance as abused until the bills say otherwise. The write-up's fix is to stop returning a reusable channel token to anonymous OTA callers for bound devices, issue short-lived single-use activation tokens instead, and bind tokens to a per-device secret provisioned at setup rather than to the MAC address.
Sources 5 links, all fetched
- 1vulncheck.comVulnCheck Advisory
- 2hackmd.ioResearcher Write-Up
- 3cveawg.mitre.orgCVE Record
- 4github.comGitHub Advisory
- 5github.comToken Source