A popular Bluetooth messenger has given its audience an extremely unpleasant surprise.
BARGHEST specialists discovered a vulnerability in the decentralized messenger BitChat that allowed forged messages to be injected into the app's Bluetooth mesh network. The bug affected the iOS version of BitChat and could be used to send spam, spoof messages, and disrupt network operation without an internet connection.
The analysis revealed a chain of errors leading to so-called cache poisoning. In this scenario, an attacker sends a specially crafted data packet, which the client accepts as legitimate and stores in the local cache. After synchronization with other devices, this packet is automatically distributed throughout the network.
BitChat is designed for messaging without a central infrastructure. Devices find each other via Bluetooth Low Energy and send messages using a gossip network, gradually distributing data between participants. Each node maintains a local message cache and shares it with new neighbors upon connection. This cache serves as the system's key trust point: only verified messages should be entered into it and then transmitted to other users.
In version 1.15.0 for iOS, the verification mechanism worked incorrectly. A client could receive a packet without a cryptographic signature and store it in the cache. Once stored, such a packet was considered a normal message and was distributed during subsequent syncing with other devices.
The attack relied on several weaknesses in packet processing. The client trusted the sender ID specified within the packet itself, even though this ID was controlled by the attacker. During a short synchronization window, the application relaxed timestamp checking, simplifying validation. Additionally, authentication was bypassed: if the TTL parameter was zero, the application accepted the packet even without a signature. Furthermore, the code cached broadcast messages before final verification.
The combination of these features allowed an attacker to connect to the device via Bluetooth, send a valid advertisement packet, and then inject an unsigned message. The application would receive the message, display it in the chat, and add it to the cache. The message would then begin to propagate among other network participants during normal synchronization.
According to the study's authors, once a malicious packet entered the cache, further propagation occurred automatically. It was enough to "poison" one network node—other devices would receive fake messages when exchanging cache data, even if the attacker had already disconnected.
The bug didn't allow arbitrary code execution, but it could seriously undermine the reliability of offline communications. During internet outages, such apps are used to coordinate activities, so fake messages and network noise can disrupt information flow.
BitChat developers fixed the issue the same day they received the notification. The fix was released on January 28, 2026. Further analysis showed that the Android version of the app is not vulnerable to this attack: the client strictly verifies digital signatures and stores data in the cache only after full validation.
BARGHEST specialists discovered a vulnerability in the decentralized messenger BitChat that allowed forged messages to be injected into the app's Bluetooth mesh network. The bug affected the iOS version of BitChat and could be used to send spam, spoof messages, and disrupt network operation without an internet connection.
The analysis revealed a chain of errors leading to so-called cache poisoning. In this scenario, an attacker sends a specially crafted data packet, which the client accepts as legitimate and stores in the local cache. After synchronization with other devices, this packet is automatically distributed throughout the network.
BitChat is designed for messaging without a central infrastructure. Devices find each other via Bluetooth Low Energy and send messages using a gossip network, gradually distributing data between participants. Each node maintains a local message cache and shares it with new neighbors upon connection. This cache serves as the system's key trust point: only verified messages should be entered into it and then transmitted to other users.
In version 1.15.0 for iOS, the verification mechanism worked incorrectly. A client could receive a packet without a cryptographic signature and store it in the cache. Once stored, such a packet was considered a normal message and was distributed during subsequent syncing with other devices.
The attack relied on several weaknesses in packet processing. The client trusted the sender ID specified within the packet itself, even though this ID was controlled by the attacker. During a short synchronization window, the application relaxed timestamp checking, simplifying validation. Additionally, authentication was bypassed: if the TTL parameter was zero, the application accepted the packet even without a signature. Furthermore, the code cached broadcast messages before final verification.
The combination of these features allowed an attacker to connect to the device via Bluetooth, send a valid advertisement packet, and then inject an unsigned message. The application would receive the message, display it in the chat, and add it to the cache. The message would then begin to propagate among other network participants during normal synchronization.
According to the study's authors, once a malicious packet entered the cache, further propagation occurred automatically. It was enough to "poison" one network node—other devices would receive fake messages when exchanging cache data, even if the attacker had already disconnected.
The bug didn't allow arbitrary code execution, but it could seriously undermine the reliability of offline communications. During internet outages, such apps are used to coordinate activities, so fake messages and network noise can disrupt information flow.
BitChat developers fixed the issue the same day they received the notification. The fix was released on January 28, 2026. Further analysis showed that the Android version of the app is not vulnerable to this attack: the client strictly verifies digital signatures and stores data in the cache only after full validation.
