This repository documents three critical security vulnerabilities discovered in the M6PLUS mobile payment terminal's Bluetooth communication protocol. These vulnerabilities affect M6PLUS terminals using Bluetooth connectivity and pose significant risks to payment security.
These vulnerabilities have been officially assigned the following CVEs:
- CVE-2026-4582 — Missing authentication
- CVE-2026-4583 — Replay attack
- CVE-2026-4584 — Cleartext transmission of cardholder data
The M6PLUS Bluetooth protocol does not implement cryptographic authentication at the application layer. Message integrity relies only on a weak XOR checksum, allowing commands to be accepted without verification of origin.
- Protocol uses single-byte XOR checksum:
checksum = ⊕ all_bytes - No HMAC, digital signature, or message authentication mechanism
- No mutual authentication between terminal and external device
- Commands accepted from paired Bluetooth devices without cryptographic validation
- Unauthorized command injection
- Manipulation of transaction parameters
- Bypass of application-level trust assumptions
References:
https://www.cve.org/CVERecord?id=CVE-2026-4582
The protocol does not implement any mechanism to ensure message uniqueness or freshness. Captured legitimate commands can be replayed indefinitely, multiplying transactions.
- No nonce, timestamp, or session identifier
- No sequence counter or replay detection
- Messages can be reused across sessions
- No binding between command and transaction context
- Replay of valid transaction messages
- Re-execution of previous operations
- Abuse of transaction flows without generating new data
References:
https://www.cve.org/CVERecord?id=CVE-2026-4583
Sensitive cardholder data, including full PAN, Track 2, cardholder name, and expiration is transmitted in cleartext within the application protocol, without encryption at the message level.
- PAN transmitted in plaintext
- Track 2 equivalent data exposed
- Cardholder name and expiration date included
- No application-layer encryption or data protection
- Exposure of sensitive cardholder data
- Risk of unauthorized data collection
- Potential compliance violations (e.g., PCI DSS)
References:
https://www.cve.org/CVERecord?id=CVE-2026-4584
[HEADER - 6 bytes]
├─ Start: 4D (TX) / 6D (RX)
├─ Length: 2 bytes
├─ Command: 2 bytes
└─ Status: 1 byte
[PAYLOAD]
├─ Marker: 3200
├─ LENGTH_BYTE: 1 byte (TLV size)
└─ TLV Data: EMV tags
[CHECKSUM - 1 byte]
└─ XOR of all previous bytes
| Tag | Name | Security Impact |
|---|---|---|
| 1F02 | Control Model | Controls CVM, PIN, online/offline |
| 1F0B | Custom EMV | Contains DF8126 (CVM limit) |
| 1F51 | Card Number | Full PAN exposed in response |
| 57 | Track 2 | Complete track data exposed |
According to the manufacturer's own documentation and data, Tags 1F02 and 1F0B are the main tags for manipulating the terminal's behavior.
Confirmed Vulnerable:
- M6PLUS Bluetooth Mobile POS Terminal (all firmware versions as of Feb 2026)
Potentially Affected:
- Others Bluetooth-enabled Terminals around the world using similar protocol
A Python tool (m6plus_client.py) demonstrates all three vulnerabilities:
Features:
- Protocol reverse engineering and TLV parsing
- Custom transaction command generation
- Parameter manipulation (tags 1F02, 1F0B)
- Replay attack demonstration
- Data exposure analysis
Usage:
# Install dependencies
pip3 install pybluez --break-system-packages
# Run research tool
sudo python3 m6plus_client.pyDisclaimer: This tool is for security research and educational purposes only. Use only on devices you own or have explicit permission to test. Some sensitive parts of the tool has been censored.
| Vulnerability | Technical Description | Attack Scenario | Impact & Severity |
|---|---|---|---|
| Transaction Control via Bluetooth | Critical transaction parameters such as amount, limits, EMV flags, and ISO formatting are transmitted in clear EMV TLV format without encryption in the Bluetooth channel. | Limit Manipulation: An attacker alters the 1F0B command (sub-tag DF8126) to increase the transaction limit without requiring PIN verification. |
HIGH: The EMV kernel processes the modified values as legitimate, allowing high-value transactions without authentication. |
| Lack of Strong Authentication | The protocol relies only on a 1-byte XOR checksum for integrity verification. There are no digital signatures, MAC, or HMAC protection mechanisms. | Command Injection: Due to the weak checksum, an attacker can modify any payload byte and recompute the checksum so the terminal accepts the altered message. | CRITICAL: The terminal cannot distinguish between the official application and a malicious device. Any correctly formatted command is accepted. |
| Replay Attack Surface | No nonces, counters, or terminal-validated timestamps are used (no secure clock validation). | Replay Attack: An attacker captures a legitimate authorization of R$100 via sniffing and replays it multiple times. The terminal processes each replay as a new transaction. | HIGH: A single legitimate authorization can be reused repeatedly to generate unlimited charges to the victim. |
| Excessive Data Exfiltration (PCI-DSS) | The terminal transmits sensitive data such as PAN, Track 2, Name, and transaction results in plaintext hexadecimal over Bluetooth, including all processed transaction data. | Silent Malware: Malware on a paired smartphone connects to the terminal and sends crafted commands (Replay) to retrieve responses containing the full PAN and other transaction data. | CRITICAL: Direct violation of multiple PCI-DSS requirements (3.3, 3.4, 4.2). The exposed data is sufficient for card cloning and online fraud. |
| State Reflection | The device mirrors exact copies of received parameters (1F42) and internal decision results (1F53). |
Oracle Attack: An attacker submits multiple malicious combinations of proprietary tags (e.g., “PIN not required”) until the terminal confirms approval via tag 1F53. |
MEDIUM-HIGH: Facilitates vulnerability discovery and confirmation of successful exploitation. |
One important condition for exploitation via Bluetooth communication is the ability to capture the original transaction hex through sniffing and then force the terminal to disconnect from the legitimate device so it can connect to a malicious one. I attempted Bluetooth channel jamming to trigger a spoofing scenario and force a disconnection, as well as a deauthentication attempt, but neither was successful. Therefore, a more realistic scenario is when the terminal disconnects naturally from the original device, creating a brief window in which an attacker could connect. This may occur due to application bugs that require the original device to be restarted, or in situations where the terminal remains unpaired and only establishes the Bluetooth connection at the moment a transaction is initiated.
Critical Priority:
-
Implement cryptographic authentication
- Add HMAC-SHA256 or TLS 1.3 mutual authentication
- Generate per-device certificates
- Validate command signatures
-
Add replay protection
- Implement 64-bit cryptographic nonces
- Validate timestamps within ±5 minute window
- Maintain cache of recent command hashes (last 1000)
-
Minimize data exposure
- Mask PAN to last 4 digits:
****5678 - Remove Track 2 from responses entirely
- Encrypt sensitive fields with AES-256-GCM
- Mask PAN to last 4 digits:
Medium Priority: 4. Timestamp validation
- Validate tag 1F03 against terminal RTC
- Reject commands outside acceptable time window
Immediate:
- Enable maximum CVM requirements
- Monitor for duplicate transactions
- Contact acquirer for update status
Long-term:
- Apply firmware updates when available
- Consider terminal replacement if issues not addressed
This research was conducted following responsible disclosure principles:
All testing on personally-owned devices
Test cards only (no real cardholder data)
Vendor notification before public disclosure
Educational purpose only
FOR EDUCATIONAL AND RESEARCH PURPOSES ONLY
The information and code in this repository are provided for security research and educational purposes. Unauthorized access to payment systems or exploitation of these vulnerabilities for malicious purposes is illegal and unethical.
Users of this code must:
- Only test on devices they own or have explicit permission to test
- Comply with all applicable laws and regulations
- Follow responsible disclosure practices
- Not use this information for fraudulent purposes
The author assumes no liability for misuse of this information.