Please report security issues privately, not through the public issue tracker.
- GitHub: open a private security advisory (preferred — it keeps the discussion attached to the repository)
- Email: info@gridbase.net
Please include what you need to demonstrate the issue: affected version, the conditions required, and what an attacker gains. A proof-of-concept is welcome but not required.
You will get an acknowledgement within a few days. This is a small project without a dedicated security team, so please be patient with the timeline — but if you get no reply at all within two weeks, escalate by opening a public issue that says only that you are waiting on a private report, with no detail.
Never include a channel key in a report, a log excerpt, or a screenshot. A key fingerprint is safe and is usually what matters.
The plugin's own code: the MCTAK codecs, the transfer engine, the companion-protocol client, the CoT injection path, and anything reachable from a datagram arriving off the air.
Particularly interesting:
- Anything that turns a malformed or hostile datagram into memory exhaustion, a crash, or code execution. Inflate bounds, fragment reassembly, and object CRC handling are the places to look.
- Anything that lets a sender inject CoT that ATAK acts on beyond what a channel member should be able to do.
- Loop or amplification conditions — a datagram that causes the plugin to transmit repeatedly is a denial of service against everyone sharing the band, not just this node.
The trust model is the channel key. Holding the pre-shared key of a MeshCore channel is
the whole of the authentication story. The sender field in an MCTAK header is not
authenticated (docs/payload-spec.md §11.1), so any channel member can impersonate any other.
That is a known and documented property, not a vulnerability. If it matters for your use, the
answer is key hygiene: a channel key is a team secret, and anyone holding it is inside your
trust boundary.
Traffic is visible as traffic. MeshCore encrypts channel payloads, but the fact and timing of a transmission are not hidden, and neither is the size. Traffic analysis against a LoRa mesh is out of scope.
Physical access to an unlocked device. Channel keys live on the radio and are readable by anything paired with it.
The ATAK host and MeshCore firmware are separate projects — please report issues in them upstream. If a plugin change can mitigate an upstream issue, that is in scope here and worth telling us about.
- Payload encryption (§7 ENC/OBJECT-ENC) is implemented but not reachable. There is no key
management UI, so
setEncKeyhas no caller and confidentiality currently rests entirely on the MeshCore channel PSK. This is tracked in the allowlist inEngineReachabilityTestand is not a secret. - Read receipts default off, and the pref that would change that is not wired to a UI.
- The plugin refuses to transmit MCTAK on channel slot 0 (Public) by design.
Only the most recent release gets fixes. Given that a release requires a fresh tak.gov signing round-trip, please state which release you tested against.