hanami is a self-hosted media server that handles private keys' signatures, encrypted files, and untrusted network input, so security reports are taken seriously and are welcome.

hanami is pre-1.0 and ships from main. Security fixes land on main and in the next tagged release; there is no back-porting to older tags. Always run the latest release.

Please do not open a public issue for a security vulnerability.

Report it privately through GitHub's Report a vulnerability button (repository → Security → Advisories). This opens a private advisory visible only to you and the maintainer.

In your report, please include:

• affected version / commit,
• a description of the issue and its impact,
• steps to reproduce (a proof of concept if you have one),
• any suggested fix.

You can expect an initial acknowledgement within a few days. Once a fix is ready we'll coordinate a disclosure timeline with you and credit you in the advisory unless you'd rather stay anonymous.

hanami's full trust model, security guarantees, and known limitations are documented in docs/threat-model.md. This section summarizes what is most worth reporting.

Things that are in scope and especially worth reporting:

• authentication / session handling and the dashboard's access control,
• the Blossom server (upload/serve/delete authorization, BUD auth),
• private-file encryption and the encrypted drive (key handling, decrypt-and-serve),
• SSRF and request forwarding (member-supplied server URLs, mirror/repair fetches, allowed_hosts / trusted_proxies),
• the federation peer backup path,
• anything that lets one member read or modify another member's data.

Because hanami is self-hosted, an operator who deliberately misconfigures their own instance (e.g. serving plaintext HTTP on a public interface, which hanami already warns about at startup) is out of scope, but a report that hanami's defaults are unsafe is very much in scope.

Thank you for helping keep hanami and the people who run it safe.