# XSS-LOADER: a menu driven XSS payload builder, scanner and dork finder

> XSS-LOADER is a small Python console program that bundles three jobs, generating XSS payloads with encodings, checking a URL with a payload list, and searching for injectable endpoints with dorks. It is a study tool for the classic cross site scripting payload families, not a web application scanner.

**capture0x/XSS-LOADER** — Xss Payload Generator ~ Xss Scanner ~ Xss Dork Finder

- Repository: https://github.com/capture0x/XSS-LOADER
- Stars: 624 · Forks: 121
- Language: Python
- License: CC0-1.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/capture0x-xss-loader

## Three separate jobs share one menu driven script

XSS-LOADER is described in its README as an all in one tool set for XSS payload generation, XSS scanning and XSS dork finding, written by TMRSWRR and marked as version 1.0.0. The three jobs are what the repository files suggest. payloader.py is the entry point you run, xssScan.py holds the URL testing logic, and dorktara.py holds the search based endpoint finder, with entry.py and promm.py supporting them. Alongside those scripts sit the payload corpora as plain text files, including basic.txt, div.txt, img.txt, body.txt, svg.txt, waf.txt, cloudflare.txt, polyglot.txt, alertt.txt and xss-payloads.txt, plus useragent.txt and proxy.txt for request shaping. The console presentation is a numbered menu rather than a set of command line flags, which is the single most important fact about the interface. Every action, from choosing a payload family to exiting, is picked from a list, so the tool has no flags to memorise and no output format to script against. That makes it friendly for learning and awkward for automation, and it is the right shape for the task it was written for.

## The payload builder works on tag families and encodings

The payload generator section offers several base templates that set a default payload parameter. There is a basic payload built on a script tag, a div payload using an onpointerover handler with a MOVE HERE prompt, an img payload using an onerror handler, a body payload using ontouchstart, and an svg payload using onload. Beyond the presets there is an option to enter your own payload, which the README says is encoded, and a separate parameter for the payload generator, which encodes the payload on the selected tag. The encoding menu is the substantial part of the tool, and the README lists thirty numbered entries covering upper case, mixed case, URL encoding, HTML entity encoding, split payloads, hex, UTF-16, UTF-32, delete tag, unicode, US-ASCII, base64, UTF-7, parenthesis bypass, UTF-8, tag block breakout, script breakout, file upload payloads, comment bypass, mutation payloads, malformed markup, space bypass, downlevel hidden blocks, WAF bypass lists, Cloudflare bypass lists, polyglot lists, alert payload lists, a create all payloads option, a return to main menu entry, and an exit entry. Several entries are not encodings at all but escapes from a restricted context, which is why the menu mixes them together.

## The scanner takes one URL and a list, then writes vulnpayload.txt

The XSS scanner section begins by asking for the URL of the target, with the README giving the expected shape as a URL with a query parameter, for example http://target.com/index.php?name=. You then pick the payload list to scan with. The built-in choices map directly onto the corpora in the repository, so the basic, div, img, body and svg payload lists each consist of the matching tag family, a mixed payload list consists of all tags, and an enter file path option takes a list you supply yourself, with the README suggesting a path such as /usr/share/wordlists/wfuzz/Injections/XSS.txt. Results are appended to a file named vulnpayload.txt after scanning. That output file is the interesting part for anyone assessing this tool honestly. There is no notion of a confirmed vulnerability, no reflection check, no status code analysis and no report structure in the description. What lands in the file is the set of payloads that were tried against a URL you gave it. The tool tells you what it sent, not what worked.

## The dork finder writes search patterns to dork.txt

The third component searches for injectable endpoints rather than testing a URL you already have. You enter a dork, and the README gives the shape of one with a search engine style query such as inurl:"search.php?q=". The results are saved to dork.txt after scanning. This is the feature that needs the clearest framing. A dork is a search query aimed at finding pages with parameters, and running one sends that query to a search engine and records what comes back, which means the tool points itself at third party sites rather than at a system you own. The dork.txt file is therefore a list of candidate URLs that somebody else is running, and the scanner in this same repository can then be pointed at them. The tools are modular by design, which is convenient for an authorised audit where you have a scope list, and it is exactly the combination that makes the tool easy to misuse. Whatever the intent, the safe reading of the workflow is that the dork results feed a scanner you have permission to run.

## Installation is a clone and a pinned pip install

The install path is short and uses a requirements file.

```bash
git clone https://github.com/capture0x/XSS-LOADER/
cd XSS-LOADER
pip3 install -r requirements.txt
```

Running it starts the interactive program.

```bash
python3 payloader.py
```

The dependency list is where the age of the project shows. requirements.txt pins beautifulsoup4 at 4.8.2, bs4 at 0.0.1, certifi at 2019.11.28, chardet at 3.0.4, idna at 2.9, lxml at 4.5.0, requests at 2.23.0, soupsieve at 2.0 and urllib3 at 1.25.8. Those are 2019 and 2020 era versions, and the whole point of that pin list was reproducibility at a time when the tool was current. On a modern Python interpreter, some of these are the kind of install that either fails outright or pulls in a build of lxml that no longer compiles against current headers. The README does acknowledge a rough edge, listing unicode errors and module errors under fixed issues, and it notes that Windows users who want the tool with Python 3 installed should download a separate build from a companion repository, which tells you the original was developed against a Linux environment. The last push to the repository was on 2026-05-02 and the repository has no GitHub releases, so there is no version history to pick from and no changelog beyond the README.

## What the tool cannot tell you, and where a real scanner starts

Set against a real web application scanner, XSS-LOADER gives up almost immediately. There is no crawling, so you must know every URL and parameter yourself. There is no context detection, so a payload built for an HTML body is sent to a parameter that expects JSON and the difference is invisible. There is no confirmation logic, so vulnpayload.txt lists attempts rather than findings. There is no rate control, no authentication support, no reporting, and no way to tell a blocked request from a request that was reflected harmlessly. The dork finder adds no precision, since a search engine result tells you a page exists with a parameter, not that the parameter is injectable. What the tool does give you is a fast way to produce the classic payload variants, including the encoding and breakout families that trip naive filters, and a way to try a specific list against one URL while you watch. For learning how filters fail and for spot checks, that is genuinely useful. For coverage, it is a starting point, and the honest comparison is that a maintained scanner with context awareness and confirmation will find more real issues in less time than this menu will.

## CC0 licensing, a 2020 copyright line and a repository still being touched

The repository is published under CC0-1.0, a public domain dedication, which is an unusual choice for software and removes essentially any question about reuse of the code and the payload lists. The README still carries a Copyright 2020 line, and the repository is not archived, with the last push on 2026-05-02, so somebody is still editing it even though the version string remains 1.0.0 and no GitHub release has ever been published. That combination, a dormant version number with occasional maintenance, is worth keeping in mind before you build a workflow on it. The .github directory exists for issue and template handling, and the README directs bug reports and enhancement requests to the issue tracker. For a tool of this size the maintenance question is mostly answered by the dependency situation rather than by the commit history, since the pinned libraries are the part that ages, and they have aged. A maintained fork with refreshed pins would be a small amount of work, which is another argument for treating this as a study tool and a reference list of payload families rather than as infrastructure.

## Conclusion

Adopt XSS-LOADER if you are studying cross site scripting payload families or need a quick manual check of a single URL that you are authorized to test, and skip it if you need continuous coverage of an application, since this is an interactive script rather than a scanner you point at a target list. Verify first that the pinned dependencies in requirements.txt still resolve on your Python version, that the payload list files are present in the checkout, and that the outputs vulnpayload.txt and dork.txt land where you expect before you point the dork finder at anything that is not yours.

## FAQ

### How do I install and run XSS-LOADER?

Clone the repository, run pip3 install -r requirements.txt inside it, and start the tool with python3 payloader.py. The program then presents a numbered menu rather than command line flags, and a separate companion repository provides a Windows build.

### What does the XSS scanner in XSS-LOADER actually report?

Results are added to a file named vulnpayload.txt after scanning. The README describes it as a list of payloads tried against the URL you entered, with no mention of confirmation logic or a findings report.

### What is the dork finder for in XSS-LOADER?

You enter a search style query, with inurl:"search.php?q=" given as the example, and the results are saved to dork.txt. It collects candidate URLs with parameters so they can be checked separately, which means the queries point at sites other than your own.

## Sources

- [capture0x/XSS-LOADER on GitHub](https://github.com/capture0x/XSS-LOADER)
- [Issues](https://github.com/capture0x/XSS-LOADER/issues)
- [License: CC0-1.0](https://github.com/capture0x/XSS-LOADER/blob/master/LICENSE)
- [README](https://github.com/capture0x/XSS-LOADER/blob/master/README.md)

---

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