# RouteVulScan: passive path probing inside Burp Suite

> RouteVulScan is a Java extension for Burp Suite that passively probes every layer of the paths it sees in traffic and matches the responses against configurable regular expressions, which finds simple but harmful endpoints that are buried at an unexpected depth. It suits a tester working one site at a time, and it depends on detection rules you can edit in its config file.

**F6JO/RouteVulScan** — Burpsuite - Route Vulnerable Scanning 递归式被动检测脆弱路径的burp插件

- Repository: https://github.com/F6JO/RouteVulScan
- Stars: 1,335 · Forks: 83
- Language: Java
- License: not declared
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/f6jo-routevulscan

## What the extension actually does

RouteVulScan is a Burp Suite extension written in Java, built on the Burp API, whose job is to recursively detect vulnerable paths.

The mechanism is a passive scan driven by rules. When traffic passes through Burp for the first time, the extension probes each layer of the path and matches the response against the configured regular expressions, and the hits are shown in a panel called VulDisplay. The rules let you define the path to request, what to match in the response, and the name of the vulnerability, so the finding is reported with a label rather than a raw snippet.

The passive part is the point of the design. The extension acts on traffic you are already generating, so it does not need a target list, a wordlist or a crawl of its own. The README recommends using it that way, by turning on only the Head button in the configuration, then testing the site normally, clicking through its features, and afterwards selecting any request and sending it to the extension. The stated benefit is that the test skips miscellaneous sites and focuses on the one you care about, while still reaching the corners of it.

That workflow is the plugin's real product. The probing is a means of covering a site you have already explored, not a way of finding a site in the first place.

## The target: simple but harmful flaws at an unexpected depth

The README explains the rationale in a way that is worth repeating, because it describes a class of finding that tools routinely miss.

The plugin focuses on vulnerabilities that are simple but harmful. These are not usually at a fixed path, but may sit at any level of the path. In that case they are very easy to overlook, and using path brute forcing is time consuming and troublesome.

So the design goal is to send a small number of accurate payloads while covering as wide an area as possible, in order to find the easy to miss vulnerabilities.

That is a specific trade against a scanner that throws a wordlist at a host. A wordlist approach is fast to set up and produces noise, because most paths do not exist and the interesting one is often a compound path, an administrative endpoint under an unusual prefix, or a leftover debug page several levels down. By deriving its candidates from paths the application actually serves, the extension spends its requests on combinations that are plausible for that application.

The rules are the other half of the accuracy claim. A response keyword such as a version string, a stack trace or a specific header is what turns a response into a finding, and the extension leaves the choice of those keywords to the tester, which is why the rule file matters more than the probing logic.

## Recursive probing, one path layer at a time

The recursion is literal and easy to follow, because it is described with a concrete example.

For a URL such as https://www.baidu.com/aaa/bbb, the extension probes the path /, then /aaa/, then /aaa/bbb/. Each layer is a separate candidate. If a path segment contains a dot, that layer is skipped, which avoids requesting things that look like filenames.

That is the whole traversal. Each observed path is decomposed into its prefixes, and every prefix becomes a candidate path to request, with the rule deciding what to look for in the answer.

The result is a sweep that follows the shape of the site rather than a list. A site whose structure is /api/v2/users and /api/v2/orders and /admin produces a small number of prefixes, and probing them covers the ancestors of every URL the tester has seen. The extension also applies the same treatment to active scanning, where the historical paths in the site map that share the same host are all probed.

The traversal is not recursive in the algorithmic sense. There is no crawl, no link following and no depth limit, which is what keeps the request count low. What it does have is the thread pool, described as increasing the scanning speed, with a default of 10 threads and a note that the thread count is at most the number of rules, since more threads than rules achieves nothing.

## The rule file and the marker syntax

Rules live in a YAML configuration file, and the extension generates it on first load. The path is in the user configuration directory, ~/.config/RouteVulScan/Config_yaml.yaml on macOS and Linux, and the default rules are built into the extension and initialised into that local file the first time it runs.

The rules can pull values out of the original request and response, and use them as the request path or as the regular expression. The marker syntax is the interesting part of the design.

```
{{request.head.*}}      -- 获取请求中head的各项，如获取cookie，{{request.head.cookie}}
{{request.head.host.main}}  -- 获取host的根域名
{{request.head.host.name}}  -- 获取域名
{{request.method}}      -- 获取请求的方法，如GET/POST
{{request.path}}        -- 获取请求的路径
{{request.url}}         -- 获取完整请求url
{{request.protocol}}    -- 获取请求的协议，如http/https
{{request.port}}        -- 获取请求的端口号
{{response.head.*}}     -- 获取响应中head的各项，如获取server
{{response.status}}     -- 获取响应的状态码
```

So a rule can use the root domain of the host, the domain itself, the method, the path of the triggering request, the status code of the response, or any header from either side. That is what makes the extension able to construct a probe from the traffic it just saw rather than from a static guess.

The status code column of a rule can also be constrained, and it takes a range or a list, written as 200-299,500-599,302, with commas separating multiple ranges or individual codes. So a rule can require a 500 to count as a finding, or accept a specific redirect code.

The result of a hit is displayed in VulDisplay, where right clicking lets you delete the selected rows or all of them.

## The controls that decide what gets sent

Several UI controls govern the extension's behaviour, and each of them is a place where an unwanted request can come from.

The Start button is the main switch and is off by default. The Head button controls whether the original request headers are carried with the probe, and it is on by default, which is what makes the probe look like a legitimate request from the same session.

Filter_Host is a multi-line text box for a host whitelist, one host per line, with a wildcard where a star represents everything, in the form of a domain pattern like *.baidu.com. Any host not on the list is skipped. This is the control that matters most in practice, because without it the extension will probe every host that happens to pass through the proxy, including internal services and third party endpoints you were only visiting as a client.

The active scan option, offered by right clicking a request, is different in kind. The plugin takes the current request and scans all the historical paths in the site map that use the same host. It is a burst of requests against one host, and the README describes it as the way to cover a site you have already explored.

Loading the extension is a manual step in Burp, through Extender, then Extensions, then Add, then Select File, then Next, which means you point it at the built jar.

## The alternative: a wordlist scanner, and how the trade differs

The closest alternative to this extension is a path enumeration tool driven by a dictionary, and the difference in approach is about where the candidate paths come from.

A wordlist scanner takes a list of common paths and requests them against a host. It knows nothing about the application, it works equally well against a site you have never visited, and it is fast to configure. What it produces is a list of paths that exist, and its accuracy depends entirely on the quality of the list.

RouteVulScan derives its candidates from the paths the application itself serves, and its findings from the content of the response rather than from the status of it. The trade is coverage against generality. The extension finds paths that are not common, in places a dictionary would not guess, but only along the shapes that the application already uses, and only where your rules say that the response is interesting.

The other difference is that the extension is embedded in the tester workflow rather than being a separate tool. Its passive mode only spends requests on traffic you generated, and its active mode reuses the site map you built up, so the knowledge of the site comes from the browsing rather than from a crawl.

If you are starting from nothing and want to find out what a host exposes, the wordlist approach remains the more direct tool. If you have already been through a site and want to sweep the corners, this extension is doing something a dictionary cannot.

## The state of the project, and the licence question

The plugin is a Java project built with Maven, with the source under src and a pom.xml at the root, alongside the configuration file and the images used in the README.

The release history shows a two-year gap followed by a large release. The versions are RouteVulScan 2.0 from 2026-07-10, 1.5.4 from 2024-06-14 and 1.5.3 from 2024-06-01, and the last push to the repository was on 2026-07-10, the same day as the 2.0 release. So the 2.0 rebuild is the current state of the code, and the previous public version is more than two years older.

What changed in 2.0 is described in the update plan at the end of the README, and every 2026-07-10 entry is part of the same rebuild. The project was refactored with AI assistance and moved to Maven with the dependencies updated, the default rules were built in and the configuration was migrated to the user directory, the user interface was made adaptive, and the host whitelist and the scan scheduling were made more stable. One entry simply says unnecessary features were removed.

The earlier entries show how the feature set grew, with dated check marks for the active scan option, the domain filter, the packet size column, the delete function in VulDisplay, the feature switches, carrying the original request headers, custom post and get requests, rule categories, per rule selection, status code ranges, the marker language, and sorting in the display panel.

The one thing to settle before you rely on the plugin is the licence. The repository licence is recorded as unknown, with no licence file in the root listing, and the project is distributed as a build that you load into Burp from your own machine. If you intend to modify it or use it inside a paid engagement, ask the author.

## Conclusion

Adopt RouteVulScan if you are testing a web application through Burp Suite and want the extension to sweep the path layers you have already visited and flag responses that match your own detection rules, because that is a workflow the extension automates rather than a capability it provides. Do not adopt it as a replacement for a rule set, since the default rules are a starting point and the quality of the result depends on the patterns you write, or as a replacement for authorisation, since it sends real requests to the host you point it at. Before you run it, set the Filter_Host whitelist, because the extension will otherwise probe every host that passes through your proxy.

## FAQ

### What is RouteVulScan?

It is a Java Burp Suite extension that recursively detects vulnerable paths. It uses a passive scan on the IScannerCheck interface, probes every layer of the paths it observes, matches the responses against configured regular expressions, and shows the hits in a VulDisplay panel.

### How do I install the RouteVulScan extension?

Build the project with Maven and load the jar in Burp Suite through Extender, then Extensions, then Add, then Select File, then Next. On first load the extension creates a Config_yaml.yaml in the user configuration directory, at ~/.config/RouteVulScan/Config_yaml.yaml on macOS and Linux, and initialises it with the built-in default rules.

### How do I restrict which hosts RouteVulScan probes?

Use the Filter_Host field, a multi-line box where each line is a whitelisted host and a star represents all of them, in the form of a pattern such as *.baidu.com. Hosts that are not on the list are skipped.

### Can RouteVulScan use values from the request in its rules?

Yes. The marker syntax includes request head values such as the cookie, the host main domain and the host name, along with the method, path, url, protocol and port, and response head values including the server header and the response status code. A status code column can also be constrained to a range or a list, for example 200-299,500-599,302.

## Sources

- [F6JO/RouteVulScan on GitHub](https://github.com/F6JO/RouteVulScan)
- [Issues](https://github.com/F6JO/RouteVulScan/issues)
- [README](https://github.com/F6JO/RouteVulScan/blob/main/README.md)
- [Releases](https://github.com/F6JO/RouteVulScan/releases)

---

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