· Vulnerabilities · 4 min read
PHP2Shell: patch PHP before attackers do
PHP2Shell affects the PHP runtime, not just one CMS. Find every PHP deployment, patch the right build, review signals, and escalate safely.
PHP2Shell is a PHP runtime issue. It is not a WordPress-only, Drupal-only or Joomla-only problem. If your organization runs PHP directly, through a hosting provider, inside a container, or behind a managed business platform, confirm where it runs and whether it has been patched.
Do these four things first
- Inventory every PHP runtime. Check production, staging, containers, serverless functions, control panels, legacy microsites and externally managed business systems. Ask third-party providers for written confirmation of their PHP version, patch status, restart plan and log-retention window.
- Patch the PHP runtime and restart it. Updating a CMS or plugin does not update PHP underneath it. Patch Apache, PHP-FPM and long-running PHP workers, then verify the running version. Do not rely only on
php -v: the CLI version can differ from the PHP-FPM or container image serving production traffic. - Review logs for indicators of attack. Check edge, WAF, web-server, PHP-FPM and application logs around the exposure window.
- Escalate signals. If you find credible indicators, preserve relevant logs and start an investigation. Do not delete files or reboot first. If you do not have a threat-hunt or incident-response partner, call SB Software at +1 (438) 842-1370.
What is PHP2Shell?
PHP2Shell is the name given to two related vulnerabilities in core PHP: CVE-2026-109618 and CVE-2026-109619. They involve PHP request handling and can expose sensitive process memory or, on affected paths, permit unauthenticated code execution. The vulnerable component is PHP itself, so secure application code alone is not enough protection.
The research demonstrated impact against common PHP applications, including WordPress, Drupal and Joomla. The complete fix is a patched PHP runtime, not an application-only update or a temporary WAF rule.
Patch targets to verify
This table is a 22 October 2026 snapshot. Always validate against your distribution’s current security advisory before changing production.
| Platform | First safe version / package |
|---|---|
| Upstream PHP 8.2 | 8.2.35 or later |
| Upstream PHP 8.3 | 8.3.36 or later |
| Upstream PHP 8.4 | 8.4.27 or later |
| Upstream PHP 8.5 | 8.5.12 or later |
| Ubuntu 24.04 LTS (Noble) | php8.3 8.3.6-0ubuntu0.24.04.13 or later |
| Ubuntu 22.04 LTS (Jammy) | php8.1 8.1.2-1ubuntu2.28 or later |
| Debian 12 (Bookworm) | php8.2 8.2.35-1~deb12u1 or later |
| Debian 13 (Trixie) | php8.4 8.4.27-1~deb13u1 or later |
| Red Hat Enterprise Linux | Follow the current Red Hat advisory and apply the vendor package update. Red Hat backports fixes, so do not judge exposure from the upstream-looking version alone. |
The upstream releases come from the PHP2Shell response guidance and PHP downloads. Ubuntu package versions are in USN-8948-1; Debian lists fixed builds in its CVE tracker. For RHEL, use the Red Hat CVE record and your enabled repositories rather than forcing an upstream PHP build.
What to look for in network and application logs
No single detection proves or rules out exploitation. The PHP2Shell guidance highlights these investigation signals:
- Unexpectedly large or malformed
PHPSESSIDresponse cookies. - Unusual multipart requests followed by PHP memory-limit errors or repeated HTTP 500 responses.
- Unexplained PHP-FPM or PHP worker crashes and restarts.
Also look for resulting behavior: new or modified PHP files in web roots or upload directories, unexpected privileged-account changes, unfamiliar outbound connections, and web-server access from unusual source patterns. Preserve the original logs, timestamps and relevant files before cleanup. The absence of these signals is not proof that an exposed runtime was not targeted.
Why a patch does not have to mean taking every site down
A public-facing PHP service should be patched quickly, but a blanket shutdown is not the only responsible response. Security works in layers:
- Firewalls, WAFs and rate controls can reduce exposure while a patch is prepared.
- Patch management identifies the exact runtime and gets the fixed package deployed.
- Account tiering limits what a compromised web account can reach.
- Policies and change control prevent rushed, untracked production changes.
- Clear communication plans keep business owners, providers and technical teams aligned.
These controls do not replace the PHP update. They reduce the chance that one exposed service becomes an organization-wide incident, and they make a measured patch-and-validate response possible.
If you find something suspicious
Treat it as an investigation, not a cleanup task. Preserve evidence, scope affected systems, review authentication and administrative changes, check for persistence and rotate credentials or tokens when the evidence supports it. If there is active compromise, isolate the affected service in a controlled way and follow your incident-response plan.
Not sure whether every PHP runtime is current? Email info@sbsoftware.ca. If you believe an incident is active, call +1 (438) 842-1370. We would be glad to help with exposure review, threat hunting or incident response.