Meshtastic is an open source mesh networking solution

Meshtastic is an open-source LoRa mesh networking firmware used primarily by hobbyists, ham radio operators, and off-grid enthusiasts. In firmware versions prior to 2.7.23.b246bcd, a node broadcasting a User.long_name with malformed character encoding — either intentionally or via naturally occurring buffer truncation — poisons the node database that the Meshtastic iOS app synchronizes over BLE. The result: the iOS app enters a Bluetooth sync loop and the user loses control of their radio until the poisoned entry ages out of the mesh.

The vendor CVSS of 7.5 (AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:H) technically fits the mechanics — network-adjacent, no auth, availability-only — but the *deployment reality* is nowhere near HIGH. This isn't running on domain controllers, hypervisors, or production infrastructure. It's running on $30 LoRa boards paired to hobbyist iPhones. The blast radius is 'my mesh radio app is stuck' — not fleet compromise, not data loss, not lateral movement. Vendor math is defensible; enterprise relevance is essentially nil unless you actually deploy Meshtastic operationally.

Why this verdict

• Availability-only, user-recoverable: the CVSS vector itself confirms C:N/I:N; the only impact is an iOS app that has to purge one node entry.
• Attacker must be RF-adjacent to the mesh — no internet-scale reachability, no scanner-driven mass exploitation model.
• Role multiplier — none: Meshtastic is not on the high-value-role catalog (no IdP, hypervisor, PAM, backup, CA, EDR, network edge, SIEM, or OT controller role). Even in the worst deployment (SAR teams, off-grid comms), the chain ends in 'restart the app' — no fleet, tenant, or supply-chain reach.
• Installed base in enterprise ≈ 0% — Shodan/Censys have no visibility because LoRa isn't IP; MDM inventories almost never list Meshtastic. This breaks the CRITICAL/HIGH floor because the affected component is definitionally not enterprise infrastructure.
• Trivial recovery path via Python CLI or aging out the poisoned entry — no persistent state damage.

Why not higher?

HIGH would require either enterprise-relevant blast radius or active exploitation — neither exists. There is no confidentiality or integrity impact, no code execution, and no lateral movement. The vendor's 7.5 is technically CVSS-defensible but ignores that the affected population is essentially not the enterprise fleet noisgate advises on.

Why not lower?

IGNORE would be wrong for the rare organization that *does* deploy Meshtastic operationally — search-and-rescue teams, event comms, some field research programs. For those users the DoS is real and reproducible without exploitation skill, so LOW (not IGNORE) reflects that a fix should still land in the backlog.

1. Inventory whether Meshtastic is actually deployed — Query MDM (Intune / Jamf) for the org.meshtastic.meshtastic iOS bundle and any managed Meshtastic firmware images. If zero installs, close the ticket. No mitigation SLA applies at LOW — this is a discovery task, not a deadline.
2. Upgrade firmware to 2.7.23.b246bcd or later — For any real deployment, flash the fixed firmware on all nodes. This is the only true fix and belongs in the normal patch backlog within the noisgate LOW remediation window (backlog hygiene, no hard SLA).
3. Prefer Android or desktop CLI for management until nodes are patched — Android app and meshtastic-python CLI are unaffected; using them avoids the iOS BLE sync loop entirely while firmware rolls out.
4. Enable channel PSK / encryption on the mesh — A shared secret raises the bar for a random RF-adjacent attacker to inject a malformed NodeInfo. Doesn't stop naturally occurring truncation, but eliminates the malicious injection path.

Run on any workstation with the meshtastic Python CLI installed and a USB-connected Meshtastic node. Invoke as ./check-cve-2026-42566.sh (no arguments, no root required). Confirms the connected node's firmware version against the fixed release.

#!/usr/bin/env bash
# noisgate check for CVE-2026-42566
# Requires: meshtastic-python CLI (pip install meshtastic)
# Usage: ./check-cve-2026-42566.sh
set -u

FIXED="2.7.23"

if ! command -v meshtastic >/dev/null 2>&1; then
  echo "UNKNOWN: meshtastic CLI not installed (pip install meshtastic)"
  exit 2
fi

INFO=$(meshtastic --info 2>/dev/null)
if [ -z "$INFO" ]; then
  echo "UNKNOWN: no Meshtastic node detected on USB"
  exit 2
fi

VER=$(echo "$INFO" | grep -Eo 'firmware_version[^"]*"[^"]+"' | head -1 | sed -E 's/.*"([^"]+)"/\1/')
if [ -z "$VER" ]; then
  VER=$(echo "$INFO" | grep -iE 'firmware' | head -1)
fi

echo "Detected firmware: ${VER:-unknown}"

# Compare major.minor.patch numerically
norm() { echo "$1" | grep -Eo '^[0-9]+\.[0-9]+\.[0-9]+' ; }
CUR=$(norm "$VER")
if [ -z "$CUR" ]; then
  echo "UNKNOWN: could not parse firmware version"
  exit 2
fi

# lexical-safe compare
lowest=$(printf '%s\n%s\n' "$CUR" "$FIXED" | sort -V | head -1)
if [ "$lowest" = "$FIXED" ] && [ "$CUR" != "$FIXED" ]; then
  echo "PATCHED: $CUR >= $FIXED"
  exit 0
elif [ "$CUR" = "$FIXED" ]; then
  echo "PATCHED: $CUR == $FIXED (verify build suffix b246bcd or later)"
  exit 0
else
  echo "VULNERABLE: $CUR < $FIXED.b246bcd"
  exit 1
fi

Sources

1. Meshtastic firmware advisory GHSA-gq7v-jr8c-mfr7
2. Meshtastic-Android advisory GHSA-h4rg-g6f3-ghh7
3. Meshtastic firmware security overview
4. OffSeq Threat Radar — CVE-2026-42566
5. Cezar Lungu — Meshtastic Security Disclosure
6. CyberPress — Severe Meshtastic Flaw
7. Cybersecurity News — Meshtastic Vulnerability