CVEFlow: Why I Built a Public Graph for Modern CVEs

I have been using some version of this for myself for a while. The reason is simple: modern CVEs are rarely just "one bug, one box, one impact". Once you actually study the interesting ones, the story is usually spread across protocol behavior, unsafe parsing, process boundaries, privilege transitions, system internals, kernel-facing surfaces, command-and-control, lateral movement, and exfiltration.

That is exactly why I built CVEFlow.

It is my public space for graphing CVEs as attack chains instead of flattening them into a few paragraphs. I use it to map how a case really works end to end: where the attacker starts, which component is exposed, which execution path gets abused, what the post-exploitation reality looks like, and what defenders should watch for. I only publish occasionally, but when I tackle a case that is technically interesting enough, this is where I put it.

Why I wanted a graph, not just a writeup

For straightforward vulnerabilities, a short note is enough. For modern exploitation, it usually is not.

Take a public RCE case: the entry point might be an internet-facing endpoint, but the real value is in understanding the full chain after initial execution. Does it reach a shell? Does it pivot into persistence? Does it hit cloud metadata? Does it stage tooling? Does it pull a C2 tunnel? Does it open a path for lateral movement? Those details are often the difference between "patch it" and actually understanding the incident.

The same applies to memory corruption and low-level bugs. A disclosure might mention a leak, a parser flaw, or a privileged service, but what matters operationally is the flow: which packet or request shape triggers the bug, which component handles it, what memory or process boundary gets crossed, and what the attacker gains from there. I wanted a format that makes that visible immediately.

What is on the site

The public site already reflects that model. It is not just a title list. Each scenario is structured as an interactive graph with the supporting context around it:

• a searchable index of public scenarios
• step-by-step attack-chain views with entities, containers, and transitions
• defender-oriented fields such as prerequisites, attacker gains, detection notes, and command snippets
• MITRE ATT&CK references when they help frame the activity
• public examples covering web exploitation, memory disclosure, supply-chain compromise, and Windows service abuse

Current public examples include React2Shell, MongoBleed, PrintNightmare, Shai-Hulud 2.0, and the TeamPCP supply-chain campaign.

That range is important to me because it shows why a graph helps. Some cases are dominated by an application-layer exploit path. Others are about memory handling. Others are really about the operational aftermath: secret theft, C2, staged malware, poisoned dependencies, or movement into other systems. The format needs to handle all of that without collapsing the story.

Why I made it public

I originally built this because I needed it myself. When I analyze a CVE, I want something more concrete than a severity score and a loose description. I want a map I can revisit quickly and extend when a case becomes richer: adding the attacker prerequisites, the internal component path, the post-exploitation steps, and the detection angle in one place.

Making it public was the natural next step. It gives me a place to publish the CVEs I find worth documenting, and it gives other researchers and defenders a more visual way to understand complicated exploit chains. That is especially useful when the interesting part is not just the initial bug, but the surrounding system behavior: C2 traffic, lateral movement opportunities, protocol internals, service abuse, or the kernel and system-facing details that get lost in summary-style writeups.

If you want to browse the project directly, it is live at cveflow.com.