Meshtastic Firmware
CVE-2025-53627
MEDIUM
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain shared channel key
-
DeliveryCraft DM lacking pki_encrypted flag
-
ExploitInject spoofed message into mesh
-
ExecutionFirmware falls back to legacy AES-CTR
-
ImpactVictim app displays it as PKI-encrypted
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V2 - Validation and Business Logic Specified type validation
|
| Exploitation Conditions | Exploitation requires the attacker to possess a valid shared channel key for a channel the victim participates in; with that key the adversary crafts a direct message that omits the pki_encrypted flag, causing firmware (version 2.5 through before 2.7.15) to silently fall back to legacy AES-256-CTR decryption while end-user apps (Web, iOS, Android, SDK-based) display it as if PKI-encrypted. The principal limiting factor is knowledge of the shared channel key - though for the default/public channel this key is well-known, lowering the barrier - and the impact is confined to spoofing/impersonation and loss of end-to-end-encryption assurance, with no confidentiality or availability consequence. Affected deployments are those running vulnerable firmware prior to 2.7.15 together with client apps lacking PKI-versus-legacy indication. |
| Impact | This is a moderate-severity integrity flaw, not a high-urgency priority. The provided CVSS of 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) reflects a network-reachable, low-complexity attack with no privileges or user interaction, but impact is limited to partial integrity (I:L) with no confidentiality or availability loss - consistent with a message-spoofing/downgrade weakness rather than code execution. A public exploit exists (GitHub Security Advisory GHSA-377p-prwp-4hwf is flagged as an exploit reference), so publicly available exploit code exists; however this is NOT active exploitation - the CVE is not in CISA KEV, so treat POC availability and exploitation as distinct signals. No EPSS score and no SSVC decision data were provided, so automatability and widespread-exploitation probability cannot be quantified from this input. A key caveat: although the CVSS vector encodes PR:N (unauthenticated), the description makes clear that exploitation requires the adversary to already know a shared channel key - this is a real material precondition that the CVSS base metrics understate, so the practical attacker barrier is higher than PR:N alone suggests. |
| Exploit ScenarioDerived | An attacker who already possesses a Meshtastic channel's shared symmetric key (e.g., the well-known default channel key or a leaked group key) crafts a direct message that omits the pki_encrypted flag. The firmware silently decrypts it with legacy AES-256-CTR and the victim's app renders it indistinguishably from a genuine PKI end-to-end-encrypted DM, letting the attacker impersonate another user. A public proof of concept is referenced in the GitHub advisory. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 05, 2026
Direct-message spoofing in Meshtastic firmware versions 2.5 through before 2.7.15 lets an attacker who knows a shared channel key inject direct messages that client apps display as PKI-encrypted, even though the firmware silently decrypted them using legacy AES-256-CTR channel encryption. Affected clients, including the Web, iOS, Android, and SDK-based applications, offer no indication of whether a DM was protected by PKI or by the legacy symmetric scheme, so users cannot distinguish genuine end-to-end encrypted messages from spoofed ones and the integrity and assurance guarantees of the PKI rollout are undermined. Publicly available exploit code exists, but there is no confirmation of active exploitation; with a CVSS of 5.3 and an integrity-only impact, this is a moderate-severity issue rather than a high-urgency one, though the barrier is lower on the default public channel whose shared key is well-known.
RemediationAI
Upgrade all Meshtastic nodes to firmware 2.7.15 or later, which the vendor advisory at https://github.com/meshtastic/firmware/security/advisories/GHSA-377p-prwp-4hwf identifies as the release that resolves the silent downgrade and gives applications a way to distinguish PKI from legacy direct messages. Upgrading the firmware alone does not remove the attack surface if the client software still presents legacy DMs as PKI-protected, so pair it with current versions of the Web, iOS, Android, or SDK-based client. As a compensating control, stop relying on the default public channel for sensitive direct messages and replace it with private channels using high-entropy pre-shared keys, then rotate those keys if any member may have been compromised; the trade-off is that every channel participant must be reconfigured and stale nodes will be unable to communicate until updated. Restricting the physical and RF exposure of nodes reduces but does not eliminate the risk, because the attack requires only knowledge of a channel key, not proximity or an authenticated session.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Meshtastic is an open-source LoRa-based mesh networking solution in which nodes relay messages over shared channels. Firmware 2.5 introduced PKI-based asymmetric encryption for direct messages, giving DMs end-to-end confidentiality and sender authenticity independent of the channel key. To preserve backward compatibility, firmware falls back to the legacy AES-256-CTR channel encryption whenever a received DM lacks the pki_encrypted flag, and the flag itself is not surfaced to the end-user applications. The root cause is CWE-1287 (Improper Validation of Specified Type of Input): the receiver trusts the absence of a type/format indicator instead of enforcing that a DM claiming PKI protection was actually PKI-encrypted, which is a classic algorithm-downgrade pattern. Any party that holds the shared channel key, including the well-known default public channel key, can therefore craft a DM that omits the flag, have it decrypted and accepted by the firmware under the legacy scheme, and have it rendered by the client as an ordinary PKI-protected direct message. CPE cpe:2.3:o:meshtastic:meshtastic_firmware:*:*:*:*:*:*:*:* covers the affected firmware line.
Know when Meshtastic Firmware gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Spoofed DMs travel over the mesh network (AV:N) with no device authentication (PR:N); impact is limited to message integrity/impersonation (I:L), with no confidentiality or availability effect.
Primary rating from Vendor (github).
CVSS VectorVendor: github
DescriptionCVE.org
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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Affected Products (CPE)CVE.org
More in Meshtastic Firmware
View allMeshtastic is an open source mesh networking solution. In the current Meshtastic architecture, a Node is identified by t
Meshtastic is an open source mesh networking solution. Prior to 2.5.1, traceroute responses from the remote node are not
Meshtastic is an open source, off-grid, decentralized, mesh network. Rated critical severity (CVSS 9.8), this vulnerabil
Meshtastic is an open source mesh networking solution. Rated critical severity (CVSS 9.4), this vulnerability is remotel
A remote code execution vulnerability in versions from 2.5.0 to (CVSS 8.3). High severity vulnerability requiring prompt
Meshtastic is an open source mesh networking solution. From 1.2.1 until 2.6.2, a packet sent to the routing module that
Meshtastic firmware is a device firmware for the Meshtastic project. Rated high severity (CVSS 7.5), this vulnerability
Meshtastic device firmware is a firmware for meshtastic devices to run an open source, off-grid, decentralized, mesh net
Meshtastic is an open source, off-grid, decentralized, mesh network built to run on affordable, low-power devices. Rated
Meshtastic is an open source mesh networking solution. Rated medium severity (CVSS 5.3), this vulnerability is remotely
Meshtastic is an open source mesh networking solution. The main_matrix.yml GitHub Action is triggered by the pull_reques
Meshtastic is an open source mesh networking solution. Rated critical severity (CVSS 9.4), this vulnerability is remotel
NVD
CVE.org
EPSS
GitHub
Exploit-DB