Skip to content

Security policy

deaddrop moves data that people want kept private, so security reports are taken seriously.

Report it privately through GitHub’s private vulnerability reporting (the Security tab → Report a vulnerability):

Report a vulnerability

Please include, as far as you can:

  • The deaddrop version (deaddrop --version) or commit, and your platform.
  • Which command and options are involved (serve, fetch, reset, notifiers, config file).
  • What an attacker needs (the ticket, the key, network position, a reset token, local access to the server, …) and what they gain.
  • Steps to reproduce, or a proof of concept.

Leave real tickets, keys, reset tokens and webhook URLs out of the report, or rotate them first.

Only the latest release gets security fixes.

Version Supported
Latest release ✅
Older releases ❌
main ✅ (best effort)

deaddrop is maintained by volunteers, so these are goals rather than guarantees:

  • An acknowledgement within 7 days.
  • A first assessment (accepted, needs more info, or out of scope) within 14 days.
  • For accepted reports, a fix and a release as soon as practical, followed by a published GitHub security advisory. You’ll be credited in the advisory unless you’d rather not be.

Please give us a reasonable chance to ship a fix before disclosing publicly. If 90 days pass without a fix, or without an agreed timeline, you’re free to disclose.

In scope are problems in deaddrop’s own code that break what it promises. See Threat model → Promises for the list, plus crashes or resource exhaustion that a remote peer can trigger cheaply.

Out of scope are the known limits and content legality, or what users choose to share.

Bugs in dependencies (iroh, iroh-blobs, librqbit, age/rage, …) should go to those projects. If deaddrop uses a dependency in a way that makes it exploitable, or ships a version with a known advisory, report it here.

The canonical policy is SECURITY.md in the repository.