CVE-2025-53627
Unknown Unknown - Not Provided
Encryption Downgrade Vulnerability in Meshtastic Firmware Direct Messages

Publication date: 2025-12-29

Last updated on: 2026-02-26

Assigner: GitHub, Inc.

Description
Meshtastic is an open source mesh networking solution. The Meshtastic firmware (starting from version 2.5) introduces asymmetric encryption (PKI) for direct messages, but when the `pki_encrypted` flag is missing, the firmware silently falls back to legacy AES-256-CTR channel encryption. This was an intentional decision to maintain backwards compatibility. However, the end-user applications, like Web app, iOS/Android app, and applications built on top of Meshtastic using the SDK, did not have a way to differentiate between end-to-end encrypted DMs and the legacy DMs. This creates a downgrade attack path where adversaries who know a shared channel key can craft and inject spoofed direct messages that are displayed as if they were PKC encrypted. Users are not given any feedback of whether a direct message was decrypted with PKI or with legacy symmetric encryption, undermining the expected security guarantees of the PKI rollout. Version 2.7.15 fixes this issue.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-29
Last Modified
2026-02-26
Generated
2026-05-07
AI Q&A
2025-12-29
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
meshtastic meshtastic_firmware From 2.5.0 (inc) to 2.7.15 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-1287 The product receives input that is expected to be of a certain type, but it does not validate or incorrectly validates that the input is actually of the expected type.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

The vulnerability in Meshtastic firmware occurs because when the 'pki_encrypted' flag is missing, the firmware falls back to using legacy AES-256-CTR channel encryption instead of the intended asymmetric PKI encryption for direct messages. However, the end-user applications cannot distinguish between messages encrypted with PKI and those using legacy encryption. This allows attackers who know the shared channel key to perform a downgrade attack by crafting and injecting spoofed direct messages that appear to be securely encrypted with PKI, misleading users about the true security of their messages.


How can this vulnerability impact me? :

This vulnerability can impact users by allowing adversaries who know the shared channel key to inject spoofed direct messages that appear to be securely encrypted with PKI but are actually encrypted with weaker legacy encryption. This undermines the security guarantees of end-to-end encryption, potentially leading to message spoofing and deception without users being aware that the messages are not properly secured.


What immediate steps should I take to mitigate this vulnerability?

Upgrade the Meshtastic firmware to version 2.7.15 or later, which fixes the issue by properly differentiating between PKI encrypted and legacy encrypted direct messages, thereby preventing the downgrade attack.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided resources do not contain information regarding the impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring direct messages (DMs) on numport 4 (TEXT_MESSAGE_APP) over LoRa or MQTT and checking if messages are being decrypted using legacy AES-256-CTR encryption instead of PKI encryption. Specifically, you can capture MeshPackets addressed to your node and inspect whether the pki_encrypted flag is missing or false, indicating fallback to legacy encryption. To detect potential spoofed messages, you can analyze traffic for packets encrypted with the known symmetric channel key but lacking the pki_encrypted flag. Commands would involve capturing LoRa or MQTT traffic on numport 4 and decrypting payloads with both PKI keys and the symmetric AES-256-CTR key to identify fallback decryptions. For example, using a packet capture tool to filter on numport 4 and custom scripts to check the pki_encrypted flag and encryption type. However, no specific commands are provided in the resources. [1]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart