Loading vulnerability…
Meshtastic versions 2.5.0 through 2.6.10 can generate cryptographic key pairs that are duplicated across devices flashed by certain hardware vendors or derived from insufficient entropy because the internal randomness pool is not properly initialized on some platforms. An attacker who has compiled affected private keys can capture and decrypt Direct Messages sent using a compromised key pair.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a Python proof-of-concept simulation for CVE-2025-52464 affecting Meshtastic firmware. It is not a full firmware or radio-stack exploit; instead, it models the vulnerable cryptographic workflow that allows passive decryption of encrypted Direct Messages when a sender uses duplicated or low-entropy X25519 private key material. The core exploit capability is implemented in crypto_engine.py, node.py, and attacker.py: nodes derive X25519 shared secrets, convert them to AES-256 keys with HKDF, and encrypt/decrypt messages with AES-GCM. The attacker class passively decrypts captured packets by loading a compromised private key and deriving the same shared secret with the receiver's public key. simulation.py is the main orchestrator and demonstrates both the vulnerable case, where Mallory successfully decrypts Alice-to-Bob traffic, and the fixed case, where fresh keys prevent decryption. security_checker.py and compromised_keys.py simulate the patched mitigation by hashing public keys and comparing them against a known low-entropy key database. The repository contains 14 files total, mostly Python modules plus tests and a README. Notably, several test scripts call a non-existent Node.encrypt_direct_message method, so the demo path via demo.py/simulation.py appears to be the intended working entry point. No external network, HTTP, DNS, or IP endpoints are contacted; the only fingerprintable artifacts are local file/module names, the HKDF info string, and hardcoded demo strings. Overall, this is a legitimate educational PoC for passive message decryption under weak-key reuse conditions, with no weaponized delivery or remote exploitation components.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
3 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.