The Firmware is itself a privacy and anti-surveillance tool, so the "vulnerability" boundary is broader than for general-purpose firmware. The following are treated as security issues:

• Privacy regressions. The Firmware fails to defend against an attack class it advertises defenses for — e.g., a deployment of PrivacyMode leaks the original node identity through a side channel; a node running RfFingerprintCountermeasures is still distinguishable on a documented attack vector; CoverTraffic decoys are statistically separable from real traffic. See ABOUT.md for the threat model and PRIVATE_PORTS.md for per-module guarantees.
• Cryptographic bugs. Issues in channel crypto, per-peer PKI, WireGuard handling, or any of the Firmware's cryptographic surfaces.
• Memory safety / RCE / privilege escalation. Standard firmware vulnerability classes affecting Firmware-introduced code.
• Authentication / authorization bypass. On the on-device API (port 4403), the bot RemoteLink (port 4404), or the private-port modules.
• Supply-chain issues in code paths that ship in the Firmware's binaries.

If you're not sure whether something qualifies, report it.

• Vulnerabilities purely in upstream Meshtastic-derived code paths that the Firmware does not modify. Report those to upstream — the Firmware doesn't triage upstream's surface beyond rolling forward when upstream patches.
• Threats outside the documented threat model — e.g., active adversaries who can transmit, on-device backdoors, or attacks predicated on operational visibility into the people using a mesh. These are explicitly out of scope per ABOUT.md.
• Disagreements about whether a feature should exist. File an issue for that.

Report privately. Two acceptable channels:

1. GitHub private vulnerability reporting (preferred). On the repository's Security tab at github.com/official-mesh, click "Report a vulnerability." This keeps the conversation attached to GitHub's normal disclosure workflow and doesn't require any out-of-band identity.
2. Email. Send to the contact address listed on the maintainer's GitHub profile (github.com/officialmeshadmin), with subject prefix [Firmware Security]. Encrypt with the maintainer's published PGP key if the report is sensitive — fingerprint 9A18 814D 74A6 3138 9F95 6EA0 5F8D 7A5E ED20 3343, full key in KEYS at the repo root or fetchable from hkps://keys.openpgp.org.

Please do not open public issues for unpatched security vulnerabilities, especially privacy-relevant ones — exploitation could have real-world consequences for users running the affected firmware.

• Firmware version (commit hash) affected.
• Hardware affected (board variant, radio chip).
• A specific reproduction or proof of concept.
• Your assessment of severity and exploitability.
• Whether you've discussed the issue with anyone else, and what disclosure timeline you have in mind.

Default target: 90 days from initial report to public disclosure or patch, whichever comes first. The Firmware is maintained by one person, so reaching this target is sometimes slower in practice. If you have a hard timeline, say so in the report; the maintainer will work with you or, failing that, will explicitly tell you so you can plan disclosure accordingly.

For privacy regressions specifically, the maintainer may request a longer embargo if a coordinated patch + retroactive mitigation guidance would meaningfully reduce harm to existing users.

Confirmed reports are credited in the relevant release notes (with the reporter's chosen handle and link, or anonymously, per their preference).

The Firmware has no formal "supported versions" matrix. The maintainer fixes issues on the most recent release and the development branch. Users on older versions are expected to update; if you can't, fork and patch. That right is the entire point of an AGPL release.