PayloadsAllTheThings asks for payloads, not fixes, and its last release was July 2025

The version number and the year label in a release are two counters

The three most recent releases carry compound titles. Version 4.2 is titled 2025.1 PayloadsAllTheThings FERRETEDITOR and is dated 2025-07-26. Version 4.1 is 2024.2 with the codename BOOKSQUIRREL, dated 2024-12-04. Version 4.0 is 2024.1 with CHIPMUNKFEED, dated 2024-04-26.

So there are three things moving at once. The major number walks 4.0, 4.1, 4.2. The second number walks 1, 2, 1, which means it is a sequence scoped to a year and resets when the year changes, since 4.1 shipped in December 2024 and 4.2 shipped in July 2025 yet carries the lower label. And a codename travels with each one.

The consequence for anyone pinning is the gap. The last release is 4.2 from 2025-07-26, and the last push to the repository is dated 2026-08-27. That is over a year of commits with no tag behind them. A fork pinned to the newest release holds a snapshot from the middle of 2025, and the default branch it will merge from is more than a year of drift away. Read from the branch, and treat the release number as a label rather than as a version you can depend on.

Every chapter is four things, and a template folder enforces the shape

The documentation section states the convention directly. Every section contains the following files, and the _template_vuln folder is there to create a new chapter from. A README.md holds the vulnerability description and how to exploit it, including several payloads. An Intruder folder holds a set of files to give to Burp Intruder. An Images folder holds pictures for the README.md. A Files folder holds some files referenced in the README.md.

That is a stronger constraint than a wiki page, and it is what makes the repository useful as a corpus rather than a blog. The Intruder folder is the machine-readable half. The payloads are not only written in prose, they are also shipped as files that a testing tool can consume, so a chapter is a description plus a loadable input.

The safety consideration sits inside that structure rather than beside it. These are strings whose purpose is to be sent at a system, and a chapter tells you how to exploit the class it covers. The repository ships a DISCLAIMER.md and a Methodology and Resources/ directory, which is the project stating the authorised-testing frame, but the four-file convention does not require a chapter to point at either of them. If you are cloning this to read, or to feed a scanner, you are picking up that framing by reading the front page first.

The folder name is the only index, and it mixes classes with tools

The top level is roughly fifty folders, and there is no table of contents beyond the front page's own link to a hosted display version. Discovery is browsing, or reading the repository tree.

The taxonomy is not a strict classification, which is the useful thing to notice. Alongside the canonical names, SQL Injection/, Command Injection/, Prototype Pollution/, Cross-Site Request Forgery/, NoSQL Injection/, and the rest, there are folders that are vulnerability classes in a looser sense: Business Logic Errors/, External Variable Modification/, Hidden Parameters/, Insecure Randomness/, Insecure Management Interface/, and Denial of Service/. There are also entries that name a technology or a technique rather than a weakness, Google Web Toolkit/, Headless Browser/, and Encoding Transformations/.

Consequence for a reader: the list is browsable and it is complete-looking, but you cannot infer from a folder name whether the chapter describes a class, a review checklist, or a tool's usage. If you are building a checklist from this, treat the irregular names as items to read rather than as equal entries in a taxonomy, and note that Prompt Injection/ sits in the same list as the injection families it belongs with by name rather than by mechanism.

The repository's primary language is recorded as Python even though the content is Markdown, which points at the tooling that generates the hosted site rather than at the corpus.

The contribution request is for payloads, and only for payloads

The front page is two sentences of invitation. A list of useful payloads and bypasses for Web Application Security, and feel free to improve with your payloads and techniques. There is also a line offering to contribute in person or through the sponsor button.

Read closely, the ask is one-directional. The project collects payloads and techniques. It does not ask for mitigations, detection signatures, log patterns, hardening notes, or false-positive guidance for the payloads it already lists. A chapter's README is described as a vulnerability description and how to exploit it, with no stated place for how to block it.

The consequence is a corpus that grows on one side. For a defender that is a real asymmetry: the repository is an excellent index of what to test for and very quiet on how to detect or prevent any of it. If your task is to write detections, each chapter gives you the strings to detect and leaves the rest to you.

Two adjacent folders partly fill the gap, Methodology and Resources/, which is the one non-vulnerability folder at the top level, and the books and YouTube selections linked from the front page. Both are pointers rather than content, and neither is referenced from the four-file chapter convention.

A pre-commit config runs before a human reads your chapter

Among the configuration files at the top level, next to .gitignore and .github/, there is a .pre-commit-config.yaml. There is no test suite in the listing and no build step, which is what you would expect from a repository whose contents are Markdown, images, and text payload files.

What that means in practice is that a contribution gets checked mechanically before anyone reads it. For a repository of this shape the checks that matter are the boring ones, trailing whitespace, line endings, and file hygiene, and .gitattributes sits at the top level to govern the last of those across a tree full of files with deliberately awkward names and contents.

The consequence is small but worth knowing if you are contributing. A payload file that contains trailing whitespace or unusual line endings, which is not impossible when the payload is a template or a header, can be rejected by a hook before a maintainer sees the content. Run the project's pre-commit configuration before opening the pull request rather than discovering the rule in review.

Contributors are pointed at CONTRIBUTING.md, and the repository also ships the sponsor button, the contributor graph, and a thank-you line, so the social machinery around contributions is well developed even though the tooling is one config file.

Three commercial security vendors sponsor the list

The sponsor section names SerpApi, described as a real time API to access Google search results that solves the issues of having to rent proxies, solving captchas, and JSON parsing. It names ProjectDiscovery, described as detecting real, exploitable vulnerabilities using Nuclei for fast and accurate findings without false positives. And it names VAADATA, described as Ethical Hacking Services.

So the commercial context is a search-results API vendor, a vulnerability-scanning vendor, and an offensive services firm. None of that appears anywhere else on the front page, and none of it is discussed.

For most readers this is unremarkable, and there is nothing in the repository suggesting the sponsorship affects which chapters exist or what they say. It becomes relevant in specific situations. In an organisation that reviews links before they circulate, or when a vendor-neutral reference is being cited in a document, knowing who pays is part of knowing the source. And a sponsored list is a different kind of artefact from a standards body's catalogue, so it is worth reading as one practitioner's accumulated corpus rather than as an authority's position.

The projects themselves are presented with no such claim. The front page says the project is proudly sponsored by these companies and nothing more.

Two sibling wikis cover the ground this repository does not

The name promises everything, and the front page is honest that it is not. It points to two other projects from the AllTheThings family. InternalAllTheThings covers Active Directory and Internal Pentest Cheatsheets. HardwareAllTheThings is a hardware and IoT pentesting wiki.

So this repository is scoped to web application security, and the two siblings are scoped to internal networks and to physical devices. A reader whose assessment moves from a web finding to an Active Directory question, or from a web application to an IoT device, has to leave this project. Nothing here bridges the two, and the split is by attack surface rather than by technique.

The family also points at a books selection and a YouTube channel selection, both under a directory in the repository, which extends the same idea into learning material rather than reference material.

The other thing worth knowing before you clone is that there is a hosted display version of the same content, at the homepage, which the front page describes as an alternative display version. Read in a browser, the hosted version is the faster way to browse fifty folders. Clone the repository when you want the Intruder payload files locally, since those are what a testing tool consumes, and they are the part the display version cannot hand you.

Editorial conclusion

PayloadsAllTheThings suits a security engineer or a CTF player who wants a maintained index of vulnerability classes and a set of payload files they can point a testing tool at, and it is a genuine service to defenders who need to know what an attacker will try. It does not suit a reader looking for remediation, detection, or hardening guidance, because the contribution model only collects the offensive side, and it is not something to run against a system you are not authorised to test. Before using it, confirm you have written authorisation for the target, treat the Intruder folders as tool input rather than documentation, and pin to a commit rather than a release, since the last tag is more than a year behind the branch.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes