# ScanT3r: a Rust DAST scanner where every check is a trait

> ScanT3r is a module based dynamic web scanner written in Rust, currently shipping four modules for XSS, SSTI, out of band SSRF and exposed Firebase databases. It suits bug bounty hunters who want a small CLI they can extend in Rust, and it is thin on checks, with SQLi and RCE sitting on the roadmap.

**MindPatch/scant3r** — ScanT3r - Module based Bug Bounty Automation Tool ( use Lotus instead github.com/bugBlocker/lotus )

- Repository: https://github.com/MindPatch/scant3r
- Website: https://scant3r.knas.me/
- Stars: 686 · Forks: 149
- Language: Rust
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/mindpatch-scant3r

## A DAST scanner whose checks are Rust traits

ScanT3r is a dynamic application security testing tool written in Rust, delivered as a command line program. The repository description calls it a module based bug bounty automation tool, and the README describes it as a fast DAST CLI tool.

The audience is narrow and worth stating plainly: security engineers and bug bounty hunters who want a scanner they can extend themselves, rather than a hosted platform or a large suite with a configuration language. The extension model is a single Rust trait per check, and the README says it in one line: New module = one trait in src/modules/mod.rs. That is a low ceremony way to add a check, but it also means the people who can extend it have to be comfortable in Rust.

The repository layout backs up a small, focused tool. Beyond the usual Rust files there is a Dockerfile, a tests directory, and a src/ directory that holds the module definitions. There is no web interface and no service to deploy. The README points to a homepage at scant3r.knas.me, but the project itself is the binary.

## Four modules, and what each one actually looks for

The module table in the README lists four checks, and each targets a different class of finding:

- xss: reflected XSS with context aware payloads
- ssti: Server-Side Template Injection
- req_callback: out of band resource load, described as blind SSRF, using interact.sh
- firebase: public Firebase databases, read and write

The design detail worth noticing is the context awareness in the XSS module. Reflected XSS detection is mostly a question of where a payload lands, whether in HTML text, inside an attribute, or in a script context, because the escaping differs in each. A scanner that only reflects a fixed wordlist will miss the cases where a naive payload is already filtered but a context specific one is not.

The req_callback module is different in kind. Instead of looking at the response, it triggers an outbound request and watches an interact.sh callback, which is how a blind SSRF is detected at all when the response carries no visible signal.

The firebase module is not a vulnerability scanner in the injection sense. It looks for publicly reachable Firebase databases, and the README says read and write, so a finding here can be about an open datastore rather than an exploitable request.

## Building it takes a clone and a cargo install

There is no binary release in the instructions. The README's install section is a clone followed by a cargo install against the local path, which means a Rust toolchain has to be present before anything works:

```bash
git clone https://github.com/MindPatch/scant3r && cd scant3r
cargo install --path .
```

The dependency list in Cargo.toml shows what this buys. Request handling is reqwest with rustls-tls and cookies enabled rather than the system OpenSSL, concurrency is tokio with the full feature set, the command line is parsed with clap and derive, and indicatif provides the progress bar that matters when you run against a long target list. There is a scraper dependency for parsing HTML, a rand dependency, and crypto crates for rsa, sha2, aes and cfb-mode, which is consistent with a tool that has to sign and encrypt payloads for the checks it performs. Tracing and tracing-subscriber are there for logging, and the release profile enables lto with a single codegen unit.

Because the project is published as a cargo package named scant3r, the install step also produces a scant3r binary on your path.

## Three ways to feed it targets, and what the flags control

The usage examples cover the three input styles you are likely to need, and each one is a single line. A target can be piped in on standard input with the all modules selected:

```bash
# pipe a target, run all modules
echo "http://testphp.vulnweb.com/listproducts.php?cat=1" | scant3r -m all

# targets list, JSON report, 100 workers
scant3r -l targets.txt -m xss,ssti -w 100 -o report.json

# through Burp, with cookies
scant3r -u "http://target.com/search?q=1" -m all -p http://127.0.0.1:8080 -C "session=abc123"
```

The -m flag takes a comma separated module list, so a scan can be narrowed to the checks you actually care about, and -l reads a file of targets. The -w flag sets the number of workers, and -o writes a JSON report, which is what you would feed into a triage step later. The -u flag passes a single URL, -p points at a proxy, and -C sends a cookie string.

That proxy option is the one with the most practical value. Sending traffic through a local Burp instance lets you reuse an authenticated session, and the example shows a session cookie being replayed with -C. The README also says to run scant3r --help for the full option list, so the three examples above are a starting set rather than the complete surface.

## The Docker image is a single static binary on debian

A Dockerfile at the repository root builds a slim runtime image. The build stage compiles in rust:1-slim, and the runtime stage copies only the release binary onto debian:bookworm-slim with ca-certificates installed:

```dockerfile
FROM rust:1-slim AS builder
WORKDIR /scant3r
COPY . .
RUN cargo build --release

FROM debian:bookworm-slim
RUN apt-get update \
    && apt-get install -y --no-install-recommends ca-certificates \
    && rm -rf /var/lib/apt/lists/*
COPY --from=builder /scant3r/target/release/scant3r /usr/local/bin/scant3r
ENTRYPOINT ["scant3r"]
CMD ["-h"]
```

The entrypoint is the scanner itself and the default command is the help text, so the image behaves like the CLI with arguments appended. There is no shell wrapper or configuration file in the image, which means every option, including the module selection and the report path, has to be passed on the command line. One detail to plan for: the report written with -o lands inside the container filesystem unless you mount a volume, so a CI job that wants the JSON afterwards has to bind a path.

The ca-certificates package is not incidental. The reqwest dependency is configured with rustls-tls, and TLS verification against public hosts needs a trust store, so running the image without it would break every https target.

## The roadmap is the honest limit on what it finds

This is where the tool's scope shows. The README roadmap lists more modules as unchecked items: SQLi, path traversal, RCE and open redirect. It also lists AI payload generation described as context and WAF aware, replacing static wordlists, AI triage of findings to reduce false positives, a REST API mode, and a headless browser module.

Every one of those is unchecked. So a scan today covers reflected XSS, SSTI, out of band SSRF and Firebase exposure, and nothing else. If your target space is a login flow with SQL injection or an API with path traversal, ScanT3r will not find it, and no amount of worker count changes that.

The extension path is the answer, and it is genuinely light. Writing one trait in src/modules/mod.rs is the documented cost of adding a check, and the crate already carries the async runtime, the HTTP client, the HTML scraper and the crypto primitives that a new check would need. A team with Rust skills can close the gap that the roadmap leaves open. A team without them cannot.

## Version numbers, licence, and the successor already named

Two things to be careful about before you pin this. The Cargo manifest declares version 1.0.0 with edition 2021, while the newest GitHub release is 0.9.3 dated 2022-06-13, and the two before it are 0.9.2 and v0.2.3-rs. The release list has not moved in a long time even though the last push to the repository was on 2026-10-04, so the work is happening on master without tagged releases. If you depend on this in a pipeline, pin a commit rather than a version number, and expect to track master yourself.

The licence is GPL-3.0, stated in the README and in the Cargo manifest. That is a meaningful constraint if you intend to modify ScanT3r and keep the result closed, because GPL obligations attach to derived works, and this is not legal advice.

There is one more signal worth reading carefully: the repository description itself ends with a note telling users to use Lotus at github.com/bugBlocker/lotus instead. The author is pointing people at a different project, which is a reasonable signal about where active development now sits, and it is worth checking that project before you invest in extending ScanT3r yourself.

## Conclusion

Adopt ScanT3r if you want a small, self hosted CLI that you can extend with your own Rust module, and if reflected XSS, template injection and out of band SSRF cover the checks you care about today. Do not adopt it as a general purpose scanner, since SQLi, path traversal, RCE and open redirect are still unchecked roadmap entries and there is no REST API or headless browser mode. Verify first that cargo install --path . produces a working binary in your environment, and note that the Cargo manifest says version 1.0.0 while the newest GitHub release is 0.9.3 from 2022-06-13.

## FAQ

### How do I install ScanT3r?

The README gives two steps: clone https://github.com/MindPatch/scant3r, then run cargo install --path . from inside the cloned directory. This requires a Rust toolchain, and it produces a scant3r binary on your path.

### Which vulnerability modules does ScanT3r support?

The README lists four: xss for reflected XSS with context aware payloads, ssti for Server-Side Template Injection, req_callback for out of band resource load and blind SSRF through interact.sh, and firebase for public Firebase databases with read and write access.

### How do I add a new check to ScanT3r?

The README states that a new module is one trait in src/modules/mod.rs. Writing a check means implementing that trait, and the dependencies in Cargo.toml already include an async runtime, an HTTP client, an HTML scraper and crypto crates.

### Can ScanT3r scan SQL injection or RCE?

Not yet. The roadmap lists SQLi, path traversal, RCE and open redirect as unchecked items, so a scan today covers XSS, SSTI, blind SSRF and Firebase exposure only.

## Sources

- [License: GPL-3.0](https://github.com/MindPatch/scant3r/blob/master/LICENSE)
- [MindPatch/scant3r on GitHub](https://github.com/MindPatch/scant3r)
- [Project website](https://scant3r.knas.me/)
- [README](https://github.com/MindPatch/scant3r/blob/master/README.md)
- [Releases](https://github.com/MindPatch/scant3r/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mindpatch-scant3r