Mobile payment terminals (mPOS) have become a core part of everyday transactions, especially for small businesses relying on accessible and low-cost payment solutions. But behind this convenience, there are often overlooked risks. In this research, I analyzed the Bluetooth communication protocol of one of these terminals and discovered that the security of the entire transaction flow can be compromised simply by interacting with the communication layer.
Through reverse engineering and hands-on exploration, I identified three vulnerabilities affecting fundamental security properties:
- Missing authentication — CVE-2026–4582
- Replay attack — CVE-2026–4583
- Cleartext transmission of cardholder data — CVE-2026–4584
These vulnerabilities reveal how the communication protocol itself layer alone can be sufficient to manipulate transactions and expose sensitive data. More information is available on GitHub: https://github.com/Davim09/m6plusexploit/
Disclaimer: Everthing was analyzed in a controlled environment to ensure no third-party data was compromised during the process. The content shared in this article is strictly for educational and informational purposes, I am not responsible for any misuse of the knowledge presented. The manufacturer had already been formally contacted, but no firmware update was available at the moment.
Background
Standard architecture for mPOS devices:
┌─────────────┐ Bluetooth ┌──────────────┐
│ Smartphone │◄──SPP/RFCOMM──►│ Terminal │
│ App │ │ (MPOS) │
└──────┬──────┘ └───────┬──────┘
│ │
│ Internet Card Interface
│ (Chip/NFC)
▼ ▼
┌─────────────┐ ┌──────────────┐
│ Acquirer/ │ │ Payment │
│ Payment │ │ Card │
│ Gateway │ └──────────────┘
└─────────────┘Most mPOS devices communicate via Bluetooth between the mobile device and the reader. In this model, a significant portion of the transaction data and logic is transmitted from the mobile application to the terminal, such as EMV tags that handle and control the transaction.
In this context, an attacker who manages to intercept or inject data into the Bluetooth communication, whether through pairing failures, use of insecure protocols, or reverse engineering, can alter critical values without needing direct access to the terminal's software (SDK). In such a scenario, standardized EMV tags, such as DF8126 (Required CVM Reader Limit), can have their limits altered, completely configuring/customizing the terminal's behavior in a transaction.
The terminal used in the analysis establishes communication with mobile applications via Bluetooth Classic using the SPP/RFCOMM (Serial Port Profile), without any PIN for the authentication. This profile functions as a virtual serial link between the mobile device and the terminal, providing a bidirectional transport layer. This channel doesn't just operate as telemetry or logging; it functions as a Transaction Control Plane, where:
App → Terminal: Sends configuration parameters and transactional context Terminal → App: Returns a complete dump of the data that was processed during the transaction
Protocol Framing Structure
Each transmitted message has a proprietary framing structure from the manufacturer. Here is a Real Example (Transaction R$ 233.00) of the packet structure:
4D 004C 0002 A0 3200 46 1F0101711F0204926400081F0B07DF812603200000... F4
│ │ │ │ │ │ └─ TLVs (70 bytes)
│ │ │ │ │ └─ LENGTH_BYTE = 0x46 (70 decimal)
│ │ │ │ └─ Fixed marker
│ │ │ └─ Status
│ │ └─ Command
│ └─ Packet length
└─ Start (TX)- There is a XOR checksum in the end that only offers weak integrity against accidental corruption, not against intentional tampering.
The Hex payload is structured using standard EMV TLV encoding, extended with internal proprietary tags (e.g., 1F02, 1F0B) that directly impact terminal behavior according to vendor-specific implementation.
Python Exploit
Using Python code that automatically pairs with the terminal's MAC address, it was possible to automate all the calculations needed to assemble a transaction and send it via Bluetooth to the terminal. This was achieved by creating a fully customized Hex Payload!
This code, or exploit, was assembled based on original Hex sent from the original app, captured through a sniff of the App → Terminal communication. These original Hex files are essential for understanding the communication and calculation logic, and can also be freely replicated, and the terminal simply accepts a typical replay attack.
Considering a large-scale attack on multiple terminals communicating via Bluetooth, an attacker can simply sniff this communication and intercept the original Hex file being sent, consequently studying the logic and calculations to build a specific exploit for that terminal.
Missing authentication and Cleartext transmission
Using the Python exploit, it is possible to establish a direct Bluetooth connection with the terminal, immediately exposing a fundamental design flaw: there is no sender authentication at the protocol level. The mPOS accepts any pairing request and blindly trusts any connected device, effectively allowing arbitrary entities to act as a legitimate transaction source.
Once connected, the terminal accepts and processes any incoming Hex payload without performing integrity validation, origin verification, or cryptographic authentication. This enables full impersonation of the legitimate mobile application responsible for assembling EMV transaction data.
Additionally, the communication channel transmits critical transaction data in cleartext or weakly protected formats, including EMV tags and sensitive fields (Track 2, PAN, CVM Result, Cardholder Name). This violates fundamental security principles and industry requirements (e.g., PCI-DSS), as sensitive cardholder data can be intercepted, modified, or replayed.
As a consequence, an attacker can not only inject arbitrary transaction parameters, but also observe, replay, and manipulate sensitive transaction data in transit, fully compromising the trust model between the mobile application and the terminal. This effectively transforms the Bluetooth channel into an unauthenticated control plane for transaction execution.
We can see that right in the command that "writes" the transaction data, In the example, it was possible to freely set/configure the values of 1F02 and 1F0B.
Replay Attack
The terminal communication protocol does not implement any protection mechanism against Replay attacks, as previously mentioned. The absence of critical elements such as nonce (one-time number), timestamp validation or sequence counters allows an attacker to capture a legitimate transaction command and reuse it indefinitely. Although the tag 1F03 contains a timestamp in the format YYYYMMDDHHmmss, this field is not validated by the terminal against the system's internal clock, functioning only as decorative metadata without any freshness check or acceptance window, being simply accepted and "written" to the terminal.
The terminal processes each received command in an isolated and stateless manner, allowing the same hex payload to be accepted multiple times as valid independent transactions.
To verify whether old commands remain valid after an extended period, a test was performed using a legitimate command that was captured on January 22, 2026 (date encoded in tag 1F03) and stored without modification.
We can see that each time the command is sent, it reverts to the time 03:51:00, that is, the time present in the hex file of the sent command. Each replay is processed as an independent transaction. There is no deduplication system, caching of viewed commands, or rate limiting. The terminal responds identically in all cases.
Vulnerability Matrix and Attack Scenarios
For better understanding, I have created a table that summarizes the discovered attacks/vulnerabilities that can be carried out through the Bluetooth communication vector, mainly using the Python exploit, exploiting both the protocol and parameter manipulation:
Exploitation via Bluetooth depends on capturing the original transaction data and taking over the connection from the legitimate device. Attempts to achieve a full MITM through jamming, spoofing, or deauthentication were unsuccessful. Instead, the attack is more feasible during natural disconnection events, where the terminal becomes available for new pairing, allowing an attacker to connect and interact with it.
Conclusion and Recommendations
In conclusion, the identified vulnerabilities demonstrate a systemic failure in the security model of this terminal, where the Bluetooth communication channel lacks authentication, integrity, and confidentiality controls. This allows attackers to manipulate transaction flows, replay operations, and access sensitive data without needing to compromise the application or hardware directly.
As mitigation, it is essential to implement cryptographic authentication, enforce message integrity (e.g., MAC), and ensure proper encryption of sensitive data in transit. For merchants and acquirers, its recommended to immediately suspend production use until validated fixes are deployed, potentially requiring large-scale recall and replacement of deployed devices.
The problem is not unique to just one terminal. Many Bluetooth payment terminals rely on similar protocol designs, implementing weak authentication mechanisms and transmitting sensitive data without adequate encryption, putting thousands of merchants at risk. The goal of sharing this research is purely educational and to raise awareness among terminal manufacturers, payment processors, acquirers, and merchants.
This analysis of the Bluetooth vulnerabilities of this terminal (mPOS) is one part of a broader research project on payment terminals. The next publication will detail the manipulation of the EMV protocol in Mastercard transactions using the same terminal. If you want to stay up to date with my work and projects, check out my Beacons.ai to follow me and see what I'm up to next!