# CVE-2026–31280: Insecure Bluetooth "RFCOMM" Leading to Device Crash in Parani M10 Intercom

**1 Security Assessment Details**\
**1.1 Executive Summary**\
This vulnerability impacts device availability, integrity and confidentiality due to the\
exposure of an unauthenticated Bluetooth Classic RFCOMM service combined with improper input validation. The device allows un-authenticated connection by bypassing\
of enabling pairing mode within Bluetooth range to establish a session and send unauthorized commands. A threat actor can disrupt normal operation by injecting arbitrary\
audio or sending malicious input that triggers Man-In-Middle(MITM), buffer overflow\
which are leads to device crash, disrupt authorized Bluetooth connection. <br>

**1.2 Scope and Objectives**\
The scope of this assessment was limited to Bluetooth Classic Communication of Parani\
M10 Intercom(Firmware Version 2.1.3).

\
**1.3 Technology Impact Summary**\
The security assessment of the Bluetooth Classic communication interface has been performed. These assessments aimed to identify security weaknesses in the evaluated intercom device, explain the impact and associated risks, and provide guidance for prioritization and remediation. <br>

**Following are the technical impacts:**\
An attacker within Bluetooth range can connect to an exposed RFCOMM service without\
authentication and perform unauthorized actions, including sending of arbitrary payloads\
leads to device crash until next manual intervention. Also attacker do MITM causes to\
play arbitrary audio discontinue authorized connection between user mobile Intercom\
device. <br>

**1.4 Business Impact Summary**\
**1.4.1 Overall Business Impact**\
The identified wireless-layer vulnerability represents a significant high business risk,\
as successful exploitation could disrupt normal device operation, allow unauthorized malicious data injection, negatively impact customer trust and user experience, damage\
brand reputation and market credibility, introduce safety concerns in sensitive deployment environments, and potentially expose the organization to regulatory scrutiny, legal\
liability, and financial costs associated with remediation and customer support.

**1.5 Testing Environment and Tools**\
Bluetooth security testing was conducted using standard Bluetooth enumeration and\
interaction tools:

• The intercom device equipped with Bluetooth Classic functionality\
• A Linux-based security testing workstation (Kali Linux) with TP -Link Bluetooth\
adapter for Bluetooth connectivity testing.\
• “bluetoothctl” CLI tool for pairing analysis and service enumeration.\
• “RFCOMM” utilities used for establish direct channel communication and transmit\
crafted test payloads.\
• “btmon” utility used to capture logs for analysis and service enumeration.\
• A python Script for payloads flooding.

<figure><img src="https://1077869007-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F672xEYmheLBSXURfBstx%2Fuploads%2FeTjWTSiUOTLcRCbwBks6%2Fimage.png?alt=media&#x26;token=7d42205b-84b5-4068-bf21-e6de662580ab" alt=""><figcaption></figcaption></figure>

**1.7 Device Strengths**\
Not assessed in this engagement (scope limited to Bluetooth Classic communication). No\
additional strengths were evaluated. <br>

**1.8 Device Weaknesses**

• The intercom device exposes an unauthenticated Bluetooth Classic RFCOMM service, allowing unauthorized nearby attackers to establish a connection bypassing of\
enabling pairing mode on the device. This leads to create buffer overflow conditions\
further that can result in device crash or reboot until manual intervention.

• The exposure of RFCOMM channels (CH10, CH12) in the device makes attacker\
to create a MITM environment. It discontinue authorized user establishment which\
disrupt Bluetooth communications by playing arbitrary noise or crash the device.

**2 Technical Findings**\
**2.1 PM10-IBT-01: Insecure Bluetooth Communiation**\
**Potential Impact: High** <br>

**Description**\
The intercom device relies on Bluetooth Classic communication to provide local wireless functionality. During the assessment, it was observed that the device exposes an\
RFCOMM service without requiring pairing or authentication. A threat actor within\
Bluetooth range can establish a direct connection to the device and transmit unauthorized commands. It was further identified that the RFCOMM service does not properly\
validate input length. By sending malicious data, the attacker can trigger a buffer overflow condition, causing the device to crash or reboot. Additionally, unauthorized audio\
playback can be performed, disrupting normal device behavior\
Affected Components\
• The device’s Bluetooth Classic communication module.\
• The exposed RFCOMM service interface.\
• The command-processing and input-handling mechanism within the firmware.

\
**Technical Risk**\
An attacker can establish an unauthenticated connection and inject arbitrary commands,\
impacting device integrity. Additionally, exploitation of the buffer overflow condition can\
cause the device to become unavailable resulting in Denial-of-Service state until physical\
intervention to restore normal functionality.\
Business Risk <br>

**Exploitation of this vulnerability could:**\
• Lead to operational downtime or instability of the device\
• Increase customer dissatisfaction and operational support costs\
• Negatively affect brand reputation and long-term consumer trust

**Steps to Reproduce (High-Level) Case 1 - Buffer Overflow Attack**

1. Perform OSINT on Target Device: Conduct open-source intelligence (OSINT) to gather publicly available information related to the intercom device, including identification of its Bluetooth MAC address.
2. Validate Device MAC Address: Physically inspect the intercom device and confirm that the Bluetooth MAC address identified during OSINT matches the MAC address printed on the back label of the device.

<figure><img src="https://1077869007-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F672xEYmheLBSXURfBstx%2Fuploads%2Fjh5ufnUpvyip7jarqQJF%2Fimage.png?alt=media&#x26;token=792c1b4f-c68c-482d-8233-9cc99906d33e" alt=""><figcaption></figcaption></figure>

3. Assess Pairing Configuration: Attempt to pair with the device and observe that it allows pairing without requiring authentication or user verification.
4. Enumerate Available Services Post-Pairing: After establishing the unauthenticated pairing, review the list of exposed Bluetooth services and identify that an RFCOMM service is active on channel 10 and 12.

<figure><img src="https://1077869007-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F672xEYmheLBSXURfBstx%2Fuploads%2FuR60qNDRcdkDvH0NcXbi%2Fimage.png?alt=media&#x26;token=c6686fef-ccc6-4569-94fc-aa3e86841276" alt=""><figcaption></figcaption></figure>

5. Establish RFCOMM Connection: Initiate a direct RFCOMM connection to channel 10 using appropriate Bluetooth utilities.

<figure><img src="https://1077869007-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F672xEYmheLBSXURfBstx%2Fuploads%2FGNb3jc50s9eucvgpaPL9%2Fimage.png?alt=media&#x26;token=acad47b5-d826-4cbf-8f3b-7c2a46f0017c" alt=""><figcaption></figcaption></figure>

6. Execute Crafted Script: Run a specially crafted script to transmit unauthorized and oversized input data through the established RFCOMM session.

<figure><img src="https://1077869007-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F672xEYmheLBSXURfBstx%2Fuploads%2FdNw3CPMitUUWzwdYhBwv%2Fimage.png?alt=media&#x26;token=8767d23e-d04b-4a82-9eff-cfb1e77ff327" alt=""><figcaption></figcaption></figure>

7. Observe that the device accepts the injected input and subsequently crashes or powered off, confirming the presence of an unauthenticated command injection vulnerability combined with a buffer overflow condition.

**Case 2- Man In the Middle Attack**

1. Connect the mobile phone to the intercom via Bluetooth and begin playing an audio track to confirm a stable connection.

<figure><img src="https://1077869007-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F672xEYmheLBSXURfBstx%2Fuploads%2FjbPA73Ftizp8qG5Ycv3Z%2Fimage.png?alt=media&#x26;token=e72d2272-a643-4a9d-87bb-b15e03379ba7" alt=""><figcaption></figcaption></figure>

2. Audio data was injected into the intercom stream through the Paplay utility.The attack succeeded, resulting in arbitrary audio being played over the intercom through an unauthorized method.

<figure><img src="https://1077869007-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F672xEYmheLBSXURfBstx%2Fuploads%2Fa0GfEcLTQi9M1ATsKe2W%2Fimage.png?alt=media&#x26;token=83d1239a-06d5-4c96-be8e-d5fca7a5bacc" alt=""><figcaption></figcaption></figure>

3. Establish an RFCOMM connection to the intercom using an available channel 12.

<figure><img src="https://1077869007-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F672xEYmheLBSXURfBstx%2Fuploads%2FasEsfDwH9oYItCtODmAx%2Fimage.png?alt=media&#x26;token=334f26b6-8994-4132-8624-6bbe3d29db78" alt=""><figcaption></figcaption></figure>

4\. Conduct a Denial-of-Service (DoS) attack over RFCOMM. Upon successfull execution of attack, the connected mobile device was forcibly disconnected. Additionally,\
other intercom devices connected to the same unit were also disconnected. The target intercom crashes, and remaining non-functional until manual intervention is\
performed.

<figure><img src="https://1077869007-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F672xEYmheLBSXURfBstx%2Fuploads%2FBipzVl98GYqQ8FWKtmuK%2Fimage.png?alt=media&#x26;token=27cf3fab-d052-49c6-a687-c40a53f6989d" alt=""><figcaption></figcaption></figure>

5. It was observed that the mobile device was successfully disconnected from the intercom, and the intercom became unavailable for further connections until manual   \
   intervention is performed.

<figure><img src="https://1077869007-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F672xEYmheLBSXURfBstx%2Fuploads%2FvphBgoQA2bJMrdjY9WBk%2Fimage.png?alt=media&#x26;token=6e211631-e252-48f2-b50b-88ad80aba834" alt=""><figcaption></figcaption></figure>

<figure><img src="https://1077869007-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F672xEYmheLBSXURfBstx%2Fuploads%2FEpQ1hFKvuZDDhtOWnsYq%2Fimage.png?alt=media&#x26;token=bcf8b4ee-32c8-4516-88b4-7d6b512b88b4" alt=""><figcaption></figcaption></figure>

**Notes**\
This proof-of-concept was conducted in a controlled and authorized testing environment.\
The assessment was limited to demonstrating unauthenticated command injection and\
service disruption through a buffer overflow condition over Bluetooth Classic communication. No attempts were made to perform advanced exploitation beyond validating the\
identified vulnerability. <br>

**3 Remediation and Recommendations**\
• Enforce Secure Authentication and Pairing Controls: Configure the Bluetooth interface to require authenticated pairing (e.g., Secure Simple Pairing with user confirmation) before granting access to any services.\
• Implement Service-Level Authorization: Restrict access to the RFCOMM service\
by validating authenticated link keys and enforcing authorization checks prior to\
processing commands.\
• Strengthen Input Validation Mechanisms: Implement strict bounds checking and\
proper input length validation within the RFCOMM service handler to prevent\
buffer overflow conditions. <br>

**4 Appendix — Contact and Disclosure**\
Researcher(s): Tapadyuti Baral, Nikhil Yalgar\
Contact: <arghyabaral@gmail.com>, <nik.sec127001@proton.me>
