A walkie-talkie firmware bug rated the same as a domain controller RCE
CVE-2026-44359 is a CWE-94 code injection flaw in Meshtastic, the open-source LoRa-based off-grid mesh messaging project. The advisory carries a network-reachable, no-auth, no-UI vector with scope change and high confidentiality+integrity impact — meaning a crafted packet arriving on a node's radio or serial/BLE/MQTT ingress can execute attacker-controlled logic on the device. Affected versions span the current firmware line prior to the vendor's patch release; exact fixed build should be confirmed against the upstream meshtastic/firmware advisory once published.
The vendor's CRITICAL 10.0 rating reflects the raw CVSS math (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H). That math is technically defensible but wildly overstates enterprise blast radius: Meshtastic runs on ESP32/nRF52 handheld radios carried by preppers, ham operators, and hikers. It is not identity, not hypervisor, not edge, not backup. In a typical Fortune-500 environment the installed base is effectively zero, and where it does exist it's shadow-IT on personal devices. Vendor severity mismatches practitioner reality by a full two buckets.
4 steps from start to impact.
Reach a Meshtastic node's ingress
mqtt.meshtastic.org are the only truly remote path.- RF range or MQTT bridge reachability
- Knowledge of channel/PSK for encrypted channels, or targeting the default public channel
- LoRa is physical-proximity limited (typically <10km line-of-sight)
- Enterprise networks rarely bridge to public Meshtastic MQTT
- Encrypted private channels require the pre-shared key
Deliver malformed packet triggering CWE-94
meshtastic CLI library.- Working exploit for the specific parser path
- Packet accepted on default or known channel
- No public PoC observed at time of assessment
- Requires reverse-engineered protocol knowledge
Execute on the microcontroller
- Successful memory-safe or eval-style injection
- MCU does not hard-fault
- Device is not a pivot point into enterprise LAN unless MQTT-bridged
- Blast radius = one radio + any paired phone via BLE
Impact — mesh takeover or message forgery
- Compromised node participates in a live mesh
- Impact contained to the Meshtastic mesh community, not enterprise assets
Meshtastic Android/iOS/desktop app to identify who in your workforce operates a node. No mitigation SLA applies to a MEDIUM verdict — complete this inventory in the normal 365-day remediation window; if any executive-protection or field-ops team relies on Meshtastic, promote those units to CRITICAL handling and mitigate within 3 days per the noisgate CRITICAL SLA.mqtt.enabled = false. This eliminates the only truly remote attack path, leaving only RF-proximity risk. Apply opportunistically alongside next firmware push.meshtastic/firmware GitHub release feed and roll the fixed build to any inventoried nodes within the 365-day remediation window.- Network firewall rules — Meshtastic's primary transport is sub-GHz LoRa, invisible to your NGFW.
- EDR — endpoint agents do not run on ESP32/nRF52 microcontrollers.
- Standard vuln scanners — Tenable/Qualys/Rapid7 have no plugin coverage for Meshtastic firmware or MQTT bridges.
- WAF or reverse proxy — no HTTP surface is involved.
The supporting signals.
| In-the-wild exploitation | None observed. Not in CISA KEV. No campaign attribution. |
|---|---|
| Public PoC | None indexed on GitHub / ExploitDB at time of assessment. |
| EPSS | Not yet scored (CVE disclosed 2026-07-20); expected <1st percentile given niche installed base. |
| KEV status | Not listed. |
| CVSS v3.1 vector | AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N → 10.0. Network vector is theoretically fair (MQTT bridge) but overwhelmingly LoRa-proximity in practice. |
| Affected component | meshtastic/firmware — ESP32/nRF52 LoRa mesh radios. |
| Fixed version | Refer to upstream GHSA advisory — patched build not yet resolvable at assessment time. |
| Exposure telemetry | Shodan / Censys do not enumerate Meshtastic MQTT bridges as a distinct product; enterprise exposure is *de facto* zero. |
| Disclosure date | 2026-07-20 |
| Deployment class | Hobbyist / off-grid comms. Not an identity, hypervisor, backup, edge, or CI/CD asset. |
Sources.
- Meshtastic firmware security advisories (GHSA)
- Meshtastic firmware repository
- MITRE CWE-94: Improper Control of Generation of Code
- CISA Known Exploited Vulnerabilities Catalog
- Meshtastic Android advisory example (GHSA-h4rg-g6f3-ghh7)
- circl.lu Meshtastic vulnerability index
- Meshtastic MQTT documentation
- FIRST EPSS
Why this verdict
- Installed-base collapse: Meshtastic is not part of any standard enterprise software bill of materials. Corporate exposure is effectively zero except for personal devices employees bring in.
- Blast radius floor stays at MEDIUM: No high-value role exists for this component — it is not an IdP, hypervisor, backup, PAM, CA, kernel-mode agent, or edge appliance. The Deployment-Role Blast Radius rule does not push the floor above MEDIUM because Meshtastic occupies role (a) low-value in every plausible enterprise scenario.
- Physical-proximity friction: The 'network' vector is dominated by LoRa RF at hobbyist power levels; true remote reach requires an opt-in MQTT bridge that enterprises do not deploy.
- No exploitation signal: Not KEV-listed, no public PoC, EPSS not scored, no observed campaigns.
- Role multiplier: N/A — no high-value role exists for LoRa mesh radios in enterprise environments.
Why not higher?
A HIGH rating would require either enterprise-relevant deployment role or observed exploitation. Neither exists. The vendor CRITICAL is a mechanical CVSS artifact of a network-reachable, unauthed RCE vector — but the reachable population inside an enterprise perimeter rounds to zero.
Why not lower?
LOW / IGNORE would be wrong for security teams that support field operations, journalists, first responders, or executive protection details where Meshtastic *is* the primary comms channel. For those specific programs the impact of a forged or intercepted message is real and warrants tracking.
Crowdsourced verification payload.
Run on an auditor workstation with read access to your MDM/EDR software inventory export (CSV). Invoke as .\Check-Meshtastic.ps1 -InventoryCsv .\endpoint_apps.csv. No elevated privileges required — this is a discovery script, not a firmware probe.
#requires -Version 5.1
<#
.SYNOPSIS
Discovers Meshtastic client/app presence in an endpoint inventory export.
.NOTES
Exit codes: 0 = PATCHED (none found), 1 = VULNERABLE (Meshtastic present), 2 = UNKNOWN
#>
param(
[Parameter(Mandatory=$true)][string]$InventoryCsv
)
if (-not (Test-Path $InventoryCsv)) {
Write-Output 'UNKNOWN: inventory CSV not found'
exit 2
}
try {
$rows = Import-Csv -Path $InventoryCsv
} catch {
Write-Output 'UNKNOWN: failed to parse CSV'
exit 2
}
# Expect columns like: Hostname, AppName, AppVersion
$hits = $rows | Where-Object {
$_.AppName -match '(?i)meshtastic'
}
if ($hits.Count -gt 0) {
Write-Output "VULNERABLE: Meshtastic app found on $($hits.Count) endpoint(s)"
$hits | Select-Object Hostname, AppName, AppVersion | Format-Table -AutoSize
exit 1
}
Write-Output 'PATCHED: no Meshtastic client detected in inventory'
exit 0