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.

Security fixes are made on the default branch and included in the next release. The project does not currently maintain backport branches.

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

ExploitHunter.app is a local-first, single-user application. Keep the service private even when its research targets are remote:

1. Bind the app to 127.0.0.1; do not expose it as a public or shared service.
2. Keep .env, provider credentials, compute-target keys, and artifact-store credentials out of logs and source control.
3. Record target scope in the authorization ledger and use the narrowest network profile that can reach the approved target.
4. Review every dangerous-action approval. A target grant does not approve commands, browser mutation, downloads, writes, credential tests, or exploit checks.
5. Keep local observability enabled. Configure an external exporter such as Langfuse only when its data handling and credentials are acceptable for the engagement.
6. Use isolated labs for untrusted files, hostile websites, and active validation; preserve the resulting evidence and diagnostics.

We will credit responsible disclosure reporters with their permission in the relevant security advisory or release notes.