Security Policy

We take the security of Cachix and its users seriously. This document explains how to report a vulnerability, what we consider in scope, and what to expect after submitting a report.

Reporting a vulnerability

Email security reports to [email protected].

A good report includes:

• A clear description of the issue and the affected asset (URL, endpoint, or component).
• Reproduction steps and a working proof of concept.
• The impact you believe a real attacker could achieve, and any conditions required to exploit (authentication, user interaction, account state).
• Your name or handle if you would like to be credited.

Please do not open a public GitHub issue for security reports. Please do not test against other users' accounts, exfiltrate data, run automated scanners that generate load, or perform any action that could degrade service for others. Do not threaten, extort, or attempt to extort Cachix or its users in connection with a vulnerability report. Stay within the scope below.

We will acknowledge your report within 5 business days and aim to resolve confirmed issues within 90 days, depending on severity and complexity.

What happens after you report

1. We receive the report and assign a primary handler who will be your point of contact.
2. We reproduce the issue and confirm the affected components and versions.
3. We audit related code paths for similar issues that should be fixed at the same time.
4. We prepare and test a fix, coordinating any downstream notifications.
5. We deploy the fix and, where appropriate, request a CVE for the confirmed vulnerability.
6. We coordinate public disclosure timing with you and credit you in the acknowledgements section below.

Safe harbor

If you make a good-faith effort to comply with this policy during your security research, we will consider that research authorized, will not pursue or support any legal action against you, and will work with you to understand and resolve the issue quickly. We cannot waive the rights of third parties, so this safe harbor does not apply to actions affecting users, partners, or infrastructure providers outside of Cachix.

Good faith means:

• Staying within the in-scope assets listed below.
• Stopping immediately if you encounter user data, and reporting what you found without copying, retaining, or further accessing it.
• Not degrading service for other users, including no automated load testing, no denial of service, and no large-scale automated scanning.
• Giving us a reasonable window to fix the issue before public disclosure.

If you are unsure whether a specific action falls within this policy, email [email protected] first and ask.

Compensation

Cachix does not operate a paid bug bounty program. We do not offer monetary rewards for vulnerability reports, and no advertisement or implication of payment exists on any of our properties.

For reports that result in a substantive fix, we are happy to publicly credit the reporter in our acknowledgements section below.

In scope

• app.cachix.org and cachix.org
• *.cachix.org cache subdomains
• The Cachix server backend
• The Cachix CLI (cachix/cachix)
• Cachix Deploy agents and workers

Out of scope

The following report classes are not accepted and will be closed without a fix unless accompanied by a concrete, demonstrated exploit chain with material impact:

• Missing or "weak" security headers without a working proof of concept (X-Frame-Options, CSP, HSTS preload, Permissions-Policy, X-Content-Type-Options, Referrer-Policy, etc.).
• Missing or misconfigured email security records (SPF, DKIM, DMARC, BIMI) without a working spoof PoC delivered to a real inbox.
• Password policy preferences (length, composition, rotation, breached-password checks) absent a concrete account-takeover scenario.
• User or email enumeration on authentication endpoints (login, signup, password reset, OAuth link) without an attached exploit.
• Rate limiting absence or weakness without a demonstrated abuse scenario causing measurable harm.
• Clickjacking on pages that do not perform sensitive state-changing actions, or where SameSite cookies already mitigate the attack.
• Self-XSS, or XSS that requires the victim to paste attacker-controlled content into their own browser console.
• Open redirects on endpoints that do not carry session credentials or sensitive parameters.
• Reports generated by automated scanners (Nessus, Acunetix, Nuclei, Burp Active Scan, etc.) without manual verification and impact analysis.
• Issues that require a malicious or compromised browser extension, rooted device, or physical access.
• Social engineering, phishing, or attacks against Cachix employees or infrastructure providers.
• Typosquatting of Cachix domains, packages, or CLI binary names.
• Denial of service via traffic volume, distributed attack, or resource exhaustion without a logic bug.
• Vulnerabilities in third-party services we depend on (report those upstream).
• Known-vulnerable third-party software or dependencies without a working proof of concept demonstrating exploitability in our specific deployment.
• Best-practice recommendations, configuration suggestions, or "informational" findings with no demonstrated security impact.
• Disclosure of public information (e.g., commit history, public S3 listings of intentionally public caches, server version banners).
• Reports asking us to confirm or rule out an issue without first attempting to reproduce it.

A report that lists multiple out-of-scope items together does not aggregate into an in-scope report.

Disclosure

We ask that you give us a reasonable window to ship a fix before publicly disclosing the issue. Once a fix is deployed, you are welcome to write about your finding. We will coordinate on timing if requested.

Acknowledgements

Researchers who have responsibly disclosed valid security issues to Cachix will be listed here.