If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/GhostTroops/scan4all shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

AVOID — Looks unmaintained — solo project with stale commits

• BSD-3-Clause licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Solo or near-solo (1 contributor active in recent commits)

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live GhostTroops/scan4all repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/GhostTroops/scan4all.

What it runs against: a local clone of GhostTroops/scan4all — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in GhostTroops/scan4all | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-3-Clause | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 694 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of GhostTroops/scan4all. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/GhostTroops/scan4all.git
#   cd scan4all
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of GhostTroops/scan4all and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "GhostTroops/scan4all(\\.git)?\\b" \\
  && ok "origin remote is GhostTroops/scan4all" \\
  || miss "origin remote is not GhostTroops/scan4all (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-3-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-3-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-3-Clause" \\
  || miss "license drift — was BSD-3-Clause at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 694 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~664d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/GhostTroops/scan4all"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

scan4all is a unified vulnerability and security scanning toolkit written in Go that integrates 15,000+ PoCs, 23 password-cracking protocols (RDP, SSH, MySQL, Oracle, SMB, etc.), 7,000+ web fingerprints, and 146 port-scanning protocols with 90,000+ detection rules. It automates vulnerability discovery, credential brute-forcing, and web application fuzzing across Linux, Windows, and macOS through a single CLI tool that wraps and optimizes projects like vscan, nuclei, ksubdomain, and subfinder. Monolithic single-binary design: brute/ package contains 10+ specialized modules (admin_brute.go, basic_brute.go, weblogic_brute.go, jboss_brute.go, etc.) for protocol-specific attacks; config/51pwn/ holds 50+ YAML PoC templates; brute/dicts/ contains wordlists (top100pass.txt, httpuser.txt, etc.) loaded at runtime. Entry point likely in root directory main.go (not shown but standard for Go CLIs).

Red team operators, penetration testers, and security researchers who need a lightweight, cross-platform vulnerability scanner that handles multi-protocol credential attacks and large-scale port scanning without setting up separate tools; also used by bug bounty hunters who need fast, automated reconnaissance on hundreds of targets.

Actively developed with comprehensive CI/CD via GitHub Actions (linux.yml, mac.yml, windows.yml, linuxarm64.yml builds), cross-compilation support (Makefile.cross-compiles), and release automation (goreleaser.yaml). The project bundles 50+ YAML-based PoC configs in config/51pwn/ and maintains dictionary files (brute/dicts/) suggesting ongoing maintenance, though the single-maintainer (@hktalent) and closed issue visibility on GitHub suggest it's a community/academic project rather than enterprise-backed.

Heavy reliance on external integrated projects (vscan, nuclei, ksubdomain, subfinder) without vendored dependencies shown in file list means upstream breaking changes propagate directly; the 1.7M+ lines of Go code and dynamic PoC loading from YAML files (config/51pwn/*.yaml) creates a large attack surface for malicious configs. No test files visible in the top 60 files (only brute/dicts/test.go) and single maintainer increase technical debt risk.

Recent activity includes GitHub Actions workflow setup (build.yml, upx.sh for binary compression), Homebrew formula publishing (HomebrewFormula/scan4all.rb), and goreleaser configuration for multi-platform releases. The presence of linuxarm64.yml suggests ARM64 support was recently added; no specific PR/issue data visible, but the active build matrix indicates quarterly to monthly release cadence.

git clone https://github.com/GhostTroops/scan4all.git
cd scan4all
make -f Makefile.cross-compiles  # Builds cross-platform binaries
# OR for native build:
go build -o scan4all .
./scan4all -h

Daily commands:

# Basic scan
./scan4all -l <targets.txt>

# With config
./scan4all -l targets.txt -c config.yaml

# Enable nmap fast scanning
config: {priorityNmap: true}

# Enable HTTP password brute-forcing (auto-enabled on 401 responses)
# Enable nuclei integration
./scan4all -l targets.txt -enableNuclei=true

(Exact params in static/usage.md and static/running.md)

• brute/dicts.go: Central registry loading all wordlists from brute/dicts/*.txt and mapping them to protocol-specific brute force functions
• brute/admin_brute.go: Core HTTP Basic Auth and admin credential brute-forcing logic, triggers on 401/403 responses
• config/51pwn/: Dynamic PoC definitions as YAML configs; new vulnerabilities added here without code changes
• brute/filefuzz.go: Web path/file fuzzing engine rewritten from vscan; uses brute/dicts/filedic.txt and fuzz404.txt
• brute/fuzzfingerprints.go: 7,000+ web fingerprint matching logic for service identification
• config.yaml: Main runtime config: enables priorityNmap, HTTP auth, nuclei, nmap parameters, target lists
• .goreleaser.yaml: Controls automated multi-platform binary generation (Linux x86/ARM64, Windows, macOS) for GitHub releases
• Makefile.cross-compiles: Explicit cross-compilation targets for all supported platforms without goreleaser overhead

Start here for common changes: (1) New password protocol: add handler in brute/ following brute/mysql_brute.go pattern, register in dicts.go; (2) New PoC: create YAML file in config/51pwn/protocol_name.yaml following config/51pwn/Actuator.yaml or AEM_misconfig.yaml structure; (3) New wordlist: add .txt file to brute/dicts/ and reference in dicts.go; (4) Fuzz rules: modify brute/fuzzfingerprints.go and brute/filefuzz.go; (5) Port fingerprints: update brute/supportinfo.go.

1. nmap mode (priorityNmap: true) requires nmap binary and root/sudo access; will silently fall back to internal scanning if nmap absent. 2. config.yaml uses YAML structure with Go unmarshaling quirks (check enableNuclei vs priorityNmap naming consistency). 3. brute/dicts/ wordlists are embedded or loaded at runtime—regenerate if modifying dictionaries. 4. PoC YAML files in config/51pwn/ are dynamically loaded, malformed YAML will panic the entire scan. 5. Integrated tools (nuclei, ksubdomain, subfinder) must be in PATH or bundled; missing binary errors may not surface until that protocol is triggered. 6. HTTP Basic Auth brute-force auto-triggers on 401 but respects brute/dicts/httpass.txt and httpuser.txt size limits—large custom dicts slow the scan.

• Dictionary-based brute-force with protocol multiplexing — scan4all loads protocol-specific wordlists (brute/dicts/top100pass.txt, httpass.txt) and concurrently attempts credentials across 23 different services (SSH, RDP, MySQL, Oracle, Redis, etc.) in one scan—understanding this avoids re-running single-protocol crackers.
• YAML-driven PoC templating with dynamic loading — New vulnerabilities are added to config/51pwn/*.yaml without recompiling the binary; this is how scan4all stays current with CVEs—critical to understand for maintaining custom PoC collections and avoiding hardcoded vulnerability logic.
• Web fingerprinting with regex + header matching — brute/fuzzfingerprints.go identifies 7,000+ services (CMS, frameworks, cloud platforms) by matching HTTP response headers, HTML tags, and status codes—this is how scan4all auto-selects which PoCs and brute-force wordlists to apply to each target.
• Concurrent goroutine-based port and protocol scanning — Go's lightweight goroutines allow scan4all to scan 146 protocols across 10,000+ ports on large target lists without spawning separate OS processes—this is why it's 'lightweight' compared to Bash-wrapped tools and essential for understanding timeout/resource constraints.
• Fuzz-based path discovery with 404-page normalization — brute/filefuzz.go (rewritten from vscan) discovers hidden web files/paths by fuzzing against a target's 404 baseline—understanding how it normalizes false positives (HTTP 403 vs 404 vs 200) is crucial for tuning false-positive rates in CI/CD environments.
• nmap integration with automatic fallback detection — When priorityNmap: true is set, scan4all prefers nmap for faster port scanning but silently falls back to internal scanning if nmap is absent—understanding this auto-switching prevents confusing results when nmap is missing or lacks permissions.
• Protocol-specific credential attack chains (T3/IIOP for Weblogic, etc.) — Different services require different handshake protocols (e.g., Weblogic T3 protocol, SMB dialect negotiation)—scan4all includes specialized handlers per protocol in brute/*.go files to avoid generic HTTP-only authentication assumptions.

• projectdiscovery/nuclei — Template-based vulnerability scanner that scan4all integrates via enableNuclei flag; Nuclei provides YAML PoC framework that scan4all's config/51pwn/ files follow
• projectdiscovery/subfinder — Subdomain enumeration tool integrated into scan4all for multi-stage reconnaissance; provides target expansion before port/vulnerability scanning
• nmap/nmap — Port scanner optionally used by scan4all when priorityNmap=true; scan4all wraps nmap with optimized parameter tuning for faster enumeration
• projectdiscovery/ksubdomain — DNS enumeration tool integrated into scan4all's initial reconnaissance phase for large target lists
• X1r0z/ActiveRecon — Alternative Python-based active reconnaissance framework; scan4all's Go approach prioritizes speed and cross-platform deployment over ActiveRecon's module flexibility

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for brute force modules (brute/*.go)

The brute force package contains 10+ modules (admin_brute.go, basic_brute.go, jboss_brute.go, tomcat_brute.go, weblogic_brute.go, etc.) with no visible test files. These are critical security modules that would benefit from regression tests, especially for password crack logic and credential validation. This improves code reliability and prevents future vulnerabilities.

• [ ] Create brute/*_test.go files for each module (admin_brute_test.go, tomcat_brute_test.go, weblogic_brute_test.go, jboss_brute_test.go)
• [ ] Add test cases for credential validation against mock services/responses
• [ ] Add test cases for dictionary loading from brute/dicts/*.txt files
• [ ] Ensure test coverage for bypass403.go logic with various HTTP response codes
• [ ] Run 'go test ./brute/...' in CI/CD pipeline

Create GitHub Actions workflow to validate POC YAML configs (config/51pwn/*.yaml)

The repository contains 100+ POC configuration files in YAML format but no validation pipeline. This causes silent failures if configs are malformed or missing required fields. A workflow to parse and validate all YAML files against a schema would catch errors early and improve maintainability.

• [ ] Create .github/workflows/validate-pocs.yml workflow
• [ ] Use yamllint or similar tool to validate YAML syntax in config/51pwn/*.yaml
• [ ] Define a schema (as JSON Schema or Go struct validation) for required POC fields (name, description, request pattern, etc.)
• [ ] Add validation step to check for missing CVE/CNVD references in filenames vs. content
• [ ] Make workflow required status check for PRs modifying config/ directory

Add integration tests for fingerprint matching logic (brute/fuzzfingerprints.go)

The fuzzfingerprints.go module claims to match 7000+ web fingerprints but lacks visible test coverage. This is a core detection feature that needs validation against real-world responses. Adding integration tests would improve fingerprint accuracy and prevent regression.

• [ ] Create brute/fuzzfingerprints_test.go with test cases for known web frameworks (Apache, Nginx, IIS, Tomcat, etc.)
• [ ] Add mock HTTP response fixtures in brute/testdata/ directory with sample headers and body signatures
• [ ] Test fingerprint detection for both exact matches and partial/fuzzy matches
• [ ] Add benchmark tests to ensure fingerprint matching stays performant with 7000+ rules
• [ ] Document test scenarios in brute/README.md

• Add integration tests for brute/mysql_brute.go, brute/ssh_brute.go, and brute/rdp_brute.go—currently only brute/dicts/test.go exists; would improve reliability of protocol handlers before production scans.
• Expand brute/dicts/404url.txt and brute/dicts/filedic.txt with 1,000+ modern framework paths (Next.js/.next, SvelteKit/.svelte-kit, Spring Boot /actuator/*, Laravel storage/) not covered in current 7,000 fingerprints; test against BuiltWith top-100 frameworks.
• Document all 146 supported protocols and their config.yaml flags in static/usage.md—currently only lists 23 password-crack protocols; add protocol maturity (stable/experimental/legacy) and example configs for SMB MS17-010, Elasticsearch WAP-WSP, and RouterOS detection.

This is a penetration testing and vulnerability scanning tool ('scan4all') designed for authorized security testing. The security

• High · Exposed Credential Dictionaries — brute/dicts/ directory (httpuser.txt, httpass.txt, top100pass.txt, jbossuserpass.txt, tomcatuserpass.txt, weblogicuserpass.txt). The repository contains multiple plaintext credential dictionaries in the brute/ directory including usernames (httpuser.txt), passwords (top100pass.txt, jbossuserpass.txt, tomcatuserpass.txt, weblogicuserpass.txt). These files are committed to version control and publicly accessible, making them valuable for attackers. Fix: Move credential dictionaries to external, private repositories or encrypted storage. Use environment variables or secure vaults to manage sensitive word lists. Implement .gitignore rules to prevent accidental commits of credential files.
• High · Extensive Hardcoded Vulnerability Patterns — config/51pwn/ directory (CVE-*.yaml, CNVD-*.yaml files). The config/51pwn/ directory contains 90+ YAML files with CVE and vulnerability exploitation patterns that could be misused. While POC repositories are common, the scale (15000+ POCs) and organization suggests this could facilitate malicious attacks if the tool is compromised or misused. Fix: Implement strict access controls and rate limiting in the tool. Add warnings about responsible disclosure. Consider requiring explicit opt-in for sensitive exploit modules. Implement logging and monitoring of POC usage.
• Medium · Potential Credential Brute Force Tool Misuse — brute/admin_brute.go, brute/jboss_brute.go, brute/tomcat_brute.go, brute/weblogic_brute.go, brute/basic_brute.go. The brute/ directory contains specialized modules for credential brute forcing against JBoss, Tomcat, WebLogic, and generic admin interfaces. While legitimate for authorized security testing, the tool could be easily weaponized for unauthorized access attempts. Fix: Add warnings and disclaimers about authorized testing only. Implement audit logging of brute force activities. Consider adding rate limiting and detection evasion warnings. Require explicit user acknowledgment of responsible use before deployment.
• Medium · Authentication Bypass Module — brute/bypass403.go. The brute/bypass403.go file indicates functionality to bypass HTTP 403 Forbidden restrictions. This could be misused to circumvent access controls on systems without authorization. Fix: Clearly document that this module is for authorized testing only. Implement mandatory authentication and authorization checks before execution. Add comprehensive audit logging of bypass attempts.
• Medium · Fuzzing Capabilities with Potential for Abuse — brute/fuzzAI.go, brute/filefuzz.go, brute/fuzzfingerprints.go, brute/dicts/fuzz404.txt. Multiple fuzzing modules (fuzzAI.go, filefuzz.go, fuzzfingerprints.go, fuzz404.txt) provide application fuzzing and reconnaissance capabilities that could be used for DoS attacks or unauthorized system probing. Fix: Implement rate limiting and resource constraints for fuzzing operations. Add detection mechanisms to prevent DoS abuse. Require explicit target authorization before running fuzz operations. Implement request throttling.
• Low · Build Artifact Management — .github/workflows/build.yml, .github/build/, .goreleaser.yaml. The .github/workflows and .goreleaser.yaml files indicate automated CI/CD builds across multiple platforms. While useful, ensure build artifacts are not distributing vulnerable versions. Fix: Implement security scanning in CI/CD pipeline. Sign releases cryptographically. Maintain detailed changelog of security patches. Use semantic versioning for vulnerability tracking.
• Low · Missing Input Validation Indication — brute/ directory, entire scanning framework. No visible input validation framework in file structure for the scanning/fuzzing/brute force modules, which is common in attack tools but represents a risk area. Fix: Implement comprehensive input validation and sanitization. Use parameterized requests and safe encoding. Validate all user-supplied targets and parameters. Implement request whitelisting where possible.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.