Exploit for Improperly Controlled Sequential Memory Allocation in Php

A["urls.txt(one target per line)"] --> B["orchestrator.pystrictly sequential, one target at a time"]

subgraph DetectionLayers["Detection layers (all read-only / passive)"]

C1["scanner.pyheaders + 404 page + optional phpinfo probe"]

C3["wapiti --wapp module(fingerprint only, never its attack modules)"]

C5["nmap + vulners/vulscan NSECVE correlation"]

C6["cmseek --light-scanCMS identification"]

C1 --> D["reconcile()cross-check every tool's answer"]

E -->|"all agree on a PHP version"| F["VULNERABLE / PATCHED /EOL_UNPATCHED"]

E -->|"tools disagree"| G["UNKNOWN(DISAGREE — needs manual check)"]

E -->|"PHP implied (e.g. WordPress),version hidden"| H["UNKNOWN(PHP_DETECTED_VERSION_HIDDEN+ SAPI risk-priority triage)"]

E -->|"a DIFFERENT backendconfirmed (ASP.NET, Rails...)"| I["NOT_PHP"]

E -->|"nothing conclusive(CDN/analytics noise only)"| J["UNKNOWN(NO_BACKEND_SIGNAL)"]

F --> K["client_summary (plain English)+ report.json (full detail)"]

- **Six independent detection layers**, cross-checked against each other

- **Strictly sequential** scanning — one target at a time, always, with a

configurable delay — there is no concurrency flag and none will be

- **Plain-English `client_summary`** per target — safe to paste directly

into a report for a non-technical stakeholder

- **CMS-aware**: recognizes that WordPress/Joomla/Drupal/Magento/Laravel/

etc. *are* PHP even when no tool's fingerprint database explicitly

- **SAPI-based risk triage** for hidden-version targets, sourced directly

from the two PHP security advisories' own text — not a guess (see

[Security advisory grounding](#security-advisory-grounding))

- **Pre-flight tool check** — a missing/misconfigured tool fails loudly

- **Per-layer timing** in the JSON report, so a suspiciously-fast "result"

- Zero required cloud services or API keys for the core detection path

This project orchestrates existing, well-known tools rather than

reimplementing detection logic. Install what you want to use; each layer

degrades gracefully (reported as `SKIPPED` or excluded, never a crash) if

a given tool isn't installed, except where noted.

| [nmap]( | OS package manager / installer | Required for layers 4–5. The script auto-detects whether `vulners`/`vulscan` NSE scripts are installed and skips them gracefully if not. |

| [webtech]( | `pip install webtech` | Required for layer 2. |

| [Wapiti3]( | `pip install wapiti3` | Required for layer 3. **Known Windows issue**: its `cffi`/`zstandard` deps may fail to build on very new Python versions. If so, install it into a venv under an older Python (3.11–3.13) instead — no code changes needed, just point `PHP2SHELL_WAPITI_PATH` at that venv's `wapiti` executable. |

| [vulners NSE]( | `git clone` into nmap's `scripts/` directory, then `nmap --script-updatedb` | Optional. Online CVE correlation by detected version. |

| [vulscan NSE]( | `git clone` into nmap's `scripts/` directory, same `--script-updatedb` | Optional. Offline CVE correlation; refresh its bundled CSVs yourself for current data. On Windows, nmap's script.db matcher needs the vulscan script's **full path**, not its bare name — set `PHP2SHELL_VULSCAN_NSE_PATH` to that full path. |

| [CMSeeK]( | `git clone`, then `pip install -r requirements.txt` inside it | Required for layer 6. Despite its own README saying "Unix-based systems only for now," it runs fine on Windows too. |

Each tool's path is resolved in this order: an environment variable

override → `PATH` lookup → (Windows only) a couple of common install

locations. Nothing is hardcoded to any one machine.

# Only needed if a tool isn't already on PATH:

export PHP2SHELL_NMAP_PATH="/usr/bin/nmap"

export PHP2SHELL_WAPITI_PATH="/path/to/wapiti"

export PHP2SHELL_WEBTECH_PATH="/path/to/webtech"

export PHP2SHELL_CMSEEK_PATH="/path/to/CMSeeK/cmseek.py"

export PHP2SHELL_VULSCAN_NSE_PATH="/path/to/nmap/scripts/vulscan/vulscan.nse"

Run `python orchestrator.py --help` — the pre-flight check it prints

first will tell you exactly which tools it found and which env var to set

The path-resolution logic itself needs no Linux-specific code (the

Windows fallback paths are explicitly gated out on other platforms, and

`PATH` lookup works the same everywhere) — but two real Linux-specific

1. **Newer Debian/Ubuntu (PEP 668) reject a bare `pip install`** outside

a virtual environment ("externally managed environment" error). Use a

2. **nmap's `scripts/` directory is root-owned** on a typical Linux

install, same as `Program Files` is on Windows — installing the

optional `vulners`/`vulscan` NSE scripts needs `sudo`.

sudo apt update && sudo apt install -y nmap python3 python3-venv git

# 2. Python deps in a venv — this also puts wapiti/webtech on PATH

# automatically once activated, no env var needed for those two

# 3. CMSeeK — not pip-installable, clone it and point the scanner at it

git clone ~/tools/CMSeeK

pip install -r ~/tools/CMSeeK/requirements.txt

export PHP2SHELL_CMSEEK_PATH="$ /tools/CMSeeK/cmseek.py"

# 4. Optional: vulners/vulscan NSE scripts (needs sudo; skip this step

# entirely and the scanner just runs nmap without them — see "Info-

# gathering + CVE-correlation scripts" note in orchestrator.py)

sudo git clone /usr/ /nmap/scripts/vulners

sudo git clone /usr/ /nmap/scripts/vulscan

export PHP2SHELL_VULSCAN_NSE_PATH="/usr/ /nmap/scripts/vulscan/vulscan.nse"

# 5. Run it (re-activate the venv in any new shell session first)

cp urls.txt.example urls.txt # then edit with your real, authorized targets

python orchestrator.py urls.txt --json report.json

Only `PHP2SHELL_CMSEEK_PATH` and (optionally) `PHP2SHELL_VULSCAN_NSE_PATH`

need setting here — `nmap`, `wapiti`, and `webtech` all resolve

automatically via `PATH` once installed this way. Add the `export` lines

to your shell profile (`~/.bashrc`/`~/.zshrc`) if you don't want to

cp urls.txt.example urls.txt # then edit it with your real, authorized targets

python orchestrator.py urls.txt --json report.json

- `--check-phpinfo` — also probe common phpinfo-exposure paths (default off)

- `--skip-nmap` / `--skip-wapiti` / `--skip-cmseek` — drop a layer

- `--cmseek-deepscan` — use CMSeeK's deep scan (plugin/theme/user

enumeration, backup-file finder, admin-page finder, config-leak

detection) instead of its default light-scan. This actively probes many

paths per target — meaningfully more intrusive than everything else in

this pipeline. Run it one target at a time, never across a full list.

- `--delay N` — seconds between targets, default 3.0 (always sequential)

`scanner.py` can also be run completely standalone if you only want the

single header/404/phpinfo check without the other five layers:

python scanner.py urls.txt --json report.json

- `VULNERABLE` — confirmed version below the fix for its branch

- `PATCHED` — confirmed version at/above the fix

- `EOL_UNPATCHED` — end-of-life PHP branch, won't get a backport, needs

- `NOT_PHP` — a genuinely different backend platform was confirmed

- `UNKNOWN` — see `version_agreement` for why: no signal at all, PHP

detected/implied but version hidden, or tools disagreeing (never

- **`version_agreement`** — the short machine-readable reason behind an

- **`php_versions_seen`** — exactly which of the four version-capable

tools found what, so you can see agreement/disagreement yourself

- **`detected_technologies`** — the full tech stack each tool

fingerprinted, not just PHP (CMS, framework, web server, CDN, etc.)

- **`client_summary`** — one plain-English sentence, safe to paste

directly into a report for a non-technical reader

- **`sapi_priority`** — `HIGH_PRIORITY` / `MEDIUM_PRIORITY` /

`LOWER_PRIORITY` / `N/A`, a triage aid for hidden-version targets (see

Everything in the "why not just try to trigger it" and the SAPI

risk-priority logic comes directly from the two upstream PHP security

- [GHSA-w8hw-w9fx-j79w]( (CVE-2026-109618)

- [GHSA-6wmf-4rv5-p3rp]( (CVE-2026-109619)

Both advisories state explicitly that there is **no safe, non-crashing

way to confirm exploitability remotely** beyond comparing the installed

version against the fixed releases, and both explicitly warn against

sending the kind of crafted requests that would actually test the real

condition. This tool respects that boundary completely. The SAPI

risk-priority field (`HIGH_PRIORITY` for Apache/mod_php, `MEDIUM_PRIORITY`

for nginx+PHP-FPM/LiteSpeed, `LOWER_PRIORITY` for FrankenPHP) reflects

each advisory's own "affected configurations" section — it tells you

*which hidden-version target to chase a PHP version for first*, nothing

- No OOM-trigger probes, no oversized multipart uploads, no PHP-FPM

worker-abort cycling — the actual exploit chain for these CVEs, which

risks crashing production infrastructure. Several public "PoC" repos

for this CVE pair do exactly this; this project does not.

- No active exploitation modules from Nikto or Wapiti (their crawling,

injection, and brute-force modules) by default. Only Wapiti's passive

- No reliance on unverified third-party "detection" repos. Several

appeared within days of disclosure under anonymous accounts, giving

mutually contradictory descriptions of the bug — a classic pattern for

low-quality or malicious content riding a trending CVE's name. None of

- Cannot confirm exploitability on a hidden-version target — only the

vendor's own (destructive) test could, and this project won't go there.

- Linux distributions sometimes backport security fixes without changing

PHP's own reported version string. A version banner that looks

unpatched may already be fixed upstream in the distro's build — always

check the vendor/distro's own advisory for your platform when in doubt.

- CMS-core-version detection (CMSeeK, webtech, Wapiti's `wapp` module) is

**not** PHP-interpreter-version detection — no tool, including WPScan,

detects that. It only helps recognize that a target *is* PHP.

- `vulscan`'s offline CVE database is only as current as when you last

Built on top of these excellent existing tools — all credit for the

underlying detection techniques goes to their respective authors:

[nmap]( [Wapiti](

[webtech](

[CMSeeK](

[nmap-vulners](

[vulscan]( The PHP security team for

the advisories this tool's risk logic is grounded in.