CVE-2025-53627

Executive Summary

CVE-2025-53627 is a downgrade attack vulnerability in Meshtastic firmware versions 2.5.0 through 2.7.14. The vulnerability arises from an intentional design decision to maintain backward compatibility: when the pki_encrypted flag is missing from a direct message (DM), the firmware silently falls back to legacy AES-256-CTR channel encryption. However, end-user applications (Web, iOS, Android, and SDK-based apps) lack the ability to differentiate between end-to-end PKI-encrypted DMs and legacy-encrypted DMs. This allows an adversary who knows the shared channel key to craft and inject spoofed DMs that appear to be PKI-encrypted, undermining the security guarantees of the PKI rollout. The vulnerability is rated CVSS 5.3 (Medium) and has a 0.0% EPSS score, indicating low exploitation likelihood. The fix is available in firmware version 2.7.15.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It affects the Meshtastic firmware binary and its associated end-user applications (Web, iOS, Android, SDK). The supply chain risk is limited to the firmware distribution channels (GitHub releases, Meshtastic Flasher, etc.). Users should verify the integrity of downloaded firmware using checksums provided by the Meshtastic project.

CVSS Breakdown & Threat Level

• CVSS Score: 5.3 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
• Attack Vector (AV): Network (N) – The attack can be launched over the mesh network.
• Attack Complexity (AC): Low (L) – No special conditions required beyond knowing the shared channel key.
• Privileges Required (PR): None (N) – The attacker does not need any privileges on the target device.
• User Interaction (UI): Required (R) – The victim must receive and view the spoofed DM.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): None (N) – No data is disclosed.
• Integrity (I): Low (L) – The attacker can inject spoofed messages, but cannot modify existing messages.
• Availability (A): None (N) – No denial of service.

Threat Level: Medium. The attack requires knowledge of the shared channel key, which limits the pool of potential attackers to those who have already compromised the channel. However, the impact is a downgrade of security guarantees, potentially leading to social engineering or misinformation.

Deep Dive & Mechanics

The Meshtastic firmware (starting from version 2.5) introduced asymmetric encryption (PKI) for direct messages to provide end-to-end security. The protocol uses a pki_encrypted flag in the message header to indicate that the payload is encrypted with the recipient's public key. However, to maintain backward compatibility with older devices that do not support PKI, the firmware includes a fallback mechanism: if the pki_encrypted flag is missing or set to false, the firmware decrypts the message using the legacy AES-256-CTR channel encryption (which uses a shared channel key).

The vulnerability lies in the fact that end-user applications (Web, iOS, Android, and SDK-based apps) do not check the pki_encrypted flag when displaying messages. They treat all decrypted messages as equally trustworthy, regardless of the encryption method used. This allows an attacker who knows the shared channel key to:

1. Craft a direct message with the pki_encrypted flag set to false (or omitted).
2. Encrypt the payload using the legacy AES-256-CTR channel encryption.
3. Inject the message into the mesh network.
4. The recipient's firmware decrypts the message using the legacy method.
5. The end-user application displays the message without indicating that it was not PKI-encrypted.

The attacker can spoof the sender's identity because the legacy encryption does not provide sender authentication. The message will appear to come from any node ID the attacker chooses.

Vulnerable vs. Patched Code

Vulnerable Code (Firmware < 2.7.15):

The firmware's message handling logic does not propagate the pki_encrypted flag to the application layer. The decryption function returns the plaintext without indicating the method used.

// Vulnerable pseudocode
bool decrypt_message(uint8_t *ciphertext, size_t len, uint8_t *plaintext, bool *pki_encrypted) {
    if (*pki_encrypted) {
        // Attempt PKI decryption
        if (pki_decrypt(ciphertext, len, plaintext)) {
            return true;
        }
        // Fallback to legacy if PKI fails
        *pki_encrypted = false;
    }
    // Legacy decryption
    return aes256_ctr_decrypt(ciphertext, len, plaintext, channel_key);
}

Patched Code (Firmware >= 2.7.15):

The patched firmware ensures that the pki_encrypted flag is preserved and passed to the application layer. The application can then display a visual indicator (e.g., a lock icon) to show whether the message was PKI-encrypted.

// Patched pseudocode
bool decrypt_message(uint8_t *ciphertext, size_t len, uint8_t *plaintext, bool *pki_encrypted) {
    if (*pki_encrypted) {
        if (pki_decrypt(ciphertext, len, plaintext)) {
            return true;
        }
        // PKI decryption failed, do not fallback
        return false;
    }
    // Legacy decryption
    return aes256_ctr_decrypt(ciphertext, len, plaintext, channel_key);
}

Additionally, the end-user applications now check the pki_encrypted flag and display a visual indicator (e.g., a lock icon) to inform the user of the encryption method.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Knowledge of the shared channel key (e.g., obtained through prior compromise or social engineering).
• A Meshtastic device or software capable of injecting messages into the mesh network (e.g., using the Meshtastic Python API).
• Target device running firmware version 2.5.0 to 2.7.14.

Exploitation Steps:

1. Obtain the shared channel key. This can be done by:

   • Compromising a node that has the key.
   • Social engineering a user to share the key.
   • Brute-forcing weak keys (unlikely).

2. Craft a spoofed direct message. Using the Meshtastic Python API:

import meshtastic
from meshtastic import mesh_pb2, portnums_pb2

# Connect to a local node
interface = meshtastic.SerialInterface(devPath='/dev/ttyUSB0')

# Create a direct message
dm = mesh_pb2.Data()
dm.portnum = portnums_pb2.PortNum.TEXT_MESSAGE_APP
dm.payload = b"Spoofed message from trusted source"

# Set the destination node ID
dm.to = 0x12345678  # Target node ID

# Do NOT set the pki_encrypted flag (or set it to false)
# The firmware will fallback to legacy encryption

# Encrypt with the shared channel key
# (This is handled automatically by the firmware when sending)

# Send the message
interface.sendData(dm, destinationId=0x12345678)

3. Inject the message. The message will be broadcast over the mesh network and decrypted by the target using the legacy AES-256-CTR encryption.

4. Observe the result. The target's end-user application will display the message without any indication that it was not PKI-encrypted.

Blue Team

Detection:

• Monitor for direct messages that lack the pki_encrypted flag but are addressed to nodes that support PKI.
• Look for anomalies in the mesh network, such as messages from nodes that are not in the expected routing table.

Mitigation:

• Upgrade all nodes to firmware version 2.7.15 or later.
• After upgrading, configure end-user applications to display a visual indicator (e.g., a lock icon) for PKI-encrypted messages.
• Educate users to verify the encryption indicator before trusting a message.

Hunting:

• Use the following YARA rule to scan firmware binaries for the vulnerable fallback logic:

rule CVE_2025_53627_Vulnerable_Fallback {
    meta:
        description = "Detects vulnerable Meshtastic firmware with silent fallback to legacy encryption"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-53627"
    strings:
        $fallback = "pki_encrypted" nocase
        $aes_ctr = "AES-256-CTR" nocase
    condition:
        $fallback and $aes_ctr
}

Indicators of Compromise (IOCs)

• Network IOCs:
  • Direct messages with the pki_encrypted flag set to false or missing, but addressed to nodes that support PKI.
  • Messages from nodes that are not in the expected routing table.
• Host IOCs:
  • Firmware versions 2.5.0 through 2.7.14.
  • End-user applications that do not display an encryption indicator for direct messages.
• Log IOCs:
  • Log entries showing decryption fallback to legacy AES-256-CTR.

Detection Engineering

YARA Rule

rule CVE_2025_53627_Vulnerable_Fallback {
    meta:
        description = "Detects vulnerable Meshtastic firmware with silent fallback to legacy encryption"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-53627"
    strings:
        $fallback = "pki_encrypted" nocase
        $aes_ctr = "AES-256-CTR" nocase
    condition:
        $fallback and $aes_ctr
}

Sigma Rule

title: CVE-2025-53627 - Meshtastic Downgrade Attack Detection
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects direct messages in Meshtastic mesh network that lack the pki_encrypted flag, indicating a potential downgrade attack.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-53627
logsource:
    category: network
    product: meshtastic
detection:
    selection:
        - event: "direct_message"
        - pki_encrypted: false
    condition: selection
falsepositives:
    - Legitimate messages from nodes that do not support PKI (pre-2.5 firmware)
level: medium

Suricata Rule

alert tcp any any -> any any (msg:"CVE-2025-53627 - Meshtastic Downgrade Attack"; flow:to_server; content:"|00|"; depth:1; content:"|01|"; within:2; content:"|00 00 00 00|"; distance:2; within:4; content:"|00|"; distance:2; within:1; sid:1000001; rev:1;)

Note: The Suricata rule above is a placeholder. A real rule would need to parse the Meshtastic protocol's binary format, which is complex and beyond the scope of this report. The rule should be tailored to the specific network traffic patterns of the Meshtastic mesh network.

Remediation & Mitigation

Immediate Actions:

1. Upgrade all Meshtastic nodes to firmware version 2.7.15 or later.
2. Update all end-user applications (Web, iOS, Android) to the latest versions that support the pki_encrypted flag display.
3. After upgrading, verify that the end-user application shows a visual indicator (e.g., a lock icon) for PKI-encrypted direct messages.

Long-Term Measures:

1. Implement a mechanism to reject direct messages that lack the pki_encrypted flag when the recipient supports PKI.
2. Educate users about the importance of verifying the encryption indicator before trusting a message.
3. Consider deprecating legacy AES-256-CTR encryption for direct messages in future firmware versions.

Workarounds:

• If upgrading is not immediately possible, disable direct messaging or use a separate channel for sensitive communications.
• Monitor the mesh network for suspicious messages using the detection rules provided.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert