Gone-Phishing is in active development. Security fixes are applied to the latest master branch and the most recent tagged release. Users running older versions are encouraged to update.

Please do not report security vulnerabilities through public GitHub issues.

If you've found a security issue in Gone-Phishing — credential leakage, prompt injection bypass, authentication weakness, dependency vulnerability, or any other class of security problem — report it privately:

1. Preferred: Open a GitHub Security Advisory (private, only visible to maintainers and you)
2. Alternative: Email the maintainer — find current contact at jryan5150's GitHub profile

• A clear description of the issue and its impact
• Steps to reproduce (proof-of-concept where applicable)
• The version / commit hash where you observed the issue
• Your assessment of severity (critical / high / medium / low) and your reasoning
• Whether you've already disclosed the issue elsewhere

• Acknowledgment within 72 hours. I'll confirm receipt and let you know if I have initial questions.
• Triage within 7 days. I'll respond with my own severity assessment and a rough timeline for a fix.
• Fix or mitigation within 30 days for high/critical issues. Lower-severity issues may take longer; I'll communicate timelines.
• Coordinated disclosure. Once a fix is shipped, I'll publish a security advisory crediting you (with your permission). If you'd prefer to remain anonymous, that's also fine.

• The Gone-Phishing application code (server/, web/, tests/, scripts/)
• The dependency surface declared in requirements.txt and pyproject.toml
• The default playbook content shipped in playbooks/
• The scenario-corpus generator and the data/scenarios.json it produces
• The published Docker image (when one exists)
• The GitHub Actions workflows in .github/workflows/

• Vulnerabilities in upstream LLM providers (Anthropic, OpenAI, Google, Ollama) — please report to the respective provider
• Vulnerabilities in ConnectWise Manage, N8N, or other integrated third-party services — please report to the respective vendor
• Issues that require physical access to the deployment host
• Social engineering attacks against the maintainer
• DoS attacks against your own deployment (capacity-planning, not a Gone-Phishing bug)

The following classes of issues are particularly interesting:

• Prompt injection that bypasses the system prompt and exfiltrates data, leaks credentials, or escalates privilege within the application
• XSS via LLM output that survives the marked.js + DOMPurify pipeline in the built-in chat UI
• Credential leakage via error messages, logs, or response bodies (the application has API keys for multiple LLM providers + ConnectWise)
• Authentication weaknesses in any deployment configuration (currently the app expects to run behind a reverse proxy with auth; document any case where it doesn't)
• Path traversal in the playbook ingestion path or any file-handling code
• Denial of service via crafted inputs to the OCR / vector store / LLM tier (especially anything that triggers expensive Tier 3 cloud calls)

The application is a single-tenant FastAPI service intended to run inside an MSP's infrastructure. It does not ship with built-in user authentication — deployments are expected to put it behind a reverse proxy that handles auth (e.g., Cloudflare Access, Tailscale Funnel, OAuth2-proxy).

Key trust boundaries:

• LLM credentials → environment variables only. Never logged, never persisted, never transmitted to clients.
• ConnectWise / N8N integration credentials → environment variables only. Same rules.
• Playbook content → ingested from playbooks/ directory at startup. Any file there is trusted as authoritative; deployers control what's there.
• Incident descriptions → user-supplied free-text input. Treated as untrusted; passed to the LLM with a fixed system prompt; output rendered through marked.js + DOMPurify in the browser.
• Generated action plans → LLM output. Treated as untrusted at render time (see XSS notes); semantically presumed accurate but always reviewed by a human before action.

If you find a way to break any of these trust boundaries, that's the kind of report this policy exists for.

The repo's commit history documents the security review pass that shipped before public release. See the Security Review row in the README's Development History table for the specific commit covering rate limiting, security headers, generic error messages, and XSS prevention. New hardening is welcome via PR or security advisory.