Security review: GHSA-xq3m-2v4x-88gg (protobuf.js RCE) — MeshMonitor is not exploitable

[Yeraze]

TL;DR

MeshMonitor is NOT exploitable by GHSA-xq3m-2v4x-88gg ("Critical flaw in Protobuf library enables JavaScript code execution", reported by Endor Labs 2026-04-18). The vulnerability requires loading an attacker-controlled .proto schema. MeshMonitor only loads static, bundled Meshtastic .proto files shipped inside the image — there is no code path that accepts schemas from users, devices, MQTT, or any other external source.

The currently-released main branch (4.0.0-beta6) and the pinned package-lock.json already resolve protobufjs@8.0.1 (the patched version). No action required for deployed operators.

---

The vulnerability (GHSA-xq3m-2v4x-88gg)

• Package: protobufjs (npm)
• Affected: <= 8.0.0 on the 8.x line, <= 7.5.4 on the 7.x line
• Fixed: 8.0.1 (npm release 2026-04-04) and 7.5.5 (npm release 2026-04-15)
• Class: Remote code execution via unsafe dynamic code generation (new Function() string concatenation)
• Root cause: When protobuf.js builds encode/decode functions from a schema, it concatenates schema-derived identifiers (such as message type names) directly into a string that is passed to the Function constructor. Schema-side identifiers are not sanitized, so a malicious .proto whose type name contains )};<attacker-js>// escapes the synthetic function body and achieves RCE in the Node.js process that loads the schema.
• Trust boundary: Exploit requires the schema itself to be attacker-controlled. A message decoded against a trusted, static schema is not a vector — the attacker must influence the .proto definition.
• Patch: Strips non-alphanumeric characters from type names before concatenation. Endor Labs notes the proper long-term fix is to stop round-tripping identifiers through Function at all.

MeshMonitor's usage of protobufjs

All protobuf usage is server-side (src/server/). The frontend never touches protobufjs directly.

Where schemas are loaded

Two call sites, both load from hard-coded paths:

• src/server/protobufLoader.ts — loads mesh.proto, admin.proto, apponly.proto, paxcount.proto, mqtt.proto, storeforward.proto
• src/server/protobufService.ts — loads meshtastic/mesh.proto, meshtastic/admin.proto

Every root.load() call uses path.join(protoDir, 'meshtastic/<literal-filename>.proto'). There is zero user input in any schema path.

Where the .proto files come from

• Vendored as the protobufs/ git submodule, pinned to upstream meshtastic/protobufs@v2.7.20 (cdde2876befc50620307497e269f313c7944fc0b).
• Dockerfile copies protobufs/ into the image at build time, and the built server reads from that path inside the container.
• There is no runtime code path that writes, uploads, or replaces a .proto file. No multer/upload handler touches the .proto directory. No API endpoint accepts schema content.

Where types are looked up

Over 150 call sites in src/server/ invoke root.lookupType('meshtastic.<TypeName>'). I audited the full list — every single type name is a hard-coded string literal. None are constructed from req.body, req.params, req.query, or any other user-influenced source. Examples: 'meshtastic.FromRadio', 'meshtastic.MeshPacket', 'meshtastic.AdminMessage', 'meshtastic.Position', 'meshtastic.Telemetry'.

Where decode is called

All Type.decode(data) sites decode message bytes against the trusted schemas loaded at startup. The message-decode path is not the attack surface described in the advisory — only schema loading is.

What we do NOT do

• No Root.fromJSON() / Root.addJSON() / protobuf.parse() of user input.
• No manipulation of the global protobuf.roots cache.
• No dynamic .proto compilation at runtime.
• No import of schemas from MQTT, device, or HTTP request payloads.

Dependency state

package.json declares "protobufjs": "^8.0.1" (patched range). The committed package-lock.json on main pins the exact resolved version:

"node_modules/protobufjs": {
  "version": "8.0.1",
  "resolved": "https://registry.npmjs.org/protobufjs/-/protobufjs-8.0.1.tgz",
  ...
}

The v4.0.0-beta6 Docker image and any npm ci install from the locked manifest get the patched build.

Threat model summary

Attack vector	In scope?	Notes
User uploads malicious .proto	No	No upload endpoint exists
Device sends malicious .proto	No	Devices send messages, not schemas
MQTT payload is a malicious schema	No	MQTT handler only decodes ServiceEnvelope/MeshPacket bytes
Config / Settings contain schema	No	No setting accepts proto source
Restore-from-backup replaces schema	No	Backup restore writes DB rows only; .proto files are baked into the image
Transitive dep ships bad schema	No	No transitive dep loads its own .proto through our root
Message bytes exploit decoder	Not this CVE	The advisory is schema-side, not decode-side

Recommendation for operators

1. If you run v4.0.0-beta6 or later, or build from main: no action required. The patched protobufjs is already installed.
2. If you run an older tag built from source before 2026-04-04 and have a hand-edited package-lock.json: verify npm ls protobufjs reports >= 8.0.1 or >= 7.5.5. If not, re-run npm install --package-lock-only --legacy-peer-deps and rebuild.
3. General hygiene: Continue to treat the protobufs/ submodule as trusted code and only update it by bumping to a tagged upstream release.

Why this was low-risk for us by design

MeshMonitor's protobuf surface is intentionally narrow:

• Schemas are build-time assets, not runtime configuration.
• Type lookups are static string literals, not reflection on user data.
• The trust boundary between "trusted schema + untrusted message bytes" and "untrusted schema" is preserved everywhere.

This aligns with Endor Labs' long-term guidance in the advisory: "treat schema-loading as untrusted input" — and we already do, by never exposing it as input at all.

References

• Advisory: GHSA-xq3m-2v4x-88gg
• Endor Labs write-up: https://www.endorlabs.com/learn/the-dangers-of-reusing-protobuf-definitions-critical-code-execution-in-protobuf-js-ghsa-xq3m-2v4x-88gg
• BleepingComputer coverage (2026-04-18): https://www.bleepingcomputer.com/news/security/critical-flaw-in-protobuf-library-enables-javascript-code-execution/
• Upstream patch: protobufjs@8.0.1 / protobufjs@7.5.5