ExploitHunter.app is designed for authorized security research. Because this project involves security tooling, agent-driven automation, and target probing, we take security issues in the project itself extremely seriously.

This is a pre-1.0 project under active development. Security updates are applied to the latest commit on the default branch.

If you discover a security vulnerability in ExploitHunter.app itself—whether in the codebase, the agent orchestration layer, the approval system, or any distributed artifact—please report it responsibly.

Please do NOT open a public issue for security vulnerabilities.

Instead, email security reports to:

security@danlevy.net

We will acknowledge receipt within 48 hours and aim to provide an initial assessment within 5 business days. We follow a coordinated disclosure process and will work with you to establish a reasonable disclosure timeline.

• A clear description of the vulnerability and its potential impact
• Steps to reproduce (proof-of-concept, if possible)
• Affected versions or commit ranges
• Any suggested remediation

The following are in scope for vulnerability reports:

• The ExploitHunter.app application code (Next.js routes, API handlers, server code)
• Mastra agent configuration and tool definitions
• Approval gate bypasses or authorization logic flaws
• Workspace isolation failures
• Secret leakage in logs, telemetry, or artifacts
• Database schema or query vulnerabilities
• Supply chain concerns in dependencies

The following are out of scope:

• Security findings produced by the agent against user-configured targets (report those to the target owner)
• Vulnerabilities in third-party dependencies (report to the upstream project)
• Social engineering or phishing against project maintainers
• Issues requiring local system access to an already-compromised deployment

When deploying ExploitHunter.app, we strongly recommend:

1. Run in isolated environments only — Dedicated hardware or rootless containers (rootless Docker, Podman, Rancher Desktop)
2. Never deploy with default or weak credentials — Use strong, unique keys for SQLite, MinIO, and API tokens
3. Restrict network egress — Use the SECURITY_RESEARCH_AUTHORIZED_TARGETS allowlist and network profiles
4. Enable Langfuse observability — Trace all model calls, tool calls, and approvals for auditability
5. Review .env before production use — Ensure SECURITY_RESEARCH_ALLOW_PUBLIC_TARGETS=false unless explicitly required

We will publicly credit responsible disclosure reporters (with your permission) in our release notes and a dedicated SECURITY_ADVISORIES.md file.