Today I’m excited to announce that HunterX — the AI-assisted vulnerability scanner and Red Team framework — is now fully open source under the Apache License 2.0.

Why Apache 2.0?

Apache 2.0 is the industry standard for security tools. It’s used by OWASP ZAP, Kubernetes, TensorFlow, and thousands of other projects. The license offers:

• Permissive terms: Fork, modify, distribute freely
• Attribution required: Proper credit to the original work
• Patent protection: Grants patent rights from contributors
• No GPL-style copyleft: Can be used in proprietary environments

What Changed

• All 57 Python source files updated to SPDX-License-Identifier: Apache-2.0
• All documentation files updated
• NOTICE file added with third-party attributions
• CONTRIBUTING.md updated with DCO requirement
• Docker Hub images rebuilt with Apache 2.0 labels

What This Means

• For users: You can now use HunterX without concerns about the prior Proprietary license
• For contributors: You retain copyright, grant a license to the project
• For the community: You can fork, modify, and redistribute

What’s Next

The roadmap remains unchanged. v4.1 will focus on gRPC, OAuth2, Redis queue, and TUI. v5.0 will bring autonomous agent capabilities.

Thank you to everyone who has supported the project. This is just the beginning.

Traditional vulnerability scanners operate on a simple model: send a payload, check for a match. HunterX replaces this with a reasoning pipeline inspired by how human penetration testers think.

Stage 0: Passive Intelligence

Before sending a single request, HunterX gathers context:

• WAF detection: 50+ WAF fingerprint signatures
• Technology fingerprinting: Server headers, cookies, response patterns
• Endpoint discovery: WebSocket, GraphQL, API paths
• Authentication state detection: Login forms, session patterns

This context informs all subsequent stages. If a WAF is detected, HunterX adjusts its probe strategy and may auto-abort.

Stage 1: Probe

HunterX sends diverse probes across all enabled attack categories. Each probe targets a specific vulnerability class and includes markers for response differential analysis.

Key principle: low confidence, broad coverage. The goal is not to confirm vulnerabilities but to identify interesting response anomalies.

Stage 2: Confirm

For categories that showed anomalies in Stage 1, HunterX deepens its investigation:

• More sophisticated payloads
• Multi-variant testing
• Time-based blind injection detection
• OOB (out-of-band) callback monitoring

Evidence is correlated across probes. A single anomaly is not enough — HunterX looks for consistent patterns.

Stage 3: Verify

Confirmed vulnerabilities are verified with safe, impact-minimizing payloads. The verification stage produces the final evidence that goes into the report.

Why This Matters

The 4-stage pipeline gives HunterX three key advantages:

1. Safety: By starting broad and narrowing, HunterX minimizes impact on targets that show no anomalies
2. Accuracy: Evidence is correlated across multiple probes before a finding is confirmed
3. Explainability: Every finding has a chain of evidence across stages

This is fundamentally different from brute-force payload matching. It’s a reasoning engine, not a template matcher.

Bug bounty hunting requires a careful balance between coverage and safety. HunterX’s Bounty profile is specifically designed for this.

The Bounty Profile

Max Requests: 500
Rate Limit:   10 req/s
Destructive:  false

This profile ensures you stay within program limits while maximizing coverage.

Workflow

1. Recon Phase

# Gather intelligence without sending probes
hunterx scan http://target.com --dry-run

2. Focused Scanning

# Scan with Bounty profile, JSON output for analysis
hunterx scan http://target.com \
  --profile bounty \
  -o findings.json

3. Authenticated Testing

hunterx scan http://target.com \
  --auth form \
  --username user@example.com \
  --password s3cret \
  --profile bounty

4. Results Analysis

# Scan with SARIF output for VS Code integration
hunterx scan http://target.com \
  --profile bounty \
  -o report.sarif

Tips

• Always use the Bounty profile on third-party programs
• Combine with Nuclei for broad template coverage
• Use Docker for consistent environments
• Enable OOB detection for SSRF/blind XXE

Safety First

Remember: the Bounty profile blocks destructive payloads. If you need to disable a category, use --exclude-category. Never bypass safety constraints on third-party targets.

HunterX provides an optimized 271MB multi-stage Docker image running as a non-root user.

Quick Start

docker run --rm nullc0d30/hunterx:latest scan http://example.com --profile bounty

Production Deployment

Volume Mounting

docker run --rm \
  -v $(pwd)/hunterx.yaml:/app/hunterx.yaml:ro \
  -v $(pwd)/reports:/data \
  nullc0d30/hunterx:latest \
  scan http://example.com -o /data

Resource Limits

docker run --rm \
  --memory="512m" \
  --cpus="2" \
  nullc0d30/hunterx:latest scan http://example.com

API Server

docker run --rm \
  -p 8443:8443 \
  -v $(pwd)/reports:/data \
  nullc0d30/hunterx:latest api --port 8443

CI/CD Integration

GitHub Actions

jobs:
  scan:
    runs-on: ubuntu-latest
    container:
      image: nullc0d30/hunterx:latest
    steps:
      - run: hunterx scan ${{ secrets.TARGET_URL }} \
          -o /data/report.sarif

GitLab CI

scan:
  image: nullc0d30/hunterx:latest
  script:
    - hunterx scan $TARGET_URL -o report.sarif
  artifacts:
    paths: [report.sarif]

Security

• Container runs as non-root user (UID 1000)
• Read-only root filesystem recommended
• Use Docker secrets for credentials
• Enable Docker Content Trust

Image Tags

• latest: Most recent stable release
• 6.0.0: Specific version
• dev: Development build (unstable)

HunterX has a decorator-based plugin system with three plugin types: detector, reporter, and hook.

Plugin Types

Detector Plugin

Analyze HTTP responses for vulnerabilities:

from hunterx.plugin import detector

@detector("custom_header_check")
class CustomHeaderDetector:
    """Check for missing security headers."""

    def detect(self, response, context):
        headers = response.headers
        missing = []

        if "X-Frame-Options" not in headers:
            missing.append("X-Frame-Options")

        if "Content-Security-Policy" not in headers:
            missing.append("Content-Security-Policy")

        if missing:
            return {
                "name": "Missing Security Headers",
                "category": "config",
                "severity": "medium",
                "evidence": {
                    "missing": missing,
                    "url": response.url
                }
            }
        return None

Reporter Plugin

Export results in custom formats:

from hunterx.plugin import reporter

@reporter("csv")
class CSVReporter:
    def report(self, results, output_path):
        import csv
        path = output_path.with_suffix(".csv")
        with open(path, "w", newline="") as f:
            writer = csv.writer(f)
            writer.writerow(["name", "severity", "url", "category"])
            for finding in results.findings:
                writer.writerow([
                    finding.name, finding.severity,
                    finding.url, finding.category
                ])
        return path

Hook Plugin

Execute code at scan lifecycle events:

from hunterx.plugin import hook

@hook("scan_complete")
def send_slack_notification(results, context):
    """Send notification when scan completes."""
    webhook_url = os.environ.get("SLACK_WEBHOOK")
    if webhook_url:
        payload = {
            "text": f"Scan complete: {len(results.findings)} findings"
        }
        requests.post(webhook_url, json=payload)

Installation

Place plugin files in the plugins/ directory. They are auto-discovered at startup.

Best Practices

• One plugin per file
• Use descriptive decorator names
• Return None from detectors that don’t match
• Handle exceptions gracefully
• Test plugins independently