Security policy
How to report vulnerabilities in Punch and what to expect from us.
Supported versions
Punch follows semantic versioning. Security fixes are issued for:
| Version | Supported |
|---|---|
| 1.x | Yes |
| 0.x | No |
The reference deployment at punch.thåst.se always tracks the latest tagged release.
Reporting a vulnerability
Please do not open a public GitHub issue for security problems.
Use one of the following private channels:
- GitHub Security Advisories — preferred. Open a private advisory at <https://github.com/FiLORUX/punch/security/advisories/new>. This keeps the report private until a fix is published and gets you a CVE if appropriate.
- Email —
security@thast.se. Subject line[Punch] <short summary>.
Include where you can:
- A description of the issue and its impact
- Steps to reproduce, or a proof-of-concept
- Affected version(s) (commit SHA or release tag)
- Whether the issue is already public
What to expect
| Stage | Target |
|---|---|
| Acknowledgement | Within 72 hours |
| Initial assessment | Within 7 days |
| Fix or mitigation plan | Within 30 days for high/critical severity |
| Public disclosure | Coordinated with the reporter |
We will keep you informed throughout the process and credit you in the fix commit and release notes unless you prefer to remain anonymous.
Scope
In scope:
- The Punch worker (
src/) and the protocol it implements - Authentication and token handling (
src/auth.ts) - Rate limiting (
src/rate-limit.ts) - Session state and isolation in the SessionRoom Durable Object
- Web UI rendered by
src/ui.ts - The reference deployment at
punch.thåst.se
Out of scope:
- Vulnerabilities in upstream dependencies (report to the dependency owner)
- Cloudflare platform-level issues (report to Cloudflare)
- SRT protocol vulnerabilities (report to the SRT Alliance / libsrt)
- Social engineering of project maintainers
- Denial-of-service attacks against the reference deployment (rate limits and Cloudflare absorb these by design)
Threat model summary
Punch’s security posture is documented in
docs/security.md. Key explicit non-goals:
- Hiding peer IP addresses. SRT requires direct peer-to-peer communication; both peers learn each other’s public IP. A relay fallback (Phase 3) will mitigate this for users who require it.
- Authenticating individual operators beyond the session token. Anyone with a valid session token has the access that token grants. Use short TTLs and per-stream tokens for sensitive productions.
Disclosure history
No vulnerabilities reported yet. Future advisories will be listed in
CHANGELOG.md with a Security heading.