DEV Community

Eldor Zufarov
Eldor Zufarov

Posted on

From LOW to CRITICAL: How a 5-Step Vulnerability Chain Goes Undetected by Flat Scanners

#security #appsec #vulnerabilities #devops

A real scan walkthrough using DVWA
By Eldor Zufarov, Founder of Auditor Core
Originally published on DataWizual Blog

The Setup

Most security scanners give you a list sorted by CVSS. A CRITICAL at the top, some HIGH findings below, and a long tail of LOW and MEDIUM that nobody ever fixes. Teams triage by severity, patch the top items, and move on.

This approach has a blind spot. It misses chains.

Here is a real example from a scan of DVWA (Damn Vulnerable Web Application) — a deliberately vulnerable PHP application used for security training. The scan was run with deterministic static analysis plus AI validation. What it found was not just a list of findings. It found a complete 5-step attack path.

What a Flat Scanner Sees

A standard SAST tool scanning DVWA would report something like this:

  • generic-api-key in csrf/help/help.php:54 — LOW
  • SAST_COMMAND_INJECTION in view_help.php:20 — HIGH
  • SAST_COMMAND_INJECTION in exec/source/high.php:26 — HIGH
  • SAST_COMMAND_INJECTION in cryptography/oracle_attack.php:57 — HIGH

A team looking at this list would prioritize the HIGH command injections. The LOW API key finding would go to the backlog. Nobody would notice the connection between them.

What Chain Analysis Sees

The ChainAnalyzer correlated these findings into a single attack path — CHAIN_0003, rule: secret_to_command_injection:

csrf/help/help.php:54 → hardcoded user-token: 026d0caed93471b507ed460ebddbd096
           ↓
view_help.php:20 → eval('?>' . file_get_contents("vulnerabilities/{$id}/help/help.php"))
           ↓
view_help.php:22 → eval('?>' . file_get_contents("vulnerabilities/{$id}/help/help.{$locale}.php"))
           ↓
exec/source/high.php:26 → shell_exec('ping ' . $target)
           ↓
cryptography/oracle_attack.php:57 → curl_exec($ch)   ← exfiltration endpoint
Enter fullscreen mode Exit fullscreen mode

This is not five separate findings. This is one complete attack path:

token capture → code execution → shell access → data exfiltration.

The LOW finding at step 1 is not low risk. It is the trigger for a CRITICAL chain. Every finding in the chain was escalated to CRITICAL — not because the individual severity changed, but because the path connecting them is exploitable end-to-end.

How the AI Validation Worked

The AI (Gemini 2.5 Flash) did not generate these findings. It validated chains already discovered by the deterministic layer.

For the curl_exec finding at step 5, the AI verdict was:

"The provided code is part of a vulnerability chain (CHAIN_0003) with a critical risk. The curl_exec function is used to execute a curl request, and the $url variable is not sanitized. The bridge logic is that the output of the first finding becomes the controlled input for subsequent steps."

This is chain-aware reasoning — the AI evaluated the finding in the context of the full path, not in isolation. The result: SUPPORTED verdict for every confirmed step in the chain.

The AI also correctly dismissed two false positives — obfuscated JavaScript files that triggered SAST rules but contained no actual command injection. Those findings were marked AI DISMISSED — MANUAL REVIEW ADVISED and excluded from the enforcement decision.

The Enforcement Decision

The scan produced a Security Posture Index (SPI) of 65.79 — grade C, status: REQUIRES REMEDIATION.

But the gate decision was not driven by the SPI. It was driven by the chain. When CRITICAL findings exist in production code, the gate overrides the mathematical score. The effective grade is capped at C regardless of the SPI value.

This resolves a common problem: a team sees SPI 87 and assumes the codebase is in good shape. But if that SPI sits alongside an undetected CRITICAL chain, the score is misleading. The gate override makes the enforcement decision honest.

Why This Matters in the Mythos Era

The CSA/SANS document on Mythos-ready security programs describes exactly this class of vulnerability:

"Mythos identifies vulnerabilities composed of multiple primitives chained together, such as scenarios requiring multiple memory corruption bugs combined into a single exploit path."

AI attackers see graphs. They chain findings into exploit paths automatically. Traditional defenders see lists.

The gap closes when the defensive layer builds the same graph — deterministically, before any AI touches the enforcement decision.

DVWA is a training application. But the chain pattern it demonstrates — credential exposure feeding into execution, feeding into exfiltration — appears in production codebases. The difference is that in production, the individual findings are spread across more files, more modules, more developers. That makes them harder to correlate manually. It makes graph analysis more valuable, not less.

Key Takeaways

  • A LOW finding at the start of a chain is not low risk. Its risk is determined by where the chain leads.
  • AI validation is most accurate when it evaluates the full chain context, not individual findings in isolation.
  • False positive filtering matters: the two AI DISMISSED findings in this scan would have created noise without chain-aware AI validation.
  • The enforcement gate should be driven by chain risk, not raw CVSS scores.

Auditor Core v2.2.1 — datawizual.github.io

Documentation on GitHUB — DataWizual Auditor Core technical overview

Top comments (0)