TL;DR: PHP shipped emergency fixes for two critical PHP2Shell vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2, because unauthenticated remote exploitation can occur in the interpreter before application code runs, according to Pentera. Patch timing, worker restarts, and runtime verification now matter more than whether the application itself is up to date.
Editorial analysis by NHI Mgmt Group, based on content published by Pentera: “PHP2Shell: the expiry date on “too hard to exploit””.
By the numbers:
- PHP2Shell includes two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both scored CVSS v4.0 9.2.
Key questions
Q: What breaks when teams rely on CMS patching but leave the PHP runtime exposed?
A: The assumption that application-layer hardening is enough breaks down.
Q: Why does a runtime patch not always mean the service is safe?
A: Because the running worker may still be using the old binary after the package update.
Q: What signs suggest interpreter-level exposure is still present after patching?
A: If the version on disk differs from the version actively serving traffic, the exposure remains.
Practitioner guidance
- Patch the interpreter to a fixed release Move PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or use your distribution’s backport if you are on an older supported branch.
- Restart every runtime worker after upgrading Restart Apache, PHP-FPM and any long-running workers, then confirm the version actually executing requests rather than the package version stored on disk.
- Treat older unsupported PHP branches as exposed Assume 8.1 and older remain exposed unless you have a verified backport, and check bundled runtimes inside containers, appliances and control panels.
Bottom line: PHP2Shell matters because the vulnerable layer is the interpreter itself, so patched applications can still remain exposed if the runtime is old or unrestarted.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →