RouterSploit: an exploitation framework for embedded devices

What RouterSploit is for, and who is expected to run it

RouterSploit targets a category of hardware that general purpose scanners handle badly: routers, access points and other embedded devices. The README describes the framework as "an open-source exploitation framework dedicated to embedded devices" and lists five module families. Exploits act on identified vulnerabilities. Creds modules test credentials against network services, which is why the repository topics include bruteforce and dictionary-attack. Scanners check whether a target is vulnerable to a given exploit. Payloads generate output for particular architectures and injection points. Generic modules cover attacks that do not fit the other four.

The intended reader is a penetration tester or an embedded security researcher working through a defined engagement, not an administrator auditing a home network. The module split reflects that workflow: you scan first, then decide whether an exploit applies, then optionally push a payload. Because the tool ships modules for specific device families rather than generic vulnerability signatures, coverage is uneven by design. A device nobody wrote a module for is simply not covered, and the README does not claim otherwise.

How the interactive shell and module tree fit together

The entry point is rsf.py at the repository root, and the framework logic lives in the routersploit package. Running rsf.py drops you into an interactive shell, which the README's asciinema recording demonstrates. From there the module families appear as a tree: exploits, creds, scanners, payloads and generic. Selecting a module loads it and exposes its options, and you set the target before running it.

That shell is not incidental. The README's "Build your own" section notes that people forked the project not for embedded security but to reuse the shell logic, and points them at Riposte, a separate project by fwkz that wraps an application in a tailored interactive shell. The maintainers effectively say the REPL plumbing is not the interesting part and should not be copied. For a user, the practical consequence is that RouterSploit is a collection of device-specific modules behind a common interface, not a scanning engine with a plugin API. When a module fails, the shell gives you no structured diagnosis. You read the module's Python.

Installing RouterSploit on Linux, macOS or Docker

The README gives per-platform instructions. On Kali Linux the sequence is a pip install, a clone and a run. Note that the README's Kali and OSX blocks still show the pycrypto dependency name, while setup.py and requirements.txt both list pycryptodome; install from requirements.txt so you get the maintained package.

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

On Ubuntu 20.04 the same steps run under sudo for the package install:

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

If you would rather not touch the host Python, the repository ships a Dockerfile and a docker-compose.yaml. The compose file builds the image, names the container routersploit, and keeps stdin open with a TTY so the shell is usable. The Dockerfile builds on python:3.9-bookworm and creates an unprivileged rts user before copying requirements.txt, the routersploit package and rsf.py.

git clone https://www.github.com/threat9/routersploit
cd routersploit
docker compose up --build -d
docker attach routersploit

To return to the shell later without rebuilding, the README gives two commands:

docker start routersploit
docker attach routersploit

Bluetooth Low Energy support is optional and needs libglib2.0-dev plus the bluepy package. On Debian-derived systems that is apt-get install libglib2.0-dev followed by python3 -m pip install bluepy, then python3 rsf.py again. After the shell starts, the first real use is to pick a scanner for a device you have permission to test, set its target option, and run it. The README does not walk through that flow, so read the module's own option list before executing anything.

The release history is the real limitation

The README says the project "is under heavy development and new modules are shipped almost every day" and tells you to run git pull often. The tagged releases contradict the tone. The most recent release listed is v3.4.0 from 2018-10-17, preceded by v3.3.0 and v3.2.0 in 2018. Meanwhile setup.py declares version 3.4.7 and requires Python 3.9 or newer. So the version string in the package metadata has moved on while the release page has not. Anyone pinning to a tag is pinning to code from 2018.

Commits are a different story: the last push to master was on 2026-05-05. That is recent enough that the repository is not abandoned, but a recent push does not tell you whether a module for your target device was updated, or whether the fix you need landed. Treat the git history, not the release page, as the source of truth, and read the commit that touched the module you intend to run.

There are other constraints worth stating plainly. The project requires Python 3.9 or later per setup.py, which rules out older distributions that still ship 3.6, even though a classifier in setup.py still advertises Python 3.6. There is no published package on an index; installation is a git clone, so updates mean pulling the tree and re-reading the code you depend on. And the README documents no rollback procedure for a payload that has been delivered to a device, which is a gap if you are testing hardware you cannot easily reflash.

Where RouterSploit is the wrong tool

RouterSploit is not a general purpose vulnerability scanner. It has no CVE feed and no signature database that updates independently of the code; a vulnerability is covered only if someone wrote a module for it. If your engagement is a broad network assessment across mixed assets, a scanner built around service detection and version matching will cover more ground with less per-device effort. RouterSploit earns its place when the target is a known embedded device and a module exists.

It is also the wrong tool for unattended or scheduled scanning. The interface is an interactive shell, and the Docker setup is built around attaching to a TTY, not around emitting machine-readable results to a pipeline. The README describes no output format, no report generation and no non-interactive mode. If you need to run checks on a schedule and parse the results, you will be writing that layer yourself.

Finally, the credential modules are dictionary attacks against network services. Against a device that locks out after repeated failures, or one whose logs feed an alerting system, running them without coordinating with the device owner produces noise and possibly a lockout that outlasts your test window. The README does not discuss lockout behaviour.

How it differs from Metasploit and from Riposte

The obvious comparison is Metasploit. Metasploit is a general exploitation framework with a much larger module set spanning servers, desktops and network services, and it ships its own database, session handling and reporting. RouterSploit narrows the scope to embedded devices and keeps the surface small: a Python package, a requirements file, and a shell. If your target is a router, RouterSploit's modules are written with that hardware in mind, including the credential and scanner families that exist specifically for it. If your target is anything else, Metasploit is the broader instrument. The two are not mutually exclusive, but RouterSploit does not try to be a general platform.

The second comparison comes from the project itself. The README's "Build your own" section directs anyone who wants the shell rather than the exploits to Riposte, described as a way to "easily wrap your application inside a tailored interactive shell" with the common REPL chores factored out. That is a different goal: Riposte is a library for building a shell around your own domain logic, while RouterSploit is an application that happens to use one. If you arrived because you liked the interface, Riposte is the project the maintainers point you to.

Licence, upgrades and what to check before you commit

The README states the RouterSploit Framework is under a BSD license and points to the LICENSE file for details. The repository metadata, however, reports the licence as NOASSERTION, meaning the automated detection could not confirm a standard identifier. Those two signals disagree, and the LICENSE file is the one that governs. Read it before you redistribute the code or bundle it into a product; this article is not legal advice and cannot tell you which terms apply.

Upgrading is a git pull, per the README, followed by re-running python3 -m pip install -r requirements.txt because the dependency set can change between pulls. requirements.txt pins requests at 2.32.2 and leaves paramiko, pysnmp and pycryptodome unpinned, so a pull can silently move those three. If you need reproducibility, pin them in your own environment rather than relying on the file.

Because the tool is unmaintained in the release sense, the upgrade cost is mostly your own reading time. Every pull can change a module you depend on, and there is no changelog in the repository to tell you which. The Docker path softens this: the image is built from a fixed base, python:3.9-bookworm, so at least the interpreter version is stable across rebuilds.

Editorial conclusion

RouterSploit suits penetration testers and embedded security researchers who already have written authorisation to test specific hardware, and who are comfortable reading module source when the interactive shell gives no output. It is the wrong choice for anyone who wants a maintained, continuously updated product: the last push was on 2026-05-05, but the most recent tagged release, v3.4.0, dates from 2018-10-17, while setup.py declares version 3.4.7. Before relying on it, verify that the module you need exists for your target and read its code, then confirm the LICENSE file's exact terms, since the repository metadata reports NOASSERTION rather than the BSD licence the README names.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. threat9/routersploit on GitHub