Security
Report a vulnerability
On this page
Pug Network is a security-focused product. We take vulnerability reports seriously and want to make it easy for you to send one in. This page explains scope, what to include, what to expect back, and how we disclose fixes.
How to reach us
Send vulnerability reports privately. Do not file a public GitHub issue — that broadcasts the bug before we can ship a fix.
- Email:
security@pug.network(or the address listed on the live deployment you are reporting against, if it differs). - GitHub: use the Private vulnerability reporting feature on the repository if it is enabled.
If you require encryption, ask in plaintext for our PGP key and we will
send it back. The key fingerprint is also published in the repository
root SECURITY.md.
What is in scope
- The Pug Network JavaScript implementation (
pugnetwork-js/): server, client, and the protocol between them. - The Pug Network Go implementation (
pugnetwork-go/): server, client, and packaging (systemd unit, OpenBSDrc.dscript, etc.). - The published documentation site if it leaks information that compromises the trust model.
- The cryptographic protocol itself, including the URL-fragment-based key transport.
What is out of scope
- Issues that depend on a malicious participant inside a room (Pug Network does not authenticate participants beyond the room secret — that is by design).
- Endpoint compromise (if your laptop is owned, no end-to-end protocol can save you).
- Out-of-band link interception (anyone you share a full room URL with has, by design, the credentials to join).
- Reports about hosted-service operations (uptime, rate limits, abuse on a third-party Pug Network deployment) — contact that deployment's operator.
- Findings from automated scanners with no proof-of-impact.
- Missing security headers on a self-hosted instance whose operator has reconfigured them; the published builds ship the strict default.
- Spam, social engineering, or physical security of any operator's infrastructure.
What to include
A good report includes:
- A clear description of the vulnerability and which implementation (JS, Go, both) it affects.
- A minimal proof-of-concept or reproduction steps.
- Your assessment of impact: what an attacker gains, under what preconditions.
- Any suggested mitigation, if you have one.
- Whether you would like credit in the fix announcement, and under what name.
What to expect back
| Stage | Target |
|---|---|
| Acknowledgement of receipt | Within 72 hours. |
| Triage and severity assessment | Within 7 days. |
| Fix or mitigation in main | Critical: 14 days. High: 30 days. Lower: best effort. |
| Coordinated public disclosure | After fix ships, by mutual agreement. |
Targets are aspirational, not contractual — Pug Network is currently maintained by a small team. We will keep you updated honestly if a timeline slips.
Disclosure policy
- We follow coordinated disclosure: fix first, then publish details.
- We will credit the reporter unless they ask not to be named.
- We will request a 90-day embargo from the date of acknowledgement, extendable by mutual agreement if the fix is non-trivial.
- Once a fix is published, we will publish a write-up describing the issue, the fix, and any user-facing action required.
Safe harbor
We will not pursue legal action against good-faith security researchers who:
- Test only against their own self-hosted Pug Network instance, or against a deployment whose operator has authorised testing.
- Avoid privacy violations, service degradation, and data destruction.
- Give us a reasonable opportunity to fix the issue before public disclosure.
If you are unsure whether your planned testing is in good faith, ask first — we would rather have the conversation than miss the report.