DEV Community: Arturo Enrique Mata Garcia

Beyond Header Grabbing: Detecting Apache mod_http2 (CVE-2026-119618) with Custom Nmap NSE

Arturo Enrique Mata Garcia — Sat, 14 Nov 2026 19:23:34 +0000

When the critical Apache mod_http2 vulnerability (CVE-2026-119618) surfaced — a memory corruption in assign_headers() leading to potential RCE with a CVSS of 9.8 — the first reflex of most teams was to grep banners for "Apache/2.4.x" and call it a day. That approach has two fatal flaws: it fires on every Apache 2.4 build regardless of whether HTTP/2 is even enabled, and it collapses into silence the moment the target sets ServerTokens Prod.

I built apache-mod-http2-scanner.nse to solve exactly that: a non-intrusive Nmap Scripting Engine module that identifies Apache HTTP Server instances potentially affected by CVE-2026-119618, by combining version detection with actual HTTP/2 capability probing — h2 over TLS and h2c over plaintext — instead of trusting a header.

⚠️ Honesty first: the version ranges and detection criteria come from an internal bulletin (published 2026-11-11). The CVE could not be independently verified at the time of writing. Always confirm against Apache's official advisory (https://httpd.apache.org/security/vulnerabilities_24.html) before acting on results in production. The script itself is safe — it sends no exploit payloads.

🛑 The 3 Technical Challenges We Had to Solve

1. The Dual-Protocol Problem (h2 vs h2c)

The vulnerability only matters if HTTP/2 is actually active on the target. But HTTP/2 can be enabled in two fundamentally different ways, and each requires a different probe:

h2 over TLS — negotiated via ALPN during the TLS handshake. The only correct way to detect it is to send a ClientHello advertising h2 and inspect the ServerHello. A plain HTTP request tells you nothing, because the negotiation already happened at the TLS layer.
h2c over plaintext — negotiated via an HTTP/1.1 Upgrade: h2c request, which expects a 101 Switching Protocols response.

A scanner that only does one of these gives false negatives by design. The script inspects the port's known state first: if Nmap knows the port is TLS, it uses ALPN; if it's plaintext, it uses h2c; if it doesn't know, it tries h2c and, if inconclusive, falls back to ALPN.

2. The "Silent" Server (`ServerTokens Prod`)

The moment an admin sets ServerTokens Prod, the Server header becomes Apache with no version. Header grabbing returns nothing useful. But here's the nuance that most scanners miss: HTTP/2 being active is still a meaningful signal even when the version is hidden.

The script handles this by not lying to you. If it detects Apache + HTTP/2 active + hidden version, it returns LIKELY VULNERABLE — not VULNERABLE (we don't know the version) and not NOT VULNERABLE (we know HTTP/2 is on, and most deployed 2.4.x builds fall in the affected window). If you prefer the stricter stance, set hidden_version=unknown and it will report NO CONCLUYENTE instead.

3. The Binary Verdict Trap

Most NSE vuln scripts output one of two states: VULNERABLE or nothing. That's dangerous for a CVE whose affected range is a specific version window and depends on a runtime feature flag. "Not vulnerable" and "couldn't tell" are not the same thing, especially when NOT VULNERABLE will be silently skipped in a report.

The script distinguishes four states:

State	Meaning
`VULNERABLE`	Version in range and HTTP/2 active
`LIKELY VULNERABLE`	Apache + HTTP/2 active, version hidden
`NO CONCLUYENTE`	Couldn't complete a probe (TLS 1.3-only, timeout, filtered, `hidden_version=unknown`)
`NOT VULNERABLE`	Version out of range, or HTTP/2 not detected conclusively

NO CONCLUYENTE is deliberately shown apart from the VULNERABLE: block, so it can't be mistaken for a positive. It tells you to retry with -sV, bump the timeout, or verify locally — instead of silently dropping the host from your report.

🔍 How the Detection Engine Works

The script runs a short cascade — no exploits, no fuzzing:

Identify the server via nmap -sV or the Server header. If it's not Apache httpd (Tomcat, nginx, Traffic Server), it exits without further probes.
Probe HTTP/2 with the appropriate mechanism for the port (ALPN or h2c Upgrade).
Compare the version against the affected range and emit the verdict.

Two practical notes:

-sV is strongly recommended. Without it, the script relies solely on the Server header, and non-standard TLS ports (9443, 10443…) may fall back to h2c and miss an h2-only server. You can force the probe with apache-mod-http2-scanner.ssl=true.
The ALPN probe uses TLS 1.2. A server that only accepts TLS 1.3 will produce NO CONCLUYENTE — by design, not as a crash.

💻 The Result in Terminal (Two Real Scenarios)

Scenario 1: Fully Exposed Environment (h2 over TLS)

In this scenario the port is recognized as TLS, ALPN negotiates h2, and the version is visible via -sV. The script confirms both the affected version and the active HTTP/2 capability — a true positive.

PORT     STATE SERVICE  VERSION
8443/tcp open  ssl/http Apache httpd 2.4.70 ((Unix) OpenSSL/3.5.7)
| apache-mod-http2-scanner:
|   VULNERABLE:
|   Apache HTTP Server mod_http2 - corrupcion de memoria / RCE (severidad Critica)
|     State: VULNERABLE
|     IDs:  CVE:CVE-2026-119618
|     Risk factor: High  CVSSv3: 9.8
|     Check results:
|       Banner/Version: Apache/2.4.70 (nmap -sV)
|       HTTP/2 habilitado: SI - h2 (ALPN)
|       Rango afectado: 2.4.55 - 2.4.70 (corregido en 2.4.71)
|_      Script: apache-mod-http2-scanner v1.0.1

Risk factor: High is a limitation of Nmap's vulns library, which only accepts High/Medium/Low. The real severity (Critical, CVSS 9.8) is shown in the title and the CVSSv3 field.

Scenario 2: Hidden Version (`ServerTokens Prod`)

Here the Server header leaks only Apache. The script still detects Apache and still confirms HTTP/2 is active, but because the version is unknown, it reports LIKELY VULNERABLE — and tells you exactly what to do next.

| apache-mod-http2-scanner:
|   VULNERABLE:
|   Apache HTTP Server mod_http2 - corrupcion de memoria / RCE (severidad Critica)
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2026-119618
|     Risk factor: High  CVSSv3: 9.8
|     Check results:
|       Banner/Version: Apache (nmap -sV)
|       HTTP/2 habilitado: SI - h2c (Upgrade)
|       Rango afectado: 2.4.55 - 2.4.70 (corregido en 2.4.71)
|_      Version oculta: verifique localmente (httpd -v).

If you want this to read as NO CONCLUYENTE instead — for a change-ticket process that won't accept "likely" — add --script-args apache-mod-http2-scanner.hidden_version=unknown.

🧪 Field-Tested on Debian 13 (trixie)

Documentation and screenshots are one thing; reproducibility is another. The script was validated end-to-end on a clean Debian 13 (trixie) VM with Nmap 7.95+dfsg-3 (from Debian repos), using the official httpd:2.4.70 Docker image — a real build inside the affected range. Three containers were spun up with different Protocols configurations:

Container	Port	Configuration	Expected
`h2c-lab`	8081	`Protocols h2c http/1.1`	`VULNERABLE` (h2c)
`h2-lab`	8443	TLS + `Protocols h2 http/1.1`	`VULNERABLE` (h2/ALPN)
`h1-lab`	8082	default `http/1.1` only	`NOT VULNERABLE`

The baseline: default `httpd:2.4.70` is not vulnerable

Before touching anything, the first scan against a stock httpd:2.4.70 container (no Protocols override, no SSL) is instructive. The script does not panic, does not crash, and does not guess. It correctly reports UNKNOWN (unable to test) with an explicit reason:

| apache-mod-http2-scanner:
|   VULNERABLE:
|   Apache HTTP Server mod_http2 - corrupcion de memoria / RCE (severidad Critica)
|     State: UNKNOWN (unable to test)
|     IDs:  CVE:CVE-2026-119618
|     Check results:
|       Banner/Version: no disponible
|       HTTP/2 habilitado: NO detectado
|       Rango afectado: 2.4.55 - 2.4.70 (corregido en 2.4.71)
|       Script: apache-mod-http2-scanner v1.0.1
|       No se pudo determinar la version de Apache.

This is the correct behavior for a container that doesn't expose its version and doesn't enable HTTP/2: it isn't a false negative, it's an honest "I can't tell". That's exactly the distinction between NOT VULNERABLE and NO CONCLUYENTE the script was designed around.

The full three-container sweep

After enabling h2c on 8081, h2 + TLS on 8443, and leaving 8082 at HTTP/1.1-only, a single Nmap invocation against all three ports returns the three expected states side-by-side. -sV is enabled so version detection feeds the script directly:

nmap -Pn -sV -p 8081,8082,8443 --script apache-mod-http2-scanner localhost

PORT     STATE SERVICE  VERSION
8081/tcp open  http     Apache httpd 2.4.70 ((Unix))
| apache-mod-http2-scanner:
|   VULNERABLE:
|     State: VULNERABLE
|     Check results:
|       Banner/Version: Apache/2.4.70 (nmap -sV)
|       HTTP/2 habilitado: SI - h2c (Upgrade)
|       Rango afectado: 2.4.55 - 2.4.70 (corregido en 2.4.71)
|_      Script: apache-mod-http2-scanner v1.0.1

8082/tcp open  http     Apache httpd 2.4.70 ((Unix))
| apache-mod-http2-scanner:
|   NOT VULNERABLE:
|     State: NOT VULNERABLE
|     IDs:  CVE:CVE-2026-119618

8443/tcp open  ssl/http Apache httpd 2.4.70 ((Unix) OpenSSL/3.5.7)
| apache-mod-http2-scanner:
|   VULNERABLE:
|     State: VULNERABLE
|     Check results:
|       Banner/Version: Apache/2.4.70 (nmap -sV)
|       HTTP/2 habilitado: SI - h2 (ALPN)
|       Rango afectado: 2.4.55 - 2.4.70 (corregido en 2.4.71)
|_      Script: apache-mod-http2-scanner v1.0.1

Three different ports, same binary version, three different verdicts — all correct. That is the core value of not stopping at the banner.

What the script is doing internally (`nmap -d`)

The -d flag on the same scan reveals exactly why 8443 is flagged and 8082 is not. The debug trace walks through the cascade in order:

NSE: Starting apache-mod-http2-scanner against localhost (127.0.0.1:8443).
NSE: [apache-mod-http2-scanner 127.0.0.1:8443] identify: producto de -sV = Apache/2.4.70 (nmap -sV)
NSE: [apache-mod-http2-scanner 127.0.0.1:8443] modo de sondeo: tls
NSE: [apache-mod-http2-scanner 127.0.0.1:8443] ALPN: protocolo elegido = h2
NSE: Finished apache-mod-http2-scanner against localhost (127.0.0.1:8443).

Three lines that tell the whole story:

identify: producto de -sV = Apache/2.4.70 — version detection from -sV is the first source of truth; the Server header is only a fallback.
modo de sondeo: tls — the script recognized the port as TLS and chose ALPN, not h2c. That's the "port-state-aware" branch from Challenge #1.
ALPN: protocolo elegido = h2 — the ServerHello genuinely negotiated h2. Not "Apache is present", not "HTTP/2 is suggested by a header", but "the TLS layer confirmed h2".

Independent confirmation with a plain curl (the same probe the script performs, but from a different tool) agrees:

curl -skI --http2 https://localhost:8443/ | head -1
# HTTP/2 200

curl -sI --http2-prior-knowledge http://localhost:8081/ | head -1
# HTTP/2 200

The script's verdict is not based on a heuristic — it's based on the same wire-level signal curl uses, parsed via Nmap's own tls.record_read.

Why the "NOT VULNERABLE" case matters as much as the vulnerable one

The 8082 result (NOT VULNERABLE) is the most commonly overlooked piece of evidence. The container runs the same httpd:2.4.70 binary as the other two. If the script were a naive version-range checker, it would have flagged 8082 as vulnerable along with the rest — a false positive that would waste remediation cycles on a box with HTTP/2 disabled.

It didn't, because HTTP/2 was conclusively not detected. That's the point of separating "version in range" from "feature active": both must be true for a positive, and the script enforces it.

🚀 Try it in your lab

The script is free, open-source, Apache-2.0 licensed, and auditable. The Debian 13 lab above is reproducible with a single shell script. The relevant container invocations:

# h2c (plaintext) — vulnerable path
docker run -d --name h2c-lab -p 8081:80 httpd:2.4.70 sh -c \
  "sed -i 's/^#LoadModule http2_module/LoadModule http2_module/' conf/httpd.conf \
   && echo 'Protocols h2c http/1.1' >> conf/httpd.conf && httpd-foreground"

# h2 over TLS — vulnerable path
docker run -d --name h2-lab -p 8443:443 httpd:2.4.70 sh -c "
  sed -i -e 's/^#LoadModule http2_module/LoadModule http2_module/' \
         -e 's/^#LoadModule ssl_module/LoadModule ssl_module/' \
         -e 's/^#LoadModule socache_shmcb_module/LoadModule socache_shmcb_module/' conf/httpd.conf &&
  openssl req -x509 -newkey rsa:2048 -nodes -keyout conf/server.key -out conf/server.crt -days 2 -subj /CN=localhost &&
  printf 'Listen 443\nSSLSessionCache shmcb:logs/ssl_scache(512000)\n<VirtualHost *:443>\nSSLEngine on\nSSLCertificateFile conf/server.crt\nSSLCertificateKeyFile conf/server.key\nProtocols h2 http/1.1\n</VirtualHost>\n' >> conf/httpd.conf &&
  httpd-foreground"

# HTTP/1.1-only baseline — not vulnerable path
docker run -d --name h1-lab -p 8082:80 httpd:2.4.70

# Scan all three
nmap -Pn -sV -p 8081,8082,8443 --script apache-mod-http2-scanner localhost

The tests/lab.sh in the repository wraps the whole up / scan / down cycle. To see NOT VULNERABLE results too (which are silent by default), add --script-args vulns.showall.

A note on scope: the script is non-intrusive, but scanning systems you don't own or have written authorization for is still illegal in most jurisdictions. Treat the USO RESPONSABLE section of the README as the contract, not as boilerplate.

🔗 Repository & Documentation: https://github.com/matarturo/apache-mod-http2-scanner

💬 Let's Discuss: What Does "Not Vulnerable" Actually Mean?

To my fellow AppSec engineers and vulnerability-management folks here on dev.to:

When your scanner returns NOT VULNERABLE, how often is it actually "we couldn't tell"? The NO CONCLUYENTE state in this script exists because I kept seeing hosts silently dropped from reports simply because a probe timed out or a server only spoke TLS 1.3. I'd love to hear how your teams handle the unknown-vs-negative distinction — do you quarantine them, re-scan them, or let them slip?

Also: if you're running Apache 2.4.55–2.4.70 with HTTP/2 enabled, the mitigation is simple — either upgrade to 2.4.71+, or strip h2 and h2c from the Protocols directive and run apachectl configtest && apachectl graceful. Either way, please re-scan afterward to confirm the change.

🔗 Useful Links & Documentation

The script, the Docker lab, and the full argument reference live in the dedicated repository:

GitHub Repository: https://github.com/matarturo/apache-mod-http2-scanner
Direct script download (.nse): https://github.com/matarturo/apache-mod-http2-scanner/blob/main/apache-mod-http2-scanner.nse

📦 Installation (Linux, macOS, Windows)

The installation is the standard Nmap NSE flow — copy the script into the scripts directory, rebuild the database, and verify it is recognised:

sudo cp apache-mod-http2-scanner.nse /usr/share/nmap/scripts/
sudo nmap --script-updatedb
nmap --script-help apache-mod-http2-scanner   # verify

The --script-updatedb step is mandatory: Nmap will not resolve the script by name until the script database is rebuilt. If you prefer to run it without installing, point Nmap at the file directly:

nmap -Pn --script apache-mod-http2-scanner.nse -p 443 <target>

Platform-specific paths (macOS Homebrew, Windows) and the full --script-args reference (path, min, max, timeout, ssl, hidden_version) are documented in the README.

⚠️ `noexec` mount workaround

On systems where the Nmap scripts directory or the download location is mounted with noexec (common on hardened /usr/share, containers, and CI runners), copying the file is enough — Nmap loads .nse files as Lua sources, it does not execute them as binaries. No chmod +x and no interpreter workaround are needed for the script itself. If you download the .nse to a noexec location first, simply cp it to /usr/share/nmap/scripts/ as shown above.

📚 What's in the repository

apache-mod-http2-scanner.nse — the non-intrusive detector for CVE-2026-119618 described in this article.
README — decision table, argument reference, honest limitations (backports, ServerTokens Prod, TLS 1.3-only servers, CDN fronting), and the mitigation steps.
Issue tracker — if you hit a false positive or an unexpected NO CONCLUYENTE or INCONCLUSIVE, attach the nmap -d trace; it is the fastest way to get it triaged.

🛡️ A final word on scope

The script is non-intrusive: it does not exploit CVE-2026-119618, does not send crafted payloads, and does not attempt to trigger the memory corruption. But non-intrusive is not the same as authorized. Scanning systems you do not own or do not have written permission to test is illegal in most jurisdictions, regardless of how gentle the probes are. Run it against your own infrastructure, your lab, or a client engagement with a signed scope. The USO RESPONSABLE or RESPONSIBLE USE section of the README is the contract, not boilerplate.

If you deploy it internally, I would love to hear what your vulnerability-management workflow does with the INCONCLUSIVE bucket — that is the open question the script was built to surface, and the answer probably differs across every org reading this. 👇

Beyond Header Grabbing: Detecting PHP2Shell Behind WAFs with Custom Nmap NSE

Arturo Enrique Mata Garcia — Fri, 30 Oct 2026 11:06:17 +0000

When the critical PHP2Shell vulnerabilities (CVE-2026-109618 / CVE-2026-109619) dropped, the security community scrambled for detection tools. However, standard scanners have a fatal flaw: they fail against modern WAFs. If a server sits behind Cloudflare or Akamai, standard header grabbing returns nothing.

To solve this, I developed http-vuln-php2shell.nse, an open-source Nmap Scripting Engine (NSE) module.

The response has been incredible—over 217 clones on GitHub in the first few days. But getting here wasn't just about writing Lua; it was about solving specific architectural challenges to make the script reliable, cross-platform, and WAF-resistant.

Here is a deep dive into the technical hurdles we solved and how the script works under the hood.

🛑 The 3 Technical Challenges We Had to Solve

The "Silent" WAF (Cloudflare/Akamai)

If an infrastructure sits behind a CDN, the HTTP X-Powered-By and Server headers are usually stripped or replaced. A passive scan returns nil.
The Solution: I implemented a multi-layered inspection. If the headers lie, the script relies on passive fingerprinting via the PHPSESSID cookie (Technique C). Even if Cloudflare hides the server version, it often fails to strip the session cookie, revealing the underlying PHP backend.

False Positives on Patched Servers

Just detecting "PHP" isn't enough; you need to know if it's vulnerable.
The Solution: We implemented a strict syntactic evaluation of the PHP version. The script compares the detected version against the patched thresholds for October 2026 (PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12). If the server runs PHP 8.5.12, the script returns INFO (not vulnerable). If it runs PHP 7.4, it flags it as LIKELY VULNERABLE.

The Nmap vulns Library Bug on Windows

This was the hardest part. Nmap has a native vulns library to format vulnerability outputs beautifully. However, on Windows (Nmap 7.98+), the vulns.Report:new() object has a nasty habit of crashing the entire script (ERROR: Script execution failed).
The Solution: I discarded the buggy vulns library and built a custom native reporting engine. By using Lua's table.insert, the script perfectly mimics Nmap's official VULNERABLE: output block without any dependencies, ensuring 100% cross-platform stability.

🔍 The 5 Inspection Vectors

The engine doesn't just do a single request; it runs a cascading behavioral inspection designed for black-box environments:

· A & B (Headers): Parses X-Powered-By and Server for quick wins.
· C (Stateful Fingerprinting): Looks for PHPSESSID cookies in the root response.
· D (Forced Exceptions): Injects malformed parameters (/index.php?[]=) to force the server to reveal Stack Traces (if display_errors is on).
· E (Differential Verification): Compares a baseline request against a malformed input. If the malformed input triggers a 500 error or PHP trace not present in the baseline, it flags anomalous backend behavior.

💻 The Result in Terminal (Two Real Scenarios)

To truly understand the power of this script, let's look at how it adapts to different server configurations. The output isn't always the same; it depends on what the server exposes and what the WAF hides.

Scenario 1: Fully Exposed Environment (Modern Unpatched PHP)

In this scenario, the server is completely exposed. It doesn't hide the Server header, and it leaks the X-Powered-By header. The script easily triggers Techniques A and B. Notice that it catches a modern PHP 8.x version that missed the October 2026 patch.

| http-vuln-php2shell:
|   VULNERABLE:
|   Title: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) Potential Exposure
|   IDs: CVE:2026-109618, CVE:2026-109619
|   State: LIKELY VULNERABLE
|   ALERTA (A): PHP2Shell potencial via X-Powered-By -> PHP/8.4.25
|_  ALERTA (B): PHP2Shell potencial via cabecera Server -> PHP/8.4.25

Scenario 2: WAF / Proxied Environment (Header Obfuscation)

Now, look at what happens when a proxy or WAF (like Cloudflare) is trying to hide the server version. The Server header is stripped, so Technique B fails. However, the script is resilient: it still catches the X-Powered-By header (Technique A) and, more importantly, uses passive fingerprinting (Technique C) to detect the PHPSESSID cookie, confirming the PHP backend even when the WAF tries to hide it.

| http-vuln-php2shell:
|   VULNERABLE:
|   Title: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) Potential Exposure
|   IDs: CVE:2026-109618, CVE:2026-109619
|   State: LIKELY VULNERABLE
|   ALERTA (A): PHP2Shell potencial via X-Powered-By -> PHP/5.6.40
|_  AVISO (C): Backend PHP detectado por cookie PHPSESSID (cabeceras de version pueden estar ocultas).

🚀 Try it in your lab

The tool is completely free, open-source, and auditable. You can clone it, spin up a vulnerable Docker container, and test it in seconds:

git clone https://github.com/matarturo/php2shell-nse-scanner.git
nmap -p 8080 -Pn -n --script http-vuln-php2shell --script-args http.useragent="Mozilla/5.0" 127.0.0.1

🔗 Repository & Documentation: https://github.com/matarturo/php2shell-nse-scanner

💬 Let's Discuss: WAF Evasion Tactics

To my fellow AppSec engineers and Red Teamers here on dev.to:

How often do you find servers that configure a reverse proxy (like NGINX or Cloudflare) to hide the Server header, but forget to filter the PHPSESSID or X-Powered-By headers?

I'd love to hear your experiences in the comments below. 👇

I want to thank the security community, including creators like Federico Miskinich from @hablemosdehackin in Instragram, who have independently tested this script and provided valuable feedback that helped refine its edge cases.

Lynx: a passive security auditor for Linux

Arturo Enrique Mata Garcia — Thu, 01 Oct 2026 19:44:25 +0000

Some servers I look after run firewalls generated years ago by Firewall Builder (fwbuilder), on distros where iptables quietly became a front end for nftables. When I need a quick answer to "is this box reasonably configured?", I don't want to install a framework, and I definitely don't want a tool that changes things while it looks.

So I wrote Lynx: a single Bash script that audits a Debian or Ubuntu host in read-only mode, prints a scored report, and saves hash-verified evidence for whoever has to review it.

Lynx is not a compliance tool, and I'll be clear about that below. It's a fast, readable first pass.

TL;DR

Lynx audits a Debian or Ubuntu host in read-only mode: 29 scored controls, a 0-100 score, and SHA-256 hashed evidence.
It understands iptables-legacy, iptables-nft, nftables and fwbuilder-generated rules.
On a real Debian 13 dev server it scored 47/100. An earlier build had scored 56, and the difference was a bug that let Docker's rules pass for a host firewall.
It is a fast first pass, not a compliance scanner.

What Lynx is
One Bash script, no dependencies beyond what Debian/Ubuntu already ship (awk, grep, sed, find, stat).
Needs root, because it reads /etc/shadow, firewall rulesets and kernel settings.
Passive: it never edits configuration, installs, or removes packages. It doesn't even run apt update, because that would be an active action.
Apache-2.0 licensed.

What it checks

Six sections add up to a 100-point score across 29 controls. A seventh section is informational and doesn't score.

#	Section	Weight	Examples
1	Kernel (sysctl)	30	SYN cookies, ICMP redirects, source routing, `rp_filter`, `kptr_restrict`, `ptrace_scope`, ASLR
2	Network stack	10	conntrack, IP forwarding, `bridge-nf-call-iptables`
3	Firewall	25	Rules on the INPUT path, stateful rule, default-deny on INPUT/FORWARD, IPv6
4	SSH and hardening	15	`PermitRootLogin`, `PasswordAuthentication`, blocked legacy modules, core dumps
5	Users	10	Single UID 0, no empty passwords, system accounts without login shells
6	Permissions	10	`/etc/shadow`, `/etc/passwd`, world-writable directories
7	Info (no score)	–	Listening ports, sudoers `NOPASSWD`, pending security updates, mount options, SUID inventory

Each control returns PASS, FAIL, or N/A. N/A means "doesn't apply here" (IPv6 disabled, no sshd installed) and awards the points so you aren't penalized for attack surface you don't have.

Design decisions worth explaining

Read sysctl from /proc/sys. Reading the files directly means Lynx doesn't depend on the sysctl binary or on PATH being sane under su.

Look at all three firewall backends. On modern Debian, iptables may point to iptables-nft, and rules loaded in legacy and in nft don't see each other. Lynx reads iptables-legacy-save, iptables-nft-save and nft list ruleset, and warns if rules live in more than one place.

Understand fwbuilder output. fwbuilder generates -m state --state ESTABLISHED,RELATED rather than -m conntrack --ctstate, and often ends INPUT with a jump to a user chain that finishes in DROP. Lynx recognizes both styles and follows jumps (up to a depth limit) to find the final deny.

Evidence you can verify. Raw dumps (rulesets, sshd -T, sudoers, listening ports, a copy of any .fw scripts found) go to lynx_evidencias_<timestamp>/ with a SHA256SUMS manifest. The report gets its own .sha256. The hash is computed after the report is finished, so it can't change the thing it protects.

Putting it to the test on a real Debian 13 dev server

Tests with simulated dumps prove that the parsers work. They don't prove the tool says anything useful about a messy, real machine. So I ran Lynx on a development server I'm free to poke at.

The test machine

Debian GNU/Linux 13 (trixie), kernel 6.12.96, amd64
Docker installed: one bridge (docker0) and a container published on port 3000
OpenSSH on 22, a Python service on 3001, avahi-daemon, and dhcpcd on several interfaces
iptables is the nft variant (/usr/sbin/xtables-nft-multi), no legacy rules, no fwbuilder, and ufw enabled as a systemd service
A typical dev box: working, but never through a hardening pass One note on the output below: I kept it verbatim, and the report is in Spanish. The firewall labels read, in order: rules loaded, stateful rule, INPUT default-deny, FORWARD default-deny, IPv6 filtered.

First run: 56/100

[PASS] +5 pts | Firewall rules loaded into the kernel (any backend)
[PASS] +7 pts | Stateful ESTABLISHED,RELATED rule (conntrack, state, or nft ct state)
[FAIL]   0 pts | INPUT with DROP/REJECT policy or final deny rule
[PASS] +3 pts | FORWARD with DROP/REJECT policy (or forwarding disabled)
[PASS] +3 pts | IPv6 filtered by firewall (or IPv6 disabled)
...
 AUDIT SCORE: 56 / 100 (56%)  -  29 controls evaluated

Four passes and one failure reads like a firewall that mostly works. It wasn't. The same report listed nine sockets listening on all interfaces, SSH among them, and the INPUT check was the only line telling the truth.

Why 56 was too generous

Docker installs its own rules in the FORWARD path, including an ESTABLISHED,RELATED accept. My checks searched any chain for those rules, so Docker's traffic rules satisfied "the host has a stateful firewall". That's a false positive that makes a machine look safer than it is, which is the worst kind of bug in a security tool.

The fix was to evaluate only chains reachable from INPUT:

# Chains reachable from a starting chain (follows -j / -g into user chains)
ipt_reach() {   # $1 = iptables-save dump (filter table), $2 = starting chain
    awk -v start="$2" '
        $1=="-A" { for (i=3;i<=NF;i++) if ($i=="-j" || $i=="-g") { n++; from[n]=$2; to[n]=$(i+1) } }
        END {
            seen[start]=1
            do { changed=0
                 for (k=1;k<=n;k++) if ((from[k] in seen) && !(to[k] in seen)) { seen[to[k]]=1; changed=1 }
            } while (changed)
            for (c in seen) print c
        }' <<<"$1"
}

The stateful and "rules present" checks now only count rules in INPUT or in chains INPUT jumps to, which is how UFW's ufw-before-input and fwbuilder's RULE_N chains work. The nftables side does the same, starting from chains with hook input and following jump and goto.

I validated this against 25 simulated cases: Docker alone, UFW active, UFW plus Docker, fwbuilder with a direct rule, fwbuilder via a RULE_1 chain, native nftables with sets, and an empty ruleset. That exercise also exposed a bug in my first nft parser, which treated a rule beginning with counter packets … as a named-object declaration and lost track of the chain.

Two more checks needed the same kind of honesty. bridge-nf-call-iptables now ignores bridges created by Docker, libvirt, LXD, CNI and Podman. And rp_filter is evaluated the way the kernel does it: the maximum of the all value and the per-interface value, not all alone.

Second run: 47/100

Same machine, corrected build:

[FAIL]   0 pts | Firewall rules filtering incoming traffic (INPUT)
[FAIL]   0 pts | Stateful rule ESTABLISHED,RELATED (conntrack, state, or nft ct state)
[FAIL]   0 pts | INPUT with DROP/REJECT policy or final deny rule
[PASS] +3 pts | FORWARD with DROP/REJECT policy (or forwarding disabled)
[FAIL]   0 pts | IPv6: inbound traffic filtered by firewall (or IPv6 disabled)
...
 AUDIT SCORE: 47 / 100 (47%)  -  29 controls evaluated

The score went down by nine points, and the arithmetic is fully explained by five controls:

Control	First build	Second build	Points
`rp_filter` (effective, per interface)	FAIL	PASS	+3
`bridge-nf-call-iptables`	FAIL	N/A (only `docker0`)	+3
Rules on the INPUT path	PASS	FAIL	−5
Stateful rule on INPUT	PASS	FAIL	−7
IPv6 inbound filtering	PASS	FAIL	−3
Total	56	47	−9

Two corrections raised the score because the old checks were too strict. Three lowered it because they were too lenient. The net effect is a lower number and a more truthful report.

The backends section shows what was really loaded:

- iptables binary: /usr/sbin/xtables-nft-multi
- iptables-legacy rules: 0 (IPv4) / 0 (IPv6)
- iptables-nft rules: 15 (IPv4) / 7 (IPv6)
- nftables (ruleset) : with rules

So there are 15 IPv4 and 7 IPv6 rules loaded, but Lynx finds none reachable from INPUT and no default-deny on it. The "persistence" block lists ufw as enabled in systemd. That only means the service starts at boot, not that it enforces a policy, which is exactly why Lynx reports persistence as information rather than as a pass.

What the rest of the report says about the box

Exposure. 18 listening sockets, 9 of them bound to all interfaces: OpenSSH (22, IPv4 and IPv6), the Python service (3001), docker-proxy (3000, IPv4 and IPv6), and avahi-daemon (mDNS on 5353 plus random UDP ports). mDNS on a server is rarely needed.
SSH. Both the PermitRootLogin and the PasswordAuthentication checks failed. With port 22 reachable on every interface and no inbound filter, that is the combination that deserves attention first.
Kernel. Failures: ICMP redirects (IPv4 and IPv6), send_redirects, kptr_restrict, ptrace_scope, and IP forwarding (most likely because of Docker). Passes: SYN cookies, source routing, rp_filter, dmesg_restrict, ASLR and suid_dumpable.
Patching. 106 packages upgradable, 36 of them security updates, and no unattended-upgrades. The apt cache was 0 days old, so the count is trustworthy.
Mount options. /tmp and /dev/shm are separate mounts but lack noexec. /var/tmp and /home inherit from / and lack nodev, nosuid and noexec.
Files. 49 SUID/SGID binaries, no world-writable files, and 22,273 files with no owner or group. I haven't investigated that last number; on a Docker host I would start with container volumes and image layers.
Good news. AppArmor active, NTP synchronized, journald persistent, a single UID 0, no empty passwords, correct permissions on /etc/shadow and /etc/passwd, no legacy network services installed (telnet, rsh, NIS, tftp, xinetd), and no world-writable directories without the sticky bit. The final level was LOW (47%), which I think is a fair description of an unhardened dev server.

Cross-checking Lynx's findings

A report is only worth trusting if you can verify it by hand. These commands reproduce the key findings, and the raw material is also in the evidence directory:

sudo ufw status verbose                          # is UFW actually enforcing anything?
sudo iptables -S INPUT                           # INPUT policy and rules (nft backend)
sudo nft list ruleset | grep -A3 'hook input'    # base chains on the input hook
ss -tulpn                                        # what is listening, and who owns it
sysctl -a | grep rp_filter                       # per-interface rp_filter values

What I took from this

A score is only as honest as its scoping. Counting rules from any chain made Docker's traffic rules look like a host firewall. Scoping the check to what the inbound path can actually reach fixed it.
Simulated tests and real runs catch different bugs. The simulations found a parser bug. Only the real machine showed that a perfectly working check was answering the wrong question.
A lower score is not a regression. After the fix the number was worse and the report was better. ## Try it

git clone https://github.com/<your-username>/lynx.git
cd lynx
less lynx.sh          # please read it before running anything as root
chmod +x lynx.sh
sudo ./lynx.sh

Reports go to /var/lib/lynx/<hostname>/ by default. Useful variables:

sudo REPORT_DIR=/srv/audits ./lynx.sh        # custom output directory
sudo LYNX_FLAT=1 REPORT_DIR=/srv/audits ./lynx.sh   # no per-host subdirectory
sudo ES_ROUTER=1 ./lynx.sh                   # host routes on purpose: forwarding isn't a failure
sudo SKIP_SLOW=1 ./lynx.sh                   # skip the slow find-based inventories
sudo SIN_EVIDENCIAS=1 ./lynx.sh              # report only, no raw evidence

One naming note: Debian and Ubuntu already have a text-mode web browser called lynx. If you install the script system-wide, give it a different name:

sudo install -m 0750 -o root -g root lynx.sh /usr/local/sbin/lynx-audit

To verify an audit later:

sha256sum -c lynx_reporte_<timestamp>_<pid>.txt.sha256
cd lynx_evidencias_<timestamp>_<pid> && sha256sum -c SHA256SUMS

Limitations

Narrow coverage. 29 scored controls is a small slice of something like a CIS Benchmark. It doesn't cover filesystem layout, PAM and password policy, most sshd options, auditd or integrity monitoring. Some checks resemble CIS recommendations but differ; for example, Lynx accepts PermitRootLogin prohibit-password, while CIS requires no. For formal compliance, use OpenSCAP or CIS-CAT.
Small validation base. One real Debian 13 development server (the two runs described above), an Ubuntu 24.04 environment, and simulated firewall dumps for everything else. Treat it as young software and try it on a test machine first.
Static sshd fallback. If sshd -T fails, Lynx reads the config files directly and doesn't interpret Match blocks.
Patch counts depend on apt's cache. Lynx warns when the cache is old.
fwbuilder detection is heuristic. It looks for the "Firewall Builder" marker in *.fw files and boot scripts.
The report is in Spanish. The script grew up in a Spanish-speaking environment; translations and an i18n layer would be a welcome contribution.

Who it's for

Sysadmins and infrastructure teams who want a fast, repeatable first look at Debian/Ubuntu servers. Auditors who need evidence with checksums. Anyone migrating from iptables-legacy or fwbuilder toward nftables who needs to see what is really loaded. Students who want a readable example of how these checks work.

It is not meant to replace a compliance scanner, a penetration test, or your own judgment about what "secure" means for your environment.

Contribute

Lynx is Apache-2.0. Issues and pull requests are welcome. Before sending one, run bash -n lynx.sh and shellcheck lynx.sh, and keep new controls read-only so the "passive" promise stays true.

If you run it and find a false positive or a check that misreads your setup, I want to hear about it. The Docker bug above only showed up because someone (me) ran the script on a real machine.

🔗 Useful Links & Documentation

GitHub Repository: https://github.com/matarturo/lynx
Open Source Edition Install:

  curl -fsSLO https://raw.githubusercontent.com/matarturo/lynx/main/lynx.sh
  chmod +x lynx.sh
  sudo ./lynx.sh

Si el directorio está en un sistema de archivos montado con noexec, ejecútalo con sudo bash lynx.sh.

Conclusion & Call to Action

Auditing modern Linux systems reveals a recurring technical limitation in generic tools: the superficial handling of hybrid network backends (iptables-legacy, iptables-nft, and nftables) and a tendency toward false positives—such as erroneously assuming that container forwarding (FORWARD) rules protect host traffic. Addressing this requires reachability analysis at the parsing level that traces jumps (-j, -g) directly from INPUT chains, reads kernel state natively from /proc/sys to avoid path dependencies, and evaluates complex metrics like the effective rp_filter per interface. Reliable infrastructure assessment requires auditing actual socket exposure across all interfaces, reviewing restrictive mount options (noexec, nodev, nosuid), correlating pending security patches, and generating verifiable evidence via SHA-256 cryptographic hashes without altering the operating system's state.

Technical actions to improve infrastructure security posture:

Ingress-plane reachability validation: Do not rely on declarative service persistence (such as active UFW or systemd states); verify via parsing that default-deny and filtering rules effectively reside in the INPUT path and are not bypassed by traffic from virtual network bridges or hypervisors.
Exposure and attack surface control: Conduct passive audits to detect globally listening sockets (services on ports 22, 3000, 3001, mDNS, etc.), permissive sshd hardening parameters, and the inventory of SUID/SGID binaries or ownerless files. Guarantee of evidence immutability: Ensure that any control script or routine calculates hash manifests (SHA-256) after report consolidation to preserve forensic traceability for configuration analysis and configuration drift detection.

Clone the repository, test it against your servers, and see what your current scanner has been missing. Drop a star, open an issue, or share your feedback

Soft-404s: The Silent Killer of DAST Scans

Arturo Enrique Mata Garcia — Sun, 27 Sep 2026 22:58:54 +0000

Traditional DAST tools have a dirty secret: they don't know when a page doesn't exist. And in modern SPA architectures, this blindness doesn't just generate noise—it corrupts the entire assessment.

If you're a pentester, DevSecOps engineer, or security researcher, you've seen it. You run a scan. The report says everything is fine. Then a manual test reveals a critical endpoint that was never crawled, never tested, and never reported. The scanner missed it because it couldn't distinguish a real page from a soft 404.

VORTEX Assessment Engine was built to solve exactly that.

🔬 What Is a Soft-404 and Why It Breaks DAST

A soft-404 is an HTTP response that returns 200 OK while serving content that semantically means "not found." Unlike a hard 404, which correctly returns a 404 status code, a soft-404 masks missing routes as legitimate pages.

This is not a bug. It's a design pattern in many modern frameworks:

React Router, Vue Router, and Angular Router often render a "not found" component with a 200 status.
Next.js and Nuxt handle dynamic routes dynamically, sometimes returning 200 for missing paths.
SPAs with client-side routing are especially prone: the server always returns the same index.html, and the router decides what to display.

For a DAST scanner, this is a minefield:

False positives: the scanner treats the fallback as a real page and tests it, then reports findings against content that isn't a distinct endpoint at all.
False negatives: the scanner assumes a path is a fallback and skips it — dropping a genuinely reachable route from the test suite entirely.
Blind spot in targeted checks: any check that probes a wordlist of known paths — API discovery, path scanning, dependency detection — has no way to tell "found it" from "the fallback said yes to everything."
Broken coverage: none of the above shows up as a failure in the summary line. The report still says "scan complete."

Traditional scanners rely on static HTML parsing and HTTP status codes. Neither works reliably with soft-404s.

🕸️ Why VORTEX Handles Soft-404s Differently

VORTEX doesn't take a 200 OK at face value — and that one decision is what separates a scan you can trust from a scan that just looks clean.

You stop chasing ghosts. Every "page" that's really just the SPA fallback in disguise gets filtered out before it ever reaches your report. No more triaging findings against a page that was never real.
You stop losing real endpoints. Routes that legacy scanners write off as "probably just the 404 page" get evaluated on their actual content, not assumed away.
It happens automatically, before anything else runs. No config, no manual allowlisting of fallback pages, no tuning per target. The calibration runs first and every downstream check inherits the result.

The result: a report where "not found" means not found, and "found" means found — which is the entire point of running a scanner in the first place.

🧪 Real-World Impact

Run against OWASP Juice Shop (Docker, port 3000): the moment VORTEX detected the SPA fallback pattern, it adjusted — and the rest of the assessment came back clean of the noise that pattern usually creates. Zero false findings traced back to fallback pages. Zero wasted cycles re-testing the same page under a different URL.

That's the difference this one check makes: not a longer report, a trustworthy one.

⚡ Why This Matters for CI/CD

In a CI/CD pipeline, a DAST scanner that cannot handle soft-404s is worse than no scanner at all. It gives you false confidence: the pipeline goes green, coverage looks complete, and the gap only surfaces later, usually manually, usually after deployment. You deploy. You think you're covered. You're not.

Calibrating for the fallback pattern before running the rest of the suite is what keeps "clean scan" from quietly meaning "we didn't actually look."

What that looks like in an actual run: the calibration check isn't a separate step someone has to remember to run — it's one of 18 checks executed in the same pass, timestamped and reproducible (2026-09-27T17:42:36). It also isn't the thing slowing the pipeline down: the same run completed with a 0.01s performance result. And the consequence isn't hypothetical — in this run, both API Discovery and Path Scan came back clean after the calibration step had already flagged content-based filtering as necessary, meaning those results reflect the fallback-aware logic, not a naive status-code check that got lucky.

Beyond what this specific run shows, VORTEX is positioned as pipeline-native by design — no cloud dependency, no separate runtime to provision, SARIF output for native integration with code-scanning tools, and a deterministic execution model. (Stated product characteristics, not something demonstrated by this particular PoC run.)

Soft-404 calibration is not a feature. It's a prerequisite for accurate DAST in modern web applications.

🔬 Evaluation Flow

A typical security assessment with VORTEX follows this streamlined execution sequence:

                  WEB APP
                     │
                     ▼
            ┌─────────────────┐
            │     VORTEX      │
            │     Crawler     │
            └────────┬────────┘
                     │
                     ▼
           Soft-404 Calibration
                     │
                     ▼
          SPA / Route Discovery 
                     │
                     ▼
          JavaScript Analysis
                     │
                     ▼
          Security Assessment
                     │
                     ▼
            ┌─────────────────┐
            │    RESULTS      │
            └────────┬────────┘
                     │
            ┌────────┼────────┐
            ▼        ▼        ▼
          HTML      JSON     SARIF

The soft-404 calibration step sits early in the pipeline for a reason: everything downstream — path scanning, API discovery, the security tests themselves — depends on knowing whether 200 OK means "page exists" for this specific target.

🧪 Proof of Concept: Soft-404 Calibration in a Modern SPA

The following output is from a VORTEX scan (PRO account) against OWASP Juice Shop, a deliberately vulnerable SPA built with Angular, deployed locally via Docker on port 3000. It captures a real-world scenario where the server returns 200 OK for non-existent routes.

root@sandbox-vortex:/opt/vortex# vortex --local --port 3000

██╗   ██╗ ██████╗ ██████╗ ████████╗███████╗██╗  ██╗
██║   ██║██╔═══██╗██╔══██╗╚══██╔══╝██╔════╝╚██╗██╔╝
██║   ██║██║   ██║██████╔╝   ██║   █████╗   ╚███╔╝
╚██╗ ██╔╝██║   ██║██╔══██╗   ██║   ██╔══╝   ██╔██╗
 ╚████╔╝ ╚██████╔╝██║  ██║   ██║   ███████╗██╔╝ ██╗
  ╚═══╝   ╚═════╝ ╚═╝  ╚═╝   ╚═╝   ╚══════╝╚═╝  ╚═╝  v3.0.6

Assessment Engine

LOCAL · FAST · ACTIONABLE

[*]  GUMROAD_PRO license renewed via CEREBELLUM.
[*] Starting VORTEX Security Audit v3.0.6
    Target: http://127.0.0.1:3000
===========================================================================
Audit Progress: [   6% ] [ ██---------------------------- ]
--- [1/15] Discovery & Crawler ---

=== DISCOVERY (CRAWLER) ===
[!] Soft-404 Calibration             [WARN] Server responds 200 to non-existent routes (SPA fallback) - Path Scan and API Discovery will filter by content, not just status code

Interpretation:

The server returned 200 OK for a non-existent route.
VORTEX correctly classified this as SPA fallback behavior rather than a real page.
Calibration status: WARN.
Downstream checks switch to content-based filtering as a direct result.

This is the exact scenario where legacy DAST tools fail silently. VORTEX makes the failure mode visible instead.

🔗 Useful Links & Documentation

Official Website & Docs: zerodayslab.co/docs
GitHub Repository: matarturo.github.io
Community Edition Install:

  curl -sSL -o install.sh https://raw.githubusercontent.com/matarturo/vortex/main/install.sh
  chmod +x install.sh
  sudo ./install.sh

Conclusion & Call to Action

Soft-404s are not a minor edge case. They are a fundamental blind spot in traditional DAST tools, and they silently corrupt the accuracy of every scan run against a modern SPA.

VORTEX was built to close that gap. The run shown above was captured on a PRO license; the soft-404 calibration step is the core mechanism this article is about, so if you're running the Community Edition, check your own output for the same Calibracion Soft-404 line before assuming feature parity.

Clone the repository, test it against your own SPAs, and see what your current scanner has been missing. Drop a star, open an issue, or share your feedback. See you in the code.

Taming SPAs with VORTEX: How a Crawler Actually Understands React, Vue, and Angular

Arturo Enrique Mata Garcia — Thu, 10 Sep 2026 15:47:32 +0000

💡Let’s run a mental experiment.

You open a SPA built with React. You point your favorite scanner—the one you've used for years, the one that "never fails"—to audit it. You wait. It generates a neat, polished report with a nice logo and a progress bar. And it tells you: "2 routes found. 0 critical vulnerabilities."

Two routes. In an application featuring a complete dashboard, an admin panel, over forty endpoints, and half a dozen features locked behind feature flags.

The scanner isn't broken. The scanner is blind. And nobody told it.

That was, literally, the starting point of VORTEX Assessment Engine. In my previous post, I covered the overall architecture: a self-hosted engine, a native binary, zero heavy dependencies, and direct CI/CD pipeline integration. Today, I want to lift the hood and show you the piece that makes all of that actually matter: the crawler, and what happens when it steps directly inside the JavaScript instead of just staring at it from the outside.

If you're a developer, this might sting a little. If you're a DevOps engineer, you'll care about how it plugs into the pipeline. And if you're a pentester... well, you already know exactly what I'm talking about.

🧱 HTML Is No Longer a Map. It’s a Lid.

Let's look at the facts. This is what a curl response to a modern SPA looks like:

<div id="root"></div>
<script src="/static/js/main.a1b2c3.js"></script>

That is literally all there is. No <a href>, no forms, no routes, nothing that a 2000s-era HTML parser can chew on. The entire application—components, router, API calls, business logic, validations, everything—is compressed and minified inside that single .js file, and it gets built right inside the browser in real-time the moment a user hits the page.

A crawler that only knows how to read HTML is staring at a locked door with a sign saying "nothing to see here." And it actually believes it.

This isn’t a minor limitation or an academic edge case. It’s the exact reason why, year after year, we keep seeing:

Google Maps, Stripe, or Firebase API keys leaked in production for months.
Complete administrative routes (/admin, /internal, /debug) that nobody discovered because they only render after a specific menu click.
Staging or internal microservice endpoints, referenced deep inside a bundle, that a "traditional" dynamic scan never touched.

Frontend secret leakage reports aren't going down. And they won't, because the tools meant to catch them are still playing a game that ended a decade ago.

⚙️ How VORTEX Solves It: Stop Reading, Start Executing

The core design decision behind the VORTEX crawler is simple to state and much harder to build right: instead of parsing HTML, execute the application like a real user would, and observe what happens next.

     WEB APPLICATION
            │
            ▼
   ┌─────────────────┐
   │     VORTEX      │
   │     Crawler     │
   └────────┬────────┘
            │
            ▼
 Rendering + Dynamic Route Discovery
            │
            ▼
    JS Bundle Extraction & Analysis
            │
            ▼
   Attack Surface Correlation

🔍 Let's break down why that actually matters.

1. 🧭 Route Discovery: Don't Read, Navigate

VORTEX doesn't just scrape links. It interacts: it clicks, navigates, opens menus, triggers transitions, and listens to the history changes fired on-the-fly by React Router, Vue Router, or Angular Router.

Why is this a big deal? Because the most interesting routes are almost never just a single obvious click away. They hide behind:

A dropdown menu that only renders on hover.
A tab loading a lazy chunk via dynamic import().
A route guard that only mounts a component if an active session exists.

None of that exists in the initial HTML. It only exists after something happens inside the browser. And a crawler that doesn’t simulate that "something" will simply never see it.

(Yes, authentication-protected routes are a whole separate, juicy topic—VORTEX supports credentials, --login-path, and session cookie handoff to reach them—but that deserves its own dedicated post. Today, we're sticking to the core crawler.)

2. 📦 Static JS Bundle Analysis: The Mistake We've All Made at Least Once

This is, without exaggeration, my favorite part of the engine. And the most underrated feature in any DAST tool.

Put yourself in the shoes of the developer writing the code, because that’s where the problem actually starts. You're deep into a sprint, you need a map to load right now, or an analytics widget to work in the staging environment. You paste the key straight into the source code, with every intention of moving it to an environment variable "as soon as I have five minutes." The PR gets reviewed—nobody notices, because nobody is checking that line by line—it gets merged, and Webpack or Vite do their job: they minify, bundle, and that key ends up shipping, completely intact, inside the main.a1b2c3.js file served publicly to anyone opening the app.

That exact moment—the "I'll fix it later" that never comes—is the exact kind of oversight that a static JS bundle analysis is built to catch. Nobody needs to click anything, and no suspicious requests need to be fired: the file is already public, accessible to anyone with a browser and their DevTools open, and it already contains what it shouldn't.

And here’s the kicker that almost no one sees coming: most of these leaks never generate a visible HTTP request during a standard dynamic scan. They don't show up in network traffic because the issue isn't what the app does, but what the bundle contains. A purely black-box scan—one that only watches packets flying back and forth—will never touch them, because it never looked inside the file itself.

If you've ever inspected your own app's bundle "out of curiosity" and found something that shouldn't be there... you know exactly what I'm talking about. And if you haven't, it’s probably worth checking before someone less friendly than you does.

3. 🎯 Correlation: Active Testing Against Real Surface Area, Not Assumptions

Once the crawler maps out the complete route tree and finishes the JS bundle analysis, VORTEX fires active security tests—SQLi, XSS, Path Traversal, among others—directly against that discovered surface, rather than firing payloads at a handful of guessed URLs or an outdated sitemap.

 SPA / Route Discovery
            │
            ▼
 JavaScript Analysis
            │
            ▼
 Security Assessment

The practical difference: scanning cycles are concentrated where there is actually something to attack, instead of wasting time hitting ghost routes that never existed or that no real user could ever reach.

👥Why Every Technical Role Should Care

Because no, this isn't "just a security thing." It hits each role differently:

👨‍💻If you're a developer: that bundle you just pushed to production with a hardcoded VITE_API_KEY "just to test on staging"—yeah, that one—is precisely what this crawler is designed to find before an attacker does. It's not personal. It's math.
🚀 If you're a DevOps / DevSecOps engineer: finding an issue like this inside a pull request, before the merge, costs minutes of fixing and a single line in a changelog. Finding that exact same issue three weeks later in production—or worse, reported by an outside party, or worse still, exploited—costs an incident response, an awkward meeting, and likely a post-mortem. Bringing this analysis into the pipeline turns security gating into an early check rather than a late, ceremonial audit.
🕵️‍♂️If you're a pentester: you already know the frustration of wasting the first two hours of an engagement simply trying to manually map an application because the automated crawler gave up at the loading screen. An engine that handles that discovery for you—while handing you pre-analyzed bundle results—doesn't replace your judgment; it gives you back your time for what actually requires a human brain: exploitation and impact analysis.

⚡Conclusion

HTML stopped being the application map years ago. The real map lives inside the JavaScript your browser silently executes every single time you load a page. A DAST tool that doesn't understand that isn't evaluating your app: it's evaluating an empty shell with a <div id="root"></div> inside, congratulating you on how clean it looks.

If you want to see the crawler running against your own SPA, the Community Edition is still available with no credit card required. And if you test it against something built with Svelte, Solid, Qwik, or any framework outside the usual trio, let me know how it behaves—that feedback is absolute gold for keeping the engine sharp.

🔗 Useful Links & Documentation

🌐 Official Website & Docs: zerodayslab.co/docs
💻 GitHub Repository: matarturo.github.io

More Than Just a Scanner: Architecture of a Self-Hosted DAST Engine for SPAs and CI/CD

Arturo Enrique Mata Garcia — Tue, 08 Sep 2026 20:28:52 +0000

Traditional DAST tools are often a massive headache for modern development teams: they are slow, tightly coupled to third-party cloud services, and worst of all, completely blind to Single Page Applications (SPAs) built with React, Vue, or Angular where routing and application logic live entirely on the client side.

If you are shipping software fast, you need a tool that speaks your language: a native, portable binary with zero heavy runtime dependencies (no Python or pip required in production) that integrates seamlessly into your CI/CD pipelines to enforce real security gatekeeping.

Meet VORTEX Assessment Engine, developed by Arturo Mata.
Official documentation and interactive diagrams are also available at matarturo.github.io.

If you are a pentester, DevSecOps engineer, or web developer, you have likely suffered through traditional DAST tools. They are sluggish, heavy, and above all, clueless about modern web applications.

SPAs built with React, Vue, or Angular rely almost entirely on JavaScript. Legacy crawlers get lost, fail to discover dynamic routes, and let critical vulnerabilities slip by—alongside exposed frontend secrets.

VORTEX Assessment Engine was built to solve precisely that problem. It is a self-hosted, high-performance DAST engine engineered specifically to evaluate SPAs with a deep focus on JavaScript analysis and native CI/CD pipeline integration.

🔬 Architecture: A Self-Hosted Engine

Unlike commercial SaaS scanners that require shipping your application code to an external cloud, VORTEX runs entirely within your own infrastructure. This guarantees:

Privacy: Your target application never leaves your secure perimeter.
Total Control: You know exactly where and how the scan execution takes place.
Automation-First: Easily embed it into a Bash script or native pipeline step.

┌───────────────────────────────────┐
│        YOUR INFRASTRUCTURE        │
│                                   │
│   ┌───────────────────────────┐   │
│   │   VORTEX Assessment       │   │
│   │        Engine             │   │
│   └─────────────┬─────────────┘   │
│                 │                 │
│                 ▼                 │
│          WEB APPLICATION          │
│            TARGET                 │
└───────────────────────────────────┘

🕸️ Why Does VORTEX Understand SPA's?

Conventional DAST scanners rely heavily on static HTML parsing. VORTEX incorporates an SPA-optimized crawler that performs the following actions:

Renders and discovers dynamic routing structures across React, Vue, and Angular applications.

Performs deep parsing of JavaScript bundles to hunt down:
Exposed API keys
Authentication tokens
Hardcoded credentials
Sensitive internal configuration secrets

🔬 Evaluation Flow

A typical security assessment with VORTEX follows this streamlined execution sequence:

               APLICACIÓN WEB
                     │
                     ▼
            ┌─────────────────┐
            │     VORTEX      │
            │     Crawler     │
            └────────┬────────┘
                     │
                     ▼
           SPA / Route Discovery
                     │
                     ▼
          JavaScript Analysis
                     │
                     ▼
          Security Assessment
                     │
                     ▼
            ┌─────────────────┐
            │    RESULTS      │
            └────────┬────────┘
                     │
            ┌────────┼────────┐
            ▼        ▼        ▼
          HTML      JSON     SARIF

VORTEX fires targeted security tests (SQLi, XSS, Path Traversal, etc.) directly against the discovered surfaces. This rigorous JavaScript inspection uncovers severe flaws that standard black-box scanners routinely miss.

🔬 Real-World Environment Demonstration

Your browser does not support the video tag.

⚡ A Native, Frictionless Binary

VORTEX is distributed as a self-contained, native Linux binary. This design delivers distinct performance advantages:

Zero requirements for Python, pip, or fragile runtime dependencies.
No Node.js engine required on the target execution host.
Ultra-lightweight footprint (averaging under 6% CPU utilization and 62 MB of RAM during standard scans).
This native portability allows you to spin up VORTEX inside staging servers, auditing workstations, or ephemeral Docker containers without complex setup overhead.

🔌 Native CI/CD Integration

One of the greatest friction points in DevSecOps is integrating security testing without turning pipelines into delivery bottlenecks. VORTEX outputs native SARIF 2.1.0 reports, enabling strict security gatekeeping across popular developer platforms.

GitHub Actions (.github/workflows/security.yml)

YAML
name: VORTEX Security Assessment

on:
  push:
  pull_request:

jobs:
  vortex:
    name: VORTEX Security Scan
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install VORTEX
        run: |
          curl -sSL [https://raw.githubusercontent.com/matarturo/vortex/main/install.sh](https://raw.githubusercontent.com/matarturo/vortex/main/install.sh) | sudo bash

      - name: Run VORTEX
        run: |
          vortex [https://my-app.com](https://my-app.com) --output /opt/vortex/reporte/reporte.sarif

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: /opt/vortex/reporte/reporte.sarif

GitLab CI (.gitlab-ci.yml)

YAML
vortex_security:
  stage: test

  script:
    - curl -sSL [https://raw.githubusercontent.com/matarturo/vortex/main/install.sh](https://raw.githubusercontent.com/matarturo/vortex/main/install.sh) | bash
    - vortex [https://my-app.com](https://my-app.com) --output /opt/vortex/reporte/reporte.sarif

  artifacts:
    when: always
    paths:
      - /opt/vortex/reporte/

Azure DevOps (azure-pipelines.yml)

YAML
steps:
- checkout: self

- script: |
    curl -sSL [https://raw.githubusercontent.com/matarturo/vortex/main/install.sh](https://raw.githubusercontent.com/matarturo/vortex/main/install.sh) | sudo bash
    vortex [https://my-app.com](https://my-app.com) --output /opt/vortex/reporte/reporte.sarif
  displayName: 'VORTEX Security Assessment'

- task: PublishBuildArtifacts@v4
  inputs:
    pathToPublish: '/opt/vortex/reporte'
    artifactName: 'VORTEX-Reports'
  displayName: 'Publish VORTEX Reports'

⚡ Quick Installation

Want to test the VORTEX Community Edition? No credit card is required to get started.

Install on Ubuntu / Debian

curl -sSL -o install.sh [https://raw.githubusercontent.com/matarturo/vortex/main/install.sh](https://raw.githubusercontent.com/matarturo/vortex/main/install.sh)
chmod +x install.sh
sudo ./install.sh

Run Your First Local Assessment

vortex --local --port [PORT_NUMBER]

🔗 Useful Links & Documentation

Official Website & Docs: zerodayslab.co/docs
GitHub Repository: github.com/matarturo/vortex

Conclusion & Call to Action

VORTEX was built to bridge the gap between fast-paced modern software development and offensive security requirements.

Clone the repository, test out the Community edition against your local SPAs, and drop a star on the repo or share your feedback to help drive the project forward. See you in the code!

DEV Community: Arturo Enrique Mata Garcia

Beyond Header Grabbing: Detecting Apache mod_http2 (CVE-2026-119618) with Custom Nmap NSE

🛑 The 3 Technical Challenges We Had to Solve

1. The Dual-Protocol Problem (h2 vs h2c)

2. The "Silent" Server (ServerTokens Prod)

3. The Binary Verdict Trap

🔍 How the Detection Engine Works

💻 The Result in Terminal (Two Real Scenarios)

Scenario 1: Fully Exposed Environment (h2 over TLS)

Scenario 2: Hidden Version (ServerTokens Prod)

🧪 Field-Tested on Debian 13 (trixie)

The baseline: default httpd:2.4.70 is not vulnerable

The full three-container sweep

What the script is doing internally (nmap -d)

Why the "NOT VULNERABLE" case matters as much as the vulnerable one

🚀 Try it in your lab

💬 Let's Discuss: What Does "Not Vulnerable" Actually Mean?

🔗 Useful Links & Documentation

📦 Installation (Linux, macOS, Windows)

⚠️ noexec mount workaround

📚 What's in the repository

🛡️ A final word on scope

Beyond Header Grabbing: Detecting PHP2Shell Behind WAFs with Custom Nmap NSE

Lynx: a passive security auditor for Linux

What Lynx is

What it checks

Design decisions worth explaining

Putting it to the test on a real Debian 13 dev server

First run: 56/100

Why 56 was too generous

Second run: 47/100

What the rest of the report says about the box

Cross-checking Lynx's findings

What I took from this

Limitations

Who it's for

Contribute

🔗 Useful Links & Documentation

Conclusion & Call to Action

Soft-404s: The Silent Killer of DAST Scans

🔬 What Is a Soft-404 and Why It Breaks DAST

🕸️ Why VORTEX Handles Soft-404s Differently

🧪 Real-World Impact

⚡ Why This Matters for CI/CD

🔬 Evaluation Flow

🧪 Proof of Concept: Soft-404 Calibration in a Modern SPA

🔗 Useful Links & Documentation

Conclusion & Call to Action

Taming SPAs with VORTEX: How a Crawler Actually Understands React, Vue, and Angular

💡Let’s run a mental experiment.

🧱 HTML Is No Longer a Map. It’s a Lid.

⚙️ How VORTEX Solves It: Stop Reading, Start Executing

🔍 Let's break down why that actually matters.

1. 🧭 Route Discovery: Don't Read, Navigate

2. 📦 Static JS Bundle Analysis: The Mistake We've All Made at Least Once

3. 🎯 Correlation: Active Testing Against Real Surface Area, Not Assumptions

👥Why Every Technical Role Should Care

⚡Conclusion

More Than Just a Scanner: Architecture of a Self-Hosted DAST Engine for SPAs and CI/CD

🔬 Architecture: A Self-Hosted Engine

🔬 Real-World Environment Demonstration

2. The "Silent" Server (`ServerTokens Prod`)

Scenario 2: Hidden Version (`ServerTokens Prod`)

The baseline: default `httpd:2.4.70` is not vulnerable

What the script is doing internally (`nmap -d`)

⚠️ `noexec` mount workaround