ExploitSpec executes security tests and handles target URLs, authentication headers, cookies, environment variables, and response data. We treat defects that cross those boundaries seriously.

ExploitSpec is currently pre-1.0. Until stable releases and a formal support window exist, security fixes are made only on the latest code in the default branch and, when releases exist, the latest release. Older commits and unofficial builds are not maintained.

Do not open a public issue with exploit details, credentials, target data, or a working proof of concept.

Use GitHub's private vulnerability reporting for this repository:

https://github.com/pazent/exploitspec/security/advisories/new

If private reporting is unavailable, open a public issue containing only the sentence “Private security contact requested” and no technical details. A maintainer will arrange a private channel.

Include, when possible:

• the affected commit, version, and operating system;
• the command and minimal sanitized spec needed to reproduce the issue;
• expected and observed behavior;
• security impact and affected boundary;
• a proof of concept that targets only systems you own;
• whether the issue is already public or known to another party;
• a safe way to acknowledge your work if you want credit.

Never include live credentials, customer information, production response data, or an unauthorized target.

Maintainers will try to acknowledge a complete report promptly, reproduce it, assess severity, and keep the reporter informed. Response and fix timing depend on impact and maintainer availability; this volunteer project does not promise a service-level agreement.

We ask reporters to allow reasonable time for a fix and release before public disclosure. Coordinated disclosure details and credit will be agreed with the reporter. We will not request silence about an issue indefinitely.

Examples include:

• bypassing remote-host authorization or the permanent metadata-IP block;
• escaping the selected base scheme or host through path interpolation or redirects;
• sending requests during validate;
• unintended file reads or writes beyond explicitly selected specs and reports;
• command or code execution caused by parsing an untrusted spec;
• credentials, cookies, captured values, or response bodies being exposed beyond documented report behavior;
• TLS verification being disabled without explicit operator choice;
• denial of service that bypasses documented file-count, file-size, response-size, timeout, or redirect limits;
• dependency vulnerabilities that are reachable in ExploitSpec's execution paths;
• report-format injection with a concrete impact on a supported consumer.

The following are generally not vulnerabilities in ExploitSpec:

• a vulnerability in the application being tested;
• a reviewed spec sending a state-changing request it explicitly defines;
• requests reaching a non-loopback hostname that the operator explicitly allowlisted;
• disclosure to a proxy, DNS resolver, terminal logger, or target system that the operator configured, within their normal function;
• secrets deliberately embedded as non-templated literal body assertions appearing in documented failure diagnostics;
• running attacker-controlled specs without review on a sensitive network;
• lack of protection from every private IP or DNS-rebinding scenario currently documented as outside the safety boundary;
• social engineering, physical attacks, or attacks requiring an already compromised host;
• automated scanner output without a reproducible impact.

An out-of-scope category can still reveal a documentation or hardening opportunity. Reports with a concrete, previously undocumented boundary crossing are welcome.

Research must use systems you own or are explicitly authorized to test. Avoid privacy violations, data destruction, persistence, lateral movement, service degradation, and accessing more data than needed to demonstrate impact.

Stop testing and report immediately if you encounter real user data, live credentials, or evidence of active compromise. Delete sensitive copies after the report is safely transferred and no longer needed for coordination.

ExploitSpec's controls reduce mistakes; they do not make arbitrary specs safe.

• Review specs like executable code.
• Run against isolated test environments and synthetic data.
• Use least-privilege, short-lived credentials.
• Explicitly authorize every remote hostname.
• Keep TLS verification enabled; reserve --insecure for controlled test environments.
• Remember that Go's standard proxy environment can route target traffic.
• Treat JSON, JUnit, and text reports as potentially sensitive.
• Do not commit .env, tokens, private keys, cookies, or unsanitized responses.
• Pin and verify the ExploitSpec version used in sensitive workflows.

The precise controls and limitations are documented in the specification and architecture.