Skip to main content
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.
The php2shell auditor runs the 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

  1. 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).
  2. Probes — sends up to three crafted multipart bodies designed to trip the parser, stopping early as soon as it has a verdict.
  3. Crash detection — looks for an in-band PHP fatal error, an empty 500/200 body where the control produced output, or a 502/503/504 from the server fronting PHP-FPM.
  4. Version fallback — when no crash is observed, reads the X-Powered-By banner and compares it with the fixed releases.
  5. Verdict — the scanner returns one verdict (VULNERABLE, FIXED, NO SIGNAL, INCONCLUSIVE or ERROR), 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-data body (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 one checkRule* 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 SIGNAL means 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.
  • INCONCLUSIVE means 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 5xx can look like a crash. Before you act on a FAIL — or rely on a SUCCESS — 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.