CVE-2025-55293 is a critical authentication flaw in Meshtastic firmware before version 2.6.3. A NodeInfo message with an empty public key clears the stored key for a known node, and a second message then stores a key the attacker chose. The fix is firmware 2.6.3.
What's affected
- Product: Meshtastic, an open source mesh networking project, specifically its device firmware.
- Affected: versions before 2.6.3.
- Fixed: 2.6.3.
- Mechanism per the advisory: the update logic skips its protection when an incoming NodeInfo has an empty public key, which clears the stored key and resets its size to zero. A later NodeInfo with a new key then passes the "no key stored" check and is saved in the node database.
The advisory quotes the code in NodeDB.cpp where the first check is bypassed. The project's own comment in that code says that if a key exists for a user already, the firmware does not overwrite it. The flaw is that an empty key defeated that rule.
The same fix is included in the project's pull request 6372, listed in the record.
How to check if you're exposed
Check the firmware version on each device. The Meshtastic app shows it on the device page, and the command line tool prints it in its device information output.
meshtastic --info
Look for the firmware version field and compare it with 2.6.3. Do this for every node, including routers and repeaters placed on rooftops or in the field, since those are the easiest to forget. If you manage a fleet, keep a list of node IDs with their firmware versions.
After updating, review the list of known nodes and their public keys on key devices. If you see a node whose key changed unexpectedly, treat that as a sign of tampering and remove and re-add the node.
What to do now
- Update every device to Meshtastic firmware 2.6.3 or later.
- Prioritize infrastructure nodes, such as routers and repeaters, since they relay traffic for others.
- After updating, check the known node list for keys that do not match what you expect, and remove suspicious entries.
- For private channels, rotate channel keys if you suspect someone interfered with direct messages.
- Do not rely on direct message encryption between nodes for sensitive information until your mesh is fully updated.
Why it matters
The weakness is improper authentication. Public key cryptography only protects a conversation if you hold the right key for the other party. If a stranger can replace the stored key of a node you already know, messages meant for that node can be encrypted to the attacker, and messages claiming to come from it can be signed as the attacker.
The bug here is a logic gap, not broken cryptography. The code had one rule, never overwrite an existing key, and a path that cleared the key first made the rule moot. Checks that depend on state need to consider every way the state can change. The vector shows network reach with no privileges, which for a radio mesh means anyone within range of a node. The CVE is not on the CISA KEV list.
The weakness is classed as CWE-287 (Improper Authentication). Severity in the CVE record: critical, CVSS 9.4 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L).
Quick check
Which version fixes it?
Meshtastic firmware 2.6.3. Versions before it are affected.
How do I spot tampering after updating?
Review the known node list for keys that changed unexpectedly. If one did, remove the node and add it again from a trusted source.
Sources
- GitHub advisory GHSA-95pq-gj5v-4fg2
- Pull request 6372 (listed in the CVE record, not fetched)
Last reviewed: 18 October 2026.
