WAIT — Mixed signals — read the receipts

• Last commit 6d ago
• 35+ active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 54% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ Scorecard: marked unmaintained (2/10)

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

RouterSploit is a modular Python 3 exploitation framework targeting embedded devices (routers, cameras, network appliances) with reusable modules for credential testing, vulnerability scanning, and payload generation. It provides a Metasploit-like CLI interface with modules organized into exploits, scanners, credential testers, payload generators, and generic attack vectors. Monolithic single-directory project: rsf.py is the CLI entry point; modules/ directory contains exploit/, creds/, scanner/, payload/, and generic/ subdirectories mirroring the framework's five attack module types. docs/modules/ mirrors the source structure with .md documentation for each module. No separation between core engine and plugins — all baked into one install.

Penetration testers and embedded device security researchers who need to test router/camera security in labs and authorized environments, without writing custom exploit code for each device type.

Actively maintained but lightweight: the project uses Travis CI (.travis.yml), has structured module documentation, and is built for Python 3.6+. However, it lacks visible test coverage (no test/ directory in top 60 files), and the last notable activity is from the master branch. It's production-ready for authorized security testing but not hardened for public-facing deployment.

Four core dependencies (requests, paramiko, pysnmp, pycryptodome) but minimal version pinning — only requests==2.32.2 is locked. Paramiko and pysnmp are pinned without versions, which risks breaking changes. Single-maintainer (threat9 org) with no visible security policy (no SECURITY.md). Optional bluepy dependency for Bluetooth adds build complexity on some OSes.

Repository appears stable with structured module documentation. The creds/ modules are extensive (cameras by manufacturer: Acti, Axis, Canon, Cisco, etc.). The Dockerfile and docker-compose.yaml suggest recent Docker support. No visible recent PRs or issue tracking in the provided file list, suggesting maintenance-mode status.

git clone https://github.com/threat9/routersploit
cd routersploit
python3 -m pip install -r requirements.txt
python3 rsf.py

Daily commands:

python3 rsf.py

This launches an interactive CLI shell. For Docker:

docker compose up --build -d && docker attach routersploit

• README.md — Entry point documentation describing the RouterSploit framework's purpose, architecture (exploits, creds, scanners, payloads, generic modules), and installation requirements—essential for understanding project scope.
• Dockerfile — Defines the containerized deployment environment and dependencies installation process; critical for reproducible builds and understanding runtime requirements.
• MANIFEST.in — Specifies which files are included in package distribution; controls what gets installed and is load-bearing for module discovery and credential database packaging.
• Makefile — Build and development automation entry point; likely contains targets for testing, installation, and common developer workflows.
• .travis.yml — CI/CD pipeline configuration; defines automated testing and deployment stages that all contributors must respect.
• CONTRIBUTING.md — Contribution guidelines and development standards; mandatory reading for any code submission to understand module structure and testing expectations.

• Scanner Modules (Paramiko, Requests, PySNMP) — Probe target device for running services (SSH, FTP, Telnet, HTTP), detect device type, and identify applicable exploits/credentials
  • Failure mode: Target device unreachable or all services filtered; returns no matches
• Exploit Modules (Python, Paramiko, Requests) — Deliver crafted payloads for identified vulnerabilities; handle target architecture detection and payload customization
  • Failure mode: Payload execution fails (device patches, unexpected firmware, architecture mismatch); exploitation fails silently
• Credential Modules (Paramiko, Requests, Python) — Manage bundled default credentials database and test credentials against services via appropriate protocol
  • Failure mode: All credentials rejected (device has custom credentials); no access gained
• Payload Generator (Python, pycryptodome) — Generate executable payloads for multiple architectures (MIPS, ARM, x86) and injection points (command injection, buffer overflow)
  • Failure mode: Payload compilation fails; device architecture not supported; payload size exceeds buffer limits
• CLI Interface (Python) — User interaction layer; loads modules, manages target configuration, displays results
  • Failure mode: Invalid module path; missing target parameters; user aborts operation

• User input → CLI Interface — User specifies target IP, port, module type, and exploitation parameters
• CLI Interface → Module Loader — Framework loads selected exploit, scanner, or

Add a new credential module for a device manufacturer

1. Create manufacturer directory structure following existing pattern (e.g., Axis, Hikvision) (docs/modules/creds/cameras/{manufacturer}/)
2. Add credential documentation files for each protocol (ftp_default_creds.md, ssh_default_creds.md, telnet_default_creds.md) (docs/modules/creds/cameras/{manufacturer}/ftp_default_creds.md)
3. Register module in MANIFEST.in to include credential data in distribution (MANIFEST.in)
4. Update README.md or docs/modules to reflect new credential module availability (README.md)

Add a new exploit module for a vulnerability

1. Create exploit module file in docs/modules/exploits/{category}/{device_type}/ following naming convention (docs/modules/exploits/)
2. Document the exploit with vulnerability details, affected devices, and exploitation steps (docs/modules/exploits/{category}/{device_type}/{exploit_name}.md)
3. Update MANIFEST.in to include exploit module in distribution (MANIFEST.in)
4. Add scanner module if automatic vulnerability detection is required (docs/modules/scanners/)

Add a new payload generator

1. Create payload module directory under docs/modules/payloads/{architecture}/ (docs/modules/payloads/)
2. Implement payload generation for specific architecture and injection point (docs/modules/payloads/{architecture}/{payload_type}.md)
3. Include payload dependencies in requirements (mips, arm, x86, etc.) if needed (Dockerfile)
4. Document payload usage and supported injection points in module documentation (README.md)

• Python 3.6+ — Cross-platform compatibility for penetration testing; allows rapid module development and integration of security libraries (paramiko, pysnmp)
• Paramiko (SSH/SFTP) — Pure-Python SSH implementation enabling remote command execution and file transfer without external SSH binaries
• PySNMP — SNMP protocol support for network device enumeration and configuration retrieval (common on embedded devices)
• Requests — HTTP client for web-based exploitation and credential testing against HTTP/HTTPS device interfaces
• Docker & Compose — Containerized deployment ensures consistent environment across all systems; simplifies dependency management for embedded exploitation tools

• Modular architecture with separate exploit, creds, scanner, and payload modules

  • Why: Allows independent development and testing of modules; enables community contributions without breaking core framework
  • Consequence: Added complexity in module discovery and initialization; requires standardized module interfaces

• Default credentials organized by manufacturer and protocol (FTP, SSH, Telnet)

  • Why: Reflects real-world embedded device landscape where manufacturers use baked-in defaults; easy to augment with new devices
  • Consequence: Creates large credential database (50+ manufacturers); requires frequent updates as vendors change defaults

• Framework operates offline with bundled credential/exploit data

  • Why: Removes dependency on external databases; enables operation in isolated networks; faster execution
  • Consequence: Credential data can become stale; manual updates required when new vulnerabilities discovered

• Python-only implementation without C extensions

  • Why: Easier to audit for security; avoids compilation issues across architectures; simpler installation
  • Consequence: Slower than native implementations for payload generation; may impact large-scale scanning operations

• Does not perform active network reconnaissance—user must provide target IP/hostname
• Does not maintain persistent C2 channels; focuses on one-time exploitation or credential testing
• Not a vulnerability scanner for network-wide assessment; designed for single-target exploitation
• Does not include antivirus evasion or traffic encryption bypasses
• Not intended for Windows-based embedded devices; targets Linux/embedded OS devices

1. Paramiko/PySNMP/PyCryptodome are unpinned in requirements.txt; you may get incompatible versions without explicit pinning (requests is the only locked version). 2) Bluetooth support (bluepy) requires libglib2.0-dev on Linux; missing it silently breaks BLE modules. 3) The module auto-discovery expects a specific file/class naming convention (not documented in provided files); trial-and-error needed to add custom modules. 4) rsf.py is a single entry point with no separate test runner; no obvious way to run tests in isolation.

• Paramiko SSH/Telnet Protocol — RouterSploit's creds modules heavily use Paramiko to test default SSH and Telnet credentials on routers/cameras; understanding Paramiko's transport layer is critical for debugging auth failures
• Default Credential Enumeration — The entire creds/ module tree (ftp_default_creds, ssh_default_creds, telnet_default_creds) is built on testing manufacturer default credentials; this is how RouterSploit gains initial access
• SNMP MIB Enumeration — RouterSploit uses PySNMP for SNMP-based scanning and info gathering on network devices; understanding OIDs and MIBs helps extend scanner modules
• Module Auto-Discovery Pattern — RouterSploit dynamically loads all .py files from modules/ subdirectories at runtime without explicit registration; understanding this pattern is essential for adding new exploits or scanners
• Embedded Device Exploitation — RouterSploit targets non-standard architectures (MIPS, ARM) and limited OS environments (uClibc, OpenWrt); payloads must account for this hardware diversity
• Telnet vs SSH Security Risk — Many RouterSploit targets still run Telnet (unencrypted); the framework tests both to demonstrate why devices should disable Telnet in favor of SSH

• rapid7/metasploit-framework — Industry-standard exploitation framework with similar modular architecture; RouterSploit is a specialized embedded-device fork
• offensive-security/exploit-database — Searchable PoC repository for published vulnerabilities; RouterSploit's exploits are often based on CVEs documented here
• bettercap/bettercap — Network attack framework for MITM and credential harvesting; complements RouterSploit for network-level device targeting
• fwts/fwts — Firmware testing suite for embedded Linux; RouterSploit targets running devices while fwts tests extracted firmware
• threat9/vulnerability_tools — Same maintainer's toolkit; likely contains utilities for credential harvesting and device fingerprinting used by RouterSploit

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 Python 3.9+ compatibility testing and update CI pipeline

The repo targets Python 3.6 (outdated, EOL since Dec 2021) but lacks explicit testing for Python 3.9+. The .travis.yml exists but the README badge only mentions 3.6. Dependencies like paramiko and pycryptodome have evolved significantly. Adding GitHub Actions workflow to test against Python 3.8-3.12 would catch compatibility issues early and modernize the project.

• [ ] Create .github/workflows/python-tests.yml with matrix testing for Python 3.8, 3.9, 3.10, 3.11, 3.12
• [ ] Update README.md badge from Python 3.6 to reflect supported versions
• [ ] Test all imports from paramiko, pysnmp, pycryptodome against multiple Python versions in the workflow
• [ ] Verify Dockerfile uses appropriate Python base image version

Add unit tests for credential modules structure validation

The docs/modules/creds/ directory contains 100+ markdown files documenting default credentials for devices (cameras across vendors like Axis, Cisco, D-Link, Hikvision, etc.). There's no apparent test coverage to validate that credential modules (the actual Python code) match documented format, have required fields, or follow consistent structure. A test suite would prevent regressions.

• [ ] Create tests/ directory with test_credential_modules.py
• [ ] Add tests to validate each creds module has required attributes (name, description, target_service)
• [ ] Add tests to ensure all documented credential files in docs/ have corresponding module implementations
• [ ] Integrate test execution into CI pipeline (.travis.yml or new GitHub Actions workflow)

Add security policy and vulnerability disclosure workflow

A security-focused exploitation framework needs SECURITY.md and responsible disclosure process. The repo lacks .github/SECURITY.md despite having CONTRIBUTING.md and issue templates. This is critical for users discovering vulnerabilities in routersploit itself or devices tested with it.

• [ ] Create .github/SECURITY.md with vulnerability reporting guidelines and contact method
• [ ] Add GitHub Security Advisory template for coordinated disclosure
• [ ] Document safe testing practices and legal disclaimers in SECURITY.md
• [ ] Reference SECURITY.md from README.md and CONTRIBUTING.md

• Add unit tests for routersploit/modules/creds/ credential modules — currently no test/ directory exists; start with mock tests for SSH/FTP/Telnet cred checkers.
• Pin Paramiko, PySNMP, and PyCryptodome versions in requirements.txt with safe upper bounds — only requests==2.32.2 is locked, risking breaking changes from unpinned transitive deps.
• Document the module auto-discovery and plugin architecture in a developer guide (CONTRIBUTING.md exists but doesn't explain how to add new exploits/scanners); create docs/DEVELOPMENT.md with code examples.

• High · Outdated Python Base Image with Known Vulnerabilities — Dockerfile, line 1. The Dockerfile uses Python 3.9-bookworm which is no longer actively maintained. Python 3.9 reached end-of-life on October 5, 2023. This base image may contain unpatched security vulnerabilities in the OS and Python runtime. Fix: Update to Python 3.12 or 3.13 LTS (FROM python:3.13-bookworm) to ensure security patches and long-term support.
• Medium · Missing Package Hash Verification — Dockerfile, line 12. The pip install command in Dockerfile does not use hash checking (--require-hashes flag). This allows potential man-in-the-middle attacks or compromised package distribution attacks. The requirements.txt file is not provided for detailed inspection of pinned versions. Fix: Use --require-hashes with requirements.txt that contains hash values for all dependencies. Example: pip install --user --require-hashes -r requirements.txt
• Medium · Unpinned Dependency Versions — requirements.txt (based on provided dependencies). Dependencies like 'paramiko', 'pysnmp', and 'pycryptodome' lack specific version pinning in requirements.txt. While requests==2.32.2 is pinned, unpinned dependencies can lead to unexpected breakage or security issues from automatic updates. Fix: Pin all dependencies to specific versions: paramiko==3.x.x, pysnmp==5.x.x, pycryptodome==18.x.x. Regularly review and update versions after testing.
• Medium · Known Vulnerability in requests Library Dependency Chain — requirements.txt. The requests==2.32.2 dependency may have transitive dependencies with known vulnerabilities. urllib3 (dependency of requests) and other packages should be explicitly pinned and monitored. Fix: Run 'pip install safety' and 'safety check' to identify vulnerable dependencies. Pin all transitive dependencies explicitly in requirements.txt.
• Medium · Non-Root User Without Privilege Escalation Prevention — Dockerfile, lines 5-7. While the Dockerfile creates a non-root user 'rts', there is no explicit prevention of privilege escalation. The USER directive is applied late in the build process, after most setup is complete. Fix: Add security options: (1) Use 'USER rts' earlier in the process, (2) Add --security-opt=no-new-privileges:true in docker-compose.yaml, (3) Drop unnecessary capabilities with cap_drop in docker-compose.yaml
• Medium · Missing Network Security Configuration in Docker Compose — docker-compose.yaml. The docker-compose.yaml does not specify network isolation or resource limits. The service has stdin_open and tty enabled, which may create interactive security risks if the framework is exposed. Fix: Add network: 'routersploit-net' with custom bridge network, set resource limits (memory, cpus), and remove stdin_open/tty unless absolutely necessary. Add cap_drop: ['ALL']
• Low · Hardcoded Default Credentials Documentation — docs/modules/creds/. The extensive documentation of default credentials for various devices (cameras, routers) in the docs/modules/creds directory, while helpful for penetration testing, could be misused if the repository is accessed by unauthorized parties or if sensitive credentials are accidentally committed. Fix: Ensure repository access is restricted. Consider moving sensitive credential databases to a separate private repository or encrypted storage. Implement pre-commit hooks to prevent accidental credential commits.
• Low · Travis CI Configuration Exposure — .travis.yml, .travis/. The .travis.yml and .travis/ directory structure are present. If CI/CD secrets are stored in Travis CI, they could be exposed through build logs or environment variable leakage. Fix: Audit all environment variables in Travis CI configuration. Use encrypted secrets only. Consider migrating to GitHub Actions with better secret management. Remove .travis files if no longer in use.
• Low · Missing Security Headers and SBOM — undefined. The codebase lacks a Software Bill of Materials ( Fix: undefined

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

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

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/threat9/routersploit 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.

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

What it runs against: a local clone of threat9/routersploit — 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 threat9/routersploit | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 36 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of threat9/routersploit. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/threat9/routersploit.git
#   cd routersploit
#
# 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 threat9/routersploit and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "Dockerfile" \\
  && ok "Dockerfile" \\
  || miss "missing critical file: Dockerfile"
test -f "MANIFEST.in" \\
  && ok "MANIFEST.in" \\
  || miss "missing critical file: MANIFEST.in"
test -f "Makefile" \\
  && ok "Makefile" \\
  || miss "missing critical file: Makefile"
test -f ".travis.yml" \\
  && ok ".travis.yml" \\
  || miss "missing critical file: .travis.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 36 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~6d)"
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/threat9/routersploit"
  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).

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