Vulnerability Disclosure

Phlix is self-hosted software with an internet-facing attack surface — HTTP and WebSocket APIs, hub pairing and relay, federation between hubs, OPDS feeds, and DLNA on the local network. If you find a way to break any of it past its documented security model, we want to hear about it privately, before it is public.

How to report

• Email: Joe Huss detain@interserver.net (the maintainer contact carried by every source-file header in the estate).
• GitHub: open a private vulnerability report from the Security tab of the affected repository (detain/phlix-server, detain/phlix-hub, the detain/phlix-*-client repositories, or detain/phlix-docs) where the report form is offered; otherwise use the email above.

Please include, as best you can:

1. The affected component and version (or commit) — server, hub, a client, or a documentation instruction that is actively unsafe.
2. Steps to reproduce, with relevant request/response samples or proof of concept.
3. The impact you see (authentication bypass, token forgery, SSRF, privilege escalation, data exposure, etc.).

What we ask of reporters

• Do not open a public issue or discussion for an unfixed vulnerability, and do not publish exploit details before a fix (or an agreed fallback timeline) exists. This is a small unpaid open-source project; give the maintainer a reasonable window to prepare a fix before coordinated disclosure.
• Test only against systems you own or are explicitly authorized to test.

What you can expect

• An acknowledgement as soon as practical (this project does not commit to a contractual SLA — it is honest about being volunteer-maintained).
• A private conversation about the fix; patched releases ship through the normal release process of the affected component.
• Credit in the advisory/release notes if you want it (your GitHub handle or a name — your call whether to be named at all).

Scope

Everything published under the detain GitHub organization: the server, the hub, the shared wire contract packages, all client apps, and these docs. Third-party libraries (vendor/, node_modules/) are handled through their own upstreams; if you find one here, tell us anyway so we can bump it.

The security model itself — what each authentication method, signed URL, relay, and federation link does and does not protect — is documented in Security Hardening, Signed Media URLs, Passkeys, and SSO. Deviations from those pages are the bugs worth reporting.