The next MeshMonitor release is built around two things: making the server safe to run, and making the mesh features behave. We took a hard look at both, and the changes are now rolling out through release candidates so you can try them before the final build. None of this adds features you have to learn — most of it is work you will feel as fewer false alarms and fewer surprises.

On the security side, we had an automated penetration test run against a copy of a real deployment, then fixed every issue it proved. On the reliability side, we fixed a set of bugs that made nodes report things that never happened and made scheduled data collection drop readings. Here is what changed, and what to watch for when you upgrade.

Security hardening

We ran an automated penetration test (Shannon, by Keygraph) against a sanitized copy of a real MeshMonitor database. It reports a problem only when it can prove it with a working exploit, not just flag a guess. It found 38 issues; we confirmed and fixed 34 of them, closed 3 as working-as-designed, and fixed 1 more that turned up during the cleanup.

The fixes span the categories you would expect a web app to be tested for:

• Code execution — the script engine can no longer be used to run code by a non-admin or across sources, and its child processes no longer inherit server secrets.
• Request forgery — a state-changing request now needs a real, validated token instead of any bearer header.
• Path traversal — backup download and delete are confined to the backup directory.
• Secret exposure — full channel encryption keys are no longer handed to read-only users.
• Stored cross-site scripting — map (GeoJSON) and analytics inputs are now encoded before the browser renders them.
• Server-side request forgery — the outbound-URL guard's bypasses are closed, and outbound settings URLs are checked.
• Broken authorization — several actions that checked a permission on any source now check the right source.

We also rewrote the content-security-policy so production serves a strict, per-request policy with no inline-script loopholes. Every fix landed with a regression test, so these specific problems can't quietly come back.

Out of caution, the exploit details stay in a private security advisory rather than this post. The short version: if you run MeshMonitor, you want this release.

Reliability and efficiency

The second half of this work fixes bugs that made MeshMonitor react to things that never happened, and makes scheduled data collection more forgiving — without adding mesh traffic.

• No more false alarms from replayed data. When a firmware-2.8 node replays its database, MeshMonitor used to read those old readings as live and fire "node rebooted" and "power lost" events — and even flag nodes as likely aircraft. Those detectors now ignore replayed readings, so your automations, notifications, and aircraft lookups stop firing on stale data. That also cuts the wasted position requests and ADS-B lookups those false flags triggered.
• Scheduled telemetry recovers from a missed pull. On a multi-hop MeshCore link, a single dropped packet used to cost a whole interval of data. There is now a short retry burst (about every 90 seconds, up to five tries) followed by a 30-minute cooldown. It stays within the existing per-source rate limit, so it recovers missed readings without putting more load on the mesh, and the retry state survives a restart or a settings save.
• Virtual-node traffic lands where it belongs. Default-key traffic coming through the Meshtastic Virtual Node now shows up on your Primary channel instead of being split onto a separate virtual "LongFast" tab.

Alongside those, a round of smaller fixes: MeshCore channels open to a clean landing page instead of auto-marking one read, you can purge non-favourite nodes from a source, your own channel reactions show as chips instead of raw text, and the node-list header controls line up properly.

Before you upgrade

A few things to know:

• These are release candidates. The security and reliability work is shipping first as pre-release builds for testing. Try them on a test instance; don't point a production deployment at an RC.
• Some actions are now stricter. The authorization fixes tightened a handful of operations to admin-only or to the correct source. This affects non-admin users only — admins are unaffected. In particular: managing and running scripts is now admin-only; system backups require admin; exporting a full channel key now requires write access, not just read; and global settings can only be changed by an admin writing globally.
• Check your web-analytics snippet. The new content-security-policy covers analytics providers with a per-request nonce, but if you run one, confirm its inline snippet still loads after upgrading — that path was unit-tested, not browser-tested.
• MeshCore TCP connect no longer accepts loopback. Use the device's real LAN address, not 127.0.0.1.
• Change your admin password. If you are still on the default admin login, change it — especially before exposing the instance to any network. Keep MeshMonitor behind authentication; don't put it on the open internet.

The upgrade is not breaking for normal use. The changes above are the only behavior you may notice.

Try it and tell us

The work is landing in stages. The security hardening shipped first, and the reliability batch followed in the next build — both are available now as release candidates, ahead of the official release. If you run a test instance, pull the latest RC and put it through its paces, especially the parts that touch your setup: scheduled telemetry, automations that watch for reboots or power changes, and anything that connects over MeshCore.

If something looks off, open an issue. The sooner problems surface on the RCs, the cleaner the official release will be.