CVE-2025-55292

Executive Summary

CVE-2025-55292 is a critical vulnerability in the Meshtastic open-source mesh networking solution. The flaw arises from the architecture's reliance on a NodeID derived from the MAC address rather than the node's public key for identification. An attacker can forge a NodeInfo message on behalf of a victim node, falsely advertising that the victim is operating in HAM mode (which disables encryption). This allows the attacker to overwrite the NodeDB on other nodes, forcing them to communicate with the victim using a shared channel key instead of Public Key Cryptography (PKC). The attack can be made persistent by regularly re-broadcasting the forged NodeInfo. The vulnerability has a CVSS score of 8.2, indicating high severity. A patch is available in Meshtastic version 2.7.6.

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby). It is a firmware-level issue in the Meshtastic project, which is distributed as binary firmware images and source code. The primary supply chain risk is the distribution of unpatched firmware images. Users must ensure they download firmware only from the official Meshtastic GitHub releases or build from the patched source.

CVSS Breakdown & Threat Level

• CVSS Score: 8.2 (High)
• Attack Vector (AV): Adjacent Network (AV:A) - The attacker must be within radio range of the target mesh network.
• Attack Complexity (AC): Low (AC:L) - The attack requires no special conditions; standard Meshtastic radio hardware is sufficient.
• Privileges Required (PR): None (PR:N) - No authentication is needed to send NodeInfo messages.
• User Interaction (UI): None (UI:N) - The victim node does not need to perform any action.
• Scope (S): Unchanged (S:U) - The vulnerability affects the confidentiality and integrity of communications within the same mesh network.
• Confidentiality (C): High (C:H) - An attacker can read all direct messages sent to the victim node.
• Integrity (I): High (I:H) - An attacker can modify the victim's node details (name, short name, etc.).
• Availability (A): None (A:N) - The attack does not directly impact the availability of the network.

Threat Level: High. The attack is easily executable with commodity hardware and requires no authentication. It can lead to a complete compromise of communication confidentiality and integrity for the targeted node.

Deep Dive & Mechanics

The core issue is the trust model in Meshtastic. The network identifies nodes by a NodeID, which is derived from the device's MAC address. This is a static, non-cryptographic identifier. The public key of a node is used for encryption but is not the primary identifier.

1. NodeInfo Message: Each node periodically broadcasts a NodeInfo message containing its NodeID, public key, long name, short name, and a flag indicating whether it is in HAM mode.
2. HAM Mode: HAM mode is a regulatory compliance feature for amateur radio operators. When enabled, the node sends all messages unencrypted. Other nodes, upon receiving a NodeInfo with the HAM flag set, will stop using PKC for direct messages to that node and instead use the shared channel key (which is often a default or weak key).
3. Forgery Attack: An attacker can craft a malicious NodeInfo message. They set the NodeID to the victim's NodeID (which is public or easily sniffed). They set the HAM mode flag to true. They can also change the long name and short name. This message is then broadcast over the mesh.
4. NodeDB Overwrite: Other nodes in the mesh receive this forged NodeInfo. Because the NodeID matches the victim's NodeID, they overwrite their local NodeDB entry for the victim. They now believe the victim is in HAM mode.
5. Consequences:
   • Loss of Confidentiality: All subsequent direct messages to the victim are sent using the shared channel key (unencrypted or weakly encrypted), which the attacker knows.
   • Loss of Integrity: The attacker can change the victim's displayed name and short name, causing confusion or impersonation.
   • Persistence: The attacker must periodically re-broadcast the forged NodeInfo to overwrite the legitimate one sent by the victim. This is a race condition that favors the attacker if they can broadcast more frequently.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-2.7.6):

The vulnerable code likely resides in the NodeDB or message handling logic. The core flaw is that the NodeInfo message is accepted and processed without verifying that the sender is the legitimate owner of the NodeID.

// Simplified vulnerable logic
void handleNodeInfo(const NodeInfo &info) {
    // No verification of the sender's identity
    nodeDB[info.node_id] = info; // Directly overwrite
}

Patched Code (2.7.6+):

The patch introduces cryptographic verification. The NodeInfo message must be signed by the private key corresponding to the public key contained within the message. The receiving node verifies this signature before updating the NodeDB.

// Simplified patched logic
void handleNodeInfo(const NodeInfo &info, const CryptoKey &sender_pub_key) {
    // Verify the signature of the NodeInfo message
    if (!verifySignature(info, sender_pub_key)) {
        return; // Reject the message
    }
    // Only update if the NodeID matches the public key's owner
    if (info.node_id == getNodeIdFromPublicKey(sender_pub_key)) {
        nodeDB[info.node_id] = info;
    }
}

The key change is that the NodeID is now cryptographically bound to the public key. The getNodeIdFromPublicKey function derives the NodeID from the public key, making it impossible to forge a NodeInfo for a different NodeID without the corresponding private key.

Exploitation & Lab Setup

Red Team (Attacker)

Objective: Forge a NodeInfo message for a victim node to force HAM mode and intercept communications.

Prerequisites:

• A Meshtastic device (e.g., ESP32-based board) with custom firmware.
• Ability to sniff the victim's NodeID (e.g., by listening to the mesh channel).
• Knowledge of the shared channel key (often default or easily guessable).

Lab Setup:

1. Hardware:
   • Attacker Node: Meshtastic device (e.g., T-Beam, RAK4631) with custom firmware.
   • Victim Node: Standard Meshtastic device running vulnerable firmware (< 2.7.6).
   • Observer Node: Another Meshtastic device to monitor traffic.
2. Software:
   • Meshtastic Python CLI or custom script to craft and send raw packets.
   • Wireshark with Meshtastic dissector to analyze traffic.

Exploitation Steps:

1. Reconnaissance: Use the observer node to capture a legitimate NodeInfo from the victim. Extract the victim's NodeID (e.g., !a1b2c3d4).
2. Craft Malicious NodeInfo: Using the Meshtastic Python library, create a NodeInfo protobuf message:

   from meshtastic import mesh_pb2, portnums_pb2
   from meshtastic.tcp_interface import TCPInterface
   
   # Connect to attacker node
   interface = TCPInterface(hostname='192.168.1.100')
   
   # Craft malicious NodeInfo
   node_info = mesh_pb2.NodeInfo()
   node_info.num = 0xa1b2c3d4  # Victim's NodeID
   node_info.user.id = "!a1b2c3d4"
   node_info.user.long_name = "HAM_VICTIM"
   node_info.user.short_name = "HAM"
   node_info.user.ham_mode = True  # Force HAM mode
   node_info.position.latitude_i = 0
   node_info.position.longitude_i = 0
   
   # Send the forged NodeInfo
   interface.sendData(node_info, portnum=portnums_pb2.PortNum.NODEINFO_APP)
   

3. Persistence: Run a loop to re-send the forged NodeInfo every few seconds to overwrite the victim's legitimate broadcasts.
4. Interception: Now, any direct message sent to the victim will be encrypted with the shared channel key. The attacker can decrypt these messages if they know the key.

Blue Team (Defender)

Objective: Detect and mitigate the NodeInfo forgery attack.

Detection:

1. Monitor NodeDB Changes: Log all NodeDB updates. Look for rapid changes to a node's ham_mode flag or user details.
2. Anomaly Detection: If a node that previously used PKC suddenly switches to HAM mode, it is a strong indicator of an attack.
3. Frequency Analysis: An attacker must broadcast frequently to maintain the forgery. Monitor for an unusually high rate of NodeInfo messages from a single NodeID.

Mitigation:

1. Patch Firmware: Update all nodes to version 2.7.6 or later.
2. Disable HAM Mode: If HAM mode is not required, disable it in the firmware configuration.
3. Use Strong Channel Keys: If HAM mode must be used, ensure the shared channel key is strong and not default.
4. Network Segmentation: Isolate critical nodes on a separate mesh with a different channel key.

Indicators of Compromise (IOCs)

• Network Traffic:
  • Anomalously high frequency of NodeInfo messages from a single NodeID (e.g., >1 per second).
  • NodeInfo messages where ham_mode is true for a node that previously had it false.
  • NodeInfo messages with inconsistent user details (e.g., long name changes rapidly).
• NodeDB State:
  • A node's ham_mode flag is true when it should be false.
  • A node's long name or short name has been changed without user action.
• Logs:
  • Repeated entries of "NodeDB updated" for the same NodeID with different parameters.
  • Logs indicating a node has switched from PKC to shared key encryption.

Detection Engineering

YARA Rule

rule Meshtastic_NodeInfo_Forgery {
    meta:
        description = "Detects forged NodeInfo messages in Meshtastic traffic"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-55292"
    strings:
        $node_info_header = { 08 ?? ?? ?? ?? 12 ?? 0a ?? 12 ?? 1a ?? 20 ?? 28 ?? 30 ?? 38 ?? 40 ?? 48 ?? 50 ?? 58 ?? 60 ?? 68 ?? 70 ?? 78 } // Protobuf NodeInfo pattern
        $ham_mode_true = { 20 01 } // ham_mode = true
        $node_id_pattern = /!([a-f0-9]{8})/ // NodeID pattern
    condition:
        $node_info_header and $ham_mode_true and #node_id_pattern > 0
}

Sigma Rule

title: Meshtastic NodeInfo Forgery Detection
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects rapid changes to NodeInfo in Meshtastic network logs
author: Valters IT
date: 2025-04-10
logsource:
    category: application
    product: meshtastic
detection:
    selection:
        event: "NodeDB updated"
        node_id: "*"
    timeframe: 10s
    condition: selection | count() by node_id > 5
falsepositives:
    - Legitimate rapid reconfiguration of a node
level: high

Suricata Rule

alert udp any any -> any any (msg:"CVE-2025-55292 Meshtastic NodeInfo Forgery"; content:"|08|"; depth:1; content:"|12|"; distance:1; within:100; content:"|20 01|"; distance:0; within:2; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action: Upgrade all Meshtastic nodes to firmware version 2.7.6 or later. This is the only definitive fix.
2. Workaround (if patching is not possible):
   • Disable HAM mode on all nodes if it is not required for regulatory compliance.
   • Use a strong, non-default shared channel key to make decryption harder for the attacker.
   • Monitor the network for the IOCs listed above and isolate any compromised nodes.
3. Long-Term Measures:
   • Implement a cryptographic binding between NodeID and public key in all future firmware versions.
   • Add rate-limiting for NodeInfo messages to prevent rapid forgery attempts.
   • Introduce a mechanism for nodes to report and blacklist forged NodeInfo messages.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Analyst