Skip to content

Security: gridbasedotnet/meshcore-TAK

SECURITY.md

Security policy

Reporting a vulnerability

Please report security issues privately, not through the public issue tracker.

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.

What is in scope

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.

What is out of scope, and why

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.

Known limitations, stated plainly

  • Payload encryption (§7 ENC/OBJECT-ENC) is implemented but not reachable. There is no key management UI, so setEncKey has no caller and confidentiality currently rests entirely on the MeshCore channel PSK. This is tracked in the allowlist in EngineReachabilityTest and 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.

Supported versions

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.

There aren't any published security advisories