If you discover a security vulnerability in this project, please report it privately. Do not open a public issue.

Contact: security@your-org.com

When reporting, please include:

• A description of the vulnerability and its potential impact.
• Steps to reproduce the issue.
• Any relevant logs, screenshots, or proof-of-concept code.

We aim to acknowledge reports within 48 hours and provide a fix or mitigation plan within 7 business days.

• commix — The reverse_tcp shell module is Linux-only and will produce an import error on Windows at startup. Core HTTP injection testing still functions normally.
• hydra — Requires Cygwin DLLs (cygwin1.dll, etc.) to be present alongside the binary in C:\Tools\Pentest\.
• wafw00f / wad — Depend on the six package, which may need to be installed manually (pip install six) if missing.

Some tools have better compatibility or additional features when run under Windows Subsystem for Linux (WSL):

• commix — Full shell payloads (including reverse shells) are only available on Linux.
• hydra — The native Windows build has limited protocol support compared to the Linux version.
• sqlmap — Works on Windows, but certain OS-level payloads and file read/write techniques require a Linux environment.

The server enforces strict target scoping to prevent unauthorized scanning.

1. Engagement definition — Before any tools can be used, an engagement must be started. The engagement specifies the authorized target scope as a list of allowed hosts, IP ranges, and URL patterns.
2. Pre-execution validation — Every tool invocation that targets a host or URL is checked against the active engagement scope before execution begins.
3. Rejection of out-of-scope targets — If a target does not match the allowed scope, the request is rejected with a clear error message. No network traffic is sent to the out-of-scope target.
4. No implicit scope expansion — Redirects, DNS resolutions, or discovered subdomains do not automatically expand the scope. Only explicitly listed targets are permitted.

This design ensures that the server cannot be used (accidentally or otherwise) to scan targets that were not explicitly authorized.

All user-supplied input is sanitized before being passed to external tool binaries.

• Allowlist-based validation — Input parameters are checked against allowlists of permitted characters and patterns. Only values that match the expected format (hostnames, IP addresses, port numbers, URL paths, etc.) are accepted.
• Shell metacharacter rejection — Characters commonly used in command injection attacks (;, |, &, $, `, (, ), {, }, <, >, \n) are rejected outright. Input containing these characters produces an immediate validation error.
• Parameterized command execution — External tools are invoked using list-based subprocess calls rather than shell strings. This prevents shell interpretation of user input even if a metacharacter were to slip through validation.
• Schema validation — Every tool defines a JSON Schema for its parameters. Incoming requests are validated against this schema before any processing begins. Missing required fields, wrong types, and unexpected properties are all rejected.

These layers work together to minimize the risk of command injection and ensure that only well-formed, expected input reaches the underlying security tools.