CVE-2025-55293: Meshtastic Firmware Auth Bypass Vulnerability

CVE-2025-55293 Overview

Meshtastic is an open source mesh networking solution that enables long-range, low-power communication using LoRa radio technology. A critical authentication bypass vulnerability was identified in Meshtastic firmware prior to version 2.6.3 that allows attackers to overwrite legitimate public keys stored in the NodeDB, potentially enabling impersonation attacks and compromising the security of mesh network communications.

The vulnerability exists in the NodeInfo handling logic where an attacker can send a NodeInfo message with an empty publicKey first, which bypasses the validation check if (p.public_key.size > 0) {. This clears the existing public key for a known node. Subsequently, the attacker can send a second NodeInfo message with a malicious key that bypasses the check if (info->user.public_key.size > 0) {, resulting in the malicious key being stored in the NodeDB.

Critical Impact

This vulnerability allows remote attackers without authentication to overwrite cryptographic public keys in the mesh network's node database, potentially enabling man-in-the-middle attacks, node impersonation, and complete compromise of encrypted communications between mesh network participants.

Affected Products

• Meshtastic Firmware versions prior to 2.6.3
• All Meshtastic devices running vulnerable firmware versions
• Mesh networks utilizing PKI-based node authentication

Discovery Timeline

• 2025-08-18 - CVE-2025-55293 published to NVD
• 2025-10-17 - Last updated in NVD database

Technical Details for CVE-2025-55293

Vulnerability Analysis

This authentication bypass vulnerability stems from a logic flaw in the public key validation sequence within the Meshtastic firmware's NodeDB component. The firmware processes incoming NodeInfo packets containing user identity and cryptographic information for nodes in the mesh network.

The vulnerable code path allows a two-step attack: first, an attacker sends a NodeInfo packet with public_key.size set to 0, which bypasses the outer conditional check and results in the existing public key being cleared from the node's record. Once the target node's key is cleared, a subsequent packet containing a malicious public key passes through the inner validation check (which only prevents overwrites when a key already exists), allowing the attacker's key to be persisted in the NodeDB.

This attack enables complete identity takeover within the mesh network, as subsequent encrypted communications intended for the legitimate node will use the attacker's public key, facilitating decryption and potential message injection attacks.

Root Cause

The root cause is a flawed conditional logic structure in src/mesh/NodeDB.cpp that improperly nests the key existence check within the incoming key size check. This allows a race condition where clearing a key (via empty packet) and setting a new key (via malicious packet) are not atomically protected. The original code only checked if an existing key was present when the incoming packet also contained a key, creating a window for the two-step attack.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker within radio range of the mesh network can:

1. Monitor mesh traffic to identify target node IDs
2. Craft a NodeInfo packet with the target's node ID and an empty publicKey field
3. Transmit this packet to clear the victim's stored public key
4. Send a second NodeInfo packet with the target's node ID containing the attacker's public key
5. All future encrypted communications to the target node will use the attacker's key

// Vulnerable code path in src/mesh/NodeDB.cpp (before patch)
// Source: https://github.com/meshtastic/firmware/commit/cf7f0f9d0895602df3453a4f5cfea843f4e09744

 #if !(MESHTASTIC_EXCLUDE_PKI)
     if (p.public_key.size > 0) {
         printBytes("Incoming Pubkey: ", p.public_key.bytes, 32);
-        if (info->user.public_key.size > 0) { // if we have a key for this user already, don't overwrite with a new one
-            LOG_INFO("Public Key set for node, not updating!");
-            // we copy the key into the incoming packet, to prevent overwrite
-            memcpy(p.public_key.bytes, info->user.public_key.bytes, 32);
-        } else {
-            LOG_INFO("Update Node Pubkey!");
-        }
+    }
+    if (info->user.public_key.size > 0) { // if we have a key for this user already, don't overwrite with a new one
+        LOG_INFO("Public Key set for node, not updating!");
+        // we copy the key into the incoming packet, to prevent overwrite
+        p.public_key.size = 32;
+        memcpy(p.public_key.bytes, info->user.public_key.bytes, 32);
+    } else if (p.public_key.size > 0) {
+        LOG_INFO("Update Node Pubkey!");
     }
 #endif

Source: GitHub Firmware Commit Update

Detection Methods for CVE-2025-55293

Indicators of Compromise

• Unexpected public key changes for established nodes in the mesh network
• Multiple NodeInfo packets from the same node ID in rapid succession with varying key states
• NodeInfo packets with empty publicKey fields targeting known nodes
• Sudden changes in encrypted communication patterns or decryption failures

Detection Strategies

• Monitor NodeDB logs for "Update Node Pubkey!" messages for nodes that should have established keys
• Implement alerting for NodeInfo packets where public_key.size equals 0
• Track and alert on public key changes for nodes after initial key establishment
• Deploy network monitoring to detect suspicious patterns of NodeInfo packet sequences

Monitoring Recommendations

• Enable verbose logging on Meshtastic devices to capture all NodeInfo processing events
• Implement out-of-band key verification mechanisms for critical mesh network nodes
• Regularly audit NodeDB entries to verify public key integrity against known-good values
• Consider implementing key pinning or certificate transparency-like logging for mesh networks

How to Mitigate CVE-2025-55293

Immediate Actions Required

• Upgrade all Meshtastic devices to firmware version 2.6.3 or later immediately
• Audit current NodeDB entries to identify any potentially compromised public keys
• Re-establish PKI trust by verifying and updating public keys through trusted channels
• Isolate unpatched devices from critical mesh network segments until updates can be applied

Patch Information

Meshtastic has released firmware version 2.6.3 which addresses this vulnerability. The fix restructures the conditional logic to ensure that existing public keys are always preserved regardless of whether the incoming packet contains a key or not. The patched code moves the existing key check outside the incoming key size conditional, ensuring that once a node has an established public key, it cannot be cleared or overwritten by subsequent NodeInfo packets.

For detailed information about the security fix, refer to:

• GitHub Security Advisory GHSA-95pq-gj5v-4fg2
• GitHub Firmware Pull Request
• GitHub Firmware Commit Update

Workarounds

• If immediate patching is not possible, consider disabling PKI features temporarily using the MESHTASTIC_EXCLUDE_PKI compile flag
• Implement network segmentation to limit the blast radius of potential attacks
• Use additional out-of-band authentication mechanisms for sensitive communications
• Monitor for firmware updates and apply patches as soon as devices can be safely updated

# Configuration example - Verify current firmware version via CLI
meshtastic --info | grep "Firmware Version"

# Update firmware to patched version 2.6.3 or later
meshtastic --firmware-update

# Verify NodeDB integrity after patching
meshtastic --nodes