Security disclosure.

Use one of the channels below. Please do not file a public GitHub issue for vulnerabilities — that exposes other users.

• GitHub Private Vulnerability Reporting (preferred): github.com/getdoks/doks/security/advisories/new. This is our default channel; it gives both sides an audit trail and a path to a CVE.
• E-mail: security@datadistill.co. PGP key fingerprint 0x0000 0000 0000 0000 available at /.well-known/security.txt.

What to include for fastest triage:

• The doks version (npm ls doks or commit SHA);
• A clear description of the issue and the impact;
• Reproduction steps, ideally a minimal proof-of-concept;
• The affected environment (Node version, OS, browser if relevant);
• Your suggested fix, if you have one (optional).

In scope:

• The doks codebase shipped at github.com/getdoks/doks on the main branch and the latest tagged release;
• This site (the marketing / documentation host);
• The /api/docs/search route handler in the reference implementation;
• The MDX <Chunk> ingest pipeline.

Issue classes we particularly care about:

• Server-side: SSRF, RCE, authentication bypass on any future authenticated route, prompt-injection that exfiltrates other users' data;
• Client-side: stored or reflected XSS in the chat panel, MDX-to-HTML escaping flaws;
• Supply chain: dependency tampering, post-install script abuse, malicious lockfile changes;
• Data: unintended exposure of API keys via client bundles, embedding leakage, log entries containing secret material.

To save your time and ours:

• Reports generated entirely by an automated scanner with no demonstrated impact;
• Missing security headers on this static site (CSP / HSTS) when no exploit is shown;
• Self-XSS that requires a victim to paste attacker-controlled code into their own console;
• Issues in third-party providers (report to the provider directly);
• Denial-of-service that requires sustained heavy traffic or paid resources to demonstrate;
• Theoretical timing attacks below practical exploitability;
• Best-practice deviations (e.g. "you should use a stricter CSP") without a working exploit;
• Vulnerabilities that exist only in unsupported / archived branches.

If you make a good-faith effort to comply with this policy, we will:

• Not pursue civil action or report you to law enforcement for security research conducted within scope;
• Treat you as having authorised access for the duration and depth necessary to investigate the issue;
• Work with you in good faith to understand and resolve the issue.

To stay inside safe harbour, you must:

• Test only on your own deployments or against the public site within the limits in section 5;
• Not access, modify, or destroy data that does not belong to you;
• Not impair the service for other users (no DoS, no resource exhaustion);
• Not use social engineering against maintainers or contributors;
• Hold the disclosure private until we have published an advisory or 90 days have passed (see section 6).

Safe harbour is not a licence to break unrelated laws. We can only protect you from claims by us; we cannot waive third-party or criminal claims.

• Use your own deployment for any test that involves writing data, hammering an endpoint, or generating load.
• This site is in scope only for read-only, single-request tests. Do not run automated scanners; do not attempt to exhaust resources.
• Rate-limit requests to the public site to one per second or less.
• Identify yourself via a custom User-Agent header containing security-research and a contact e-mail; this helps us not block you accidentally.
• Stop and report the moment you confirm an issue. Do not exfiltrate data beyond what is necessary to demonstrate impact.

Day 0

You submit the report.

Within 3 business days

We acknowledge receipt and assign a triage owner.

Within 10 business days

We respond with our assessment of severity and a target fix window.

Up to 90 days

We work on a fix and prepare an advisory. For critical issues we aim for a fix and patch release within 14 days.

Coordinated disclosure

We publish a GitHub Security Advisory and request a CVE if warranted. You are credited in the advisory unless you ask not to be.

If we go silent

If we have not responded within 14 days of your report, you may publish your findings. We do not consider this a breach of safe harbour.

We use the CVSS 4.0 base metric as a starting point and adjust for the realistic exploitation context of a self-hosted, MDX-driven docs site. The published advisory always shows the CVSS vector string so you can recompute under your own context.

doks is an open-source project with no funding, so there is no monetary bounty. What we do offer:

• Public credit in the advisory and in SECURITY-HALL-OF-FAME.md;
• A swift, respectful response;
• For high-severity reports, a written reference letter on request.

If at some point in the future the project is sponsored or commercialised, a structured bounty programme will be considered. This page will be updated when that happens.

We follow a variant-hunting philosophy: when a vulnerability is fixed, we also look for sibling issues in adjacent code paths and document the search in the advisory. If you find one variant, we encourage you to look for others before reporting; we'll happily wait.