Security Auditor — probes a site for the PHP
multipart/form-data crash bug tracked as CVE-2026-109618 / CVE-2026-109619.Resilience
A single unauthenticated request can crash the PHP worker, taking the site down.
Security
The memory corruption behind the crash can be a stepping stone to worse.
php2shell scanner against the audited URL to tell whether its PHP stack is affected by CVE-2026-109618 / CVE-2026-109619, a bug in PHP’s multipart/form-data parser that crashes the request handler. The fix ships in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
This is an active probe: it sends multipart bodies that can crash PHP workers. For that reason it never runs from an anonymous Quick Audit (preview_enabled is off) and the platform only runs it against domain-verified targets.
The detection logic is derived from Assetnote’s open-source php2shell-scanner, which this auditor wraps. Because a verdict is inferred from how the server responds to the probes, a human should verify any finding before acting on it — confirm the result against the host directly rather than treating the automated verdict as final.
How it works
- Control request — sends a minimal, well-formed multipart POST to the audited URL and records how the server answers (and whether it is phpMyAdmin, which the scanner retargets).
- Probes — sends up to three crafted multipart bodies designed to trip the parser, stopping early as soon as it has a verdict.
- Crash detection — looks for an in-band PHP fatal error, an empty
500/200body where the control produced output, or a502/503/504from the server fronting PHP-FPM. - Version fallback — when no crash is observed, reads the
X-Powered-Bybanner and compares it with the fixed releases. - Verdict — the scanner returns one verdict (
VULNERABLE,FIXED,NO SIGNAL,INCONCLUSIVEorERROR), which this auditor maps to a single result.
Preferences
What it checks
- Whether the PHP request handler can be crashed by a crafted
multipart/form-databody (the core of CVE-2026-109618 / CVE-2026-109619). - The advertised PHP version, as a fallback, when the probes produce no crash signal: a patched release passes, an unpatched one fails.
- It inspects only the audited page for a block (HTTP 403 / 429 / Cloudflare challenge); the probes are part of the audited request, not separate paths.
What it audits
Every row maps to onecheckRule* method and one CheckCode. CheckCode suffixes use status ranges: 100 information, 200–299 success, 300–399 warning, 400–499 fail, 500–599 error.
Output documentation
Risks and considerations
This probe can crash PHP workers
- The probes are the actual exploit payloads: on a vulnerable server they crash the PHP worker handling the request. Only run this against sites you own or are authorized to test — which is why it is gated on domain verification and is off for anonymous previews.
A clean result is not a guarantee
NO SIGNALmeans the probes did not crash the server and no PHP version was advertised. It is reported as a pass, but it is not proof of safety: confirm the running PHP version is at least the fixed release.INCONCLUSIVEmeans a WAF, proxy or server error stopped the scan from reaching a verdict. The server may still be exposed — re-run, or test the PHP origin directly.
Verify findings with a human
- This auditor wraps Assetnote’s php2shell-scanner and infers the verdict from the server’s responses, so a result can be wrong in either direction: a WAF, proxy or load balancer can absorb a crash and look like a pass, and an unrelated
5xxcan look like a crash. Before you act on aFAIL— or rely on aSUCCESS— have a person confirm it against the host (check the running PHP version and the server logs for the probe requests).
Why it matters
- The bug lets an unauthenticated request crash the PHP process, so a few requests can take a site down (denial of service).
- The memory corruption behind the crash raises the risk of worse outcomes than a crash, so patching promptly matters.