awesome-vrre-writeups is one README file, and its only admission rule is a rhetorical question

The admission rule is a question: no source, no disassembly, no PoC

The defining statement of the collection is a question rather than a checklist. It asks whether something is really a writeup if it does not have source, disassembly, or a proof of concept. Everything else on the page follows from that stance. The stated purpose of each entry is to break down in-depth not only the exploit but the exploitation steps, which is the distinction being drawn: a vulnerability announcement is not the same artifact as a walkthrough. The list is drawn from around the internet rather than from any single publisher, which is why advisory vendors, individual researchers, project blogs and conference material all sit in the same flat list with no separation between them. If you submit something, that question is the filter the submission will be read against.

The whole repository is one README file and nothing else

There is no software here and no build. The repository contains a single file, the readme, and that file is the entire deliverable. There is no generator, no tag validation, no link checker, no topic index, and no release history. The licensing situation is likewise not declared in the repository metadata, which matters for a different reason than usual here: the page is explicit that all credit for anything posted goes to the original posters. In other words the repository curates pointers rather than copies, so the licensing question that would apply to a mirror does not arise. The last recorded push to the default branch is dated 27 September 2026, which tells you the list is still being appended to even though nothing about it is automated.

Entries are grouped by year, and the promised type index does not exist yet

The structure on the page is a table of contents with one branch: a write-ups section, which then splits by year into 2024, 2025 and 2026 headings. That is the entire hierarchy, and the author says so directly, describing the intent to get a table of contents where the types are broken down in the future. What that means in practice is that finding an entry means scanning a flat list inside a year, and the only signal you have about a given article's subject is its title. For a collection whose stated motivation is that it is impossible to keep track of every vulnerability type, that is a real limitation rather than a stylistic quibble: the thing the page set out to solve is deferred, and year ordering is a proxy for it. Submissions are welcome by pull request, so the taxonomy can be built collaboratively.

Browser engines and JavaScript runtimes are the heaviest category

Within the 2024 entries, browser and JavaScript engine work recurs more than any other theme, and it spans both exploitation and reverse engineering. There is a writeup on exploiting the V8 engine at a security conference, a separate one on getting remote code execution in Chrome through incomplete object initialisation in the Maglev compiler, and a third on chaining messages in browser extensions to reach universal code execution. Around those sit a variant hunt on a Project Zero bug, a deep dive on reversing eBPF programs, and a piece on exploiting the flexibility of email addresses offensively. If your bug is in a browser, this list is at its densest, and the three browser entries are from three different authors on three different surfaces: the engine, the compiler, and the extension messaging layer.

Fuzzing appears as a method, not as a single topic

Fuzzing shows up repeatedly across unrelated subsystems, which is a fair signal about where the method is being applied. The most explicit entry fuzzes the NVMe over fabrics TCP driver for Linux with a kernel fuzzer, and the regex entry is framed as lessons learned from fuzzing regex libraries across two parts. Elsewhere the method is implied rather than named: a variant of a previously reported bug found by digging into a root cause, and a writeup on exploit development on Linux that starts from a deliberately trivial target. The allocator material, an advanced piece on Doug Lea's malloc exploits published in a classic computing magazine, sits alongside these as the manual counterpart to the fuzzed surface. Read together, these entries cover the range from automated kernel and library fuzzing to hand written heap exploitation.

Reverse engineering entries run from Lua bytecode up to individual CPU gates

The reverse engineering half of the collection spans several orders of magnitude of abstraction, and that range is one of the more useful things about it. At the software end there is a breakdown of Lua security flaws inside a game engine framed as bytecode analysis, a deep dive on reversing eBPF programs, and a writeup on reversing a pickle format with a dedicated decoder tool. In the middle sits work on the Windows registry as a research target, a journey into the internals of Microsoft Defender's signature handling, and an analysis of API obfuscation in a banking trojan through vectored exception handling. At the hardware end there is a piece on standard cells, looking at individual gates inside a Pentium processor. And one entry is purely physical: reverse engineering the rotating barcodes used for event tickets.

Build system and package manager entries carry the widest blast radius

Several entries concern code that arrives on developer machines before anyone reviews it, which is why they are worth singling out. One analyses the obfuscation in the bash stage of the xz compression library, a supply chain case that reached widely. Another covers vulnerabilities in the CocoaPods package manager opening the door to supply chain attacks against a large number of mobile and desktop applications. A third covers multiple vulnerabilities in a PyTorch model server component, with two severity scores quoted in the title itself. A bare repository link for a browser sandbox bypass tool also appears among them. If your concern is whether your build pulls something hostile, these entries are the reason the collection includes items with no CVE identifier at all.

Entries carry identifiers in the title, and the same publishers recur

Titles in the list are written as retrieval keys rather than as prose. Many include the identifier directly, so a search for a specific advisory finds the entry without needing the site name, and a few carry two, which is a hint that the writeup covers a family rather than a single bug. A handful include a severity score in the title, which makes it easy to sort mentally by urgency. The publishers also repeat: a large vendor research blog appears several times with different bug classes, a hardware vendor advisory blog appears for a driver fuzzing effort, a vulnerability coordination firm appears for both a SharePoint parsing bug and a backup software privilege escalation, and a project security team appears for browser compiler work. Recognising those names is faster than reading titles when you already know who you trust on a given class of bug.

Editorial conclusion

Use this repository as a starting index when you are looking for prior art on a bug class, not as a reference you can cite. It carries no tooling, no structure beyond year headings, and no promise that a listed article is still reachable or still accurate. Two things to check before you lean on it: whether the specific technique you need is present at all, since the promised breakdown by vulnerability type does not exist yet, and whether an article is a writeup or a bare link, because at least one entry is a code repository rather than prose. If you want a durable taxonomy of exploit technique, this list will not provide one and the author says as much.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases