Skip to content

Forged DMs with no PKC show up as encrypted

Moderate
jp-bennett published GHSA-377p-prwp-4hwf Dec 29, 2025

Package

No package listed

Affected versions

<2.7.15

Patched versions

2.7.15

Description

Summary

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.

Details

When the firmware receives a direct message over LoRa or MQTT on numport 4 TEXT_MESSAGE_APP:

  • If the the firmware decrypts the payload using the node’s asymmetric PKI keys, the pki_encrypted flag in the MeshPacket is set to true.
  • If the asymmetric decryption fails, the firmware falls back to legacy AES-256-CTR decryption using the symmetric channel key, and If the pki_encrypted flag remains set to false.

This fallback mechanism allows attackers who know the symmetric channel key (which is shared by all members of a channel, and trivially known in the case of default/public channels) to craft spoofed direct messages:

  • Encrypt the message payload using the channel’s symmetric AES-256-CTR key.
  • Injects the crafted packet over LoRa or MQTT.

The receiving node will accept and display the message as a valid direct message. On-device user interfaces (e.g., OLED displays, MUI) do not differentiate between PKI and legacy decryption, giving the recipient no way to verify the authenticity of the message.

This effectively enables a downgrade attack, where the security of direct messages can be bypassed by forcing legacy encryption.

The decision of whether a DM was decrypted with PKI or legacy encryption is left to the UI, with the flag pki_encrypted. This means legacy DMs can appear as secure PKI messages if UI does not implement safe handling. A safer design would be for the firmware to enforce PKI by default and only allow legacy DMs if explicitly enabled for known legacy nodes.

The fix in 2.7.15 was to disallow legacy DMs at the firmware level.

PoC

  • Create a channel where the victim node is present.
  • Craft a MeshPacket addressed to the victim node without setting the pki_encrypted flag.
  • Encrypt a TEXT_MESSAGE_APP payload with the known AES-256-CTR channel key.
  • Send the packet via LoRa or MQTT.
  • Observe that the victim’s firmware decrypts and accepts the message as a direct message, with no on-device indication that legacy encryption was used.
imagen imagen

Impact

Type: Downgrade Attack / Spoofing / Identity Impersonation
Affected: All Meshtastic firmware users (>= v2.5 and < v2.7.15) relying on PKI for direct message security.
Severity: Moderate – Enables detectable spoofing of direct messages, and breaks PKI security guarantees and allowing impersonation of any node.
Exploitability: Trivial on public/default channels with widely known keys.

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

CVE ID

CVE-2025-53627

Weaknesses

Improper Validation of Specified Type of Input

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. Learn more on MITRE.

Credits