PHP2Shell Explained: Patch the Critical PHP RCE Flaws Now
Two critical vulnerabilities in the PHP runtime can allow an unauthenticated attacker to execute code on an affected server. The issues are being called PHP2Shell and are tracked as CVE-2026-109618 and CVE-2026-109619.
This is not a WordPress plugin bug and it is not fixed by updating WordPress, Laravel, Drupal, Joomla, or Magento. The vulnerable component is PHP itself. If a public website or API processes requests with PHP, verify the runtime and patch it now.
Update every web-facing PHP runtime to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or install a vendor package that explicitly backports the two fixes. Restart the affected workers and verify the version inside the running web environment—not only in your terminal.
PHP2Shell in one minute
The official PHP advisory describes two related memory-safety vulnerabilities:
| Vulnerability | What goes wrong | Potential impact |
|---|---|---|
| CVE-2026-109618 | Out-of-memory handling can interrupt PHP while request data is only partially initialized. Cleanup can then treat invalid data as legitimate. | Memory corruption, memory disclosure, and remote code execution |
| CVE-2026-109619 | Request-owned global state can remain after its backing memory is freed. A later request handled by the same worker can reuse that stale state. | Use-after-free, worker crashes, memory disclosure, and remote code execution |
Both vulnerabilities received a CVSS v4 score of 9.2. PHP lists all
web-serving setups as at risk, including PHP-FPM, Apache with mod_php,
php-cgi, FrankenPHP, and LiteSpeed. The project considers mod_php the
highest-risk configuration because researchers demonstrated an attack before
application code runs.
These are runtime flaws. A well-maintained application can still be exposed if it runs on an affected PHP interpreter.
Who found the vulnerabilities?
The accurate answer is that this was a multi-year, coordinated effort—not a single researcher finding one simple bug.
The PHP Foundation's account says the first signs of the out-of-memory problem appeared while the PHP team was remediating findings from a 2024 external audit performed by Quarkslab. A possible exploit was theorized, but the team did not yet have a concrete route to remote code execution. Designing a compatible fix for central PHP memory and error-handling behavior proved difficult, and the work stalled.
The investigation accelerated in 2026:
- The PHP Foundation joined OpenAI's Patch the Planet initiative, and security firm Calif began a PHP audit on July 30, 2026.
- On August 11, Calif researcher Ryan A reported unconditional remote code execution sharing the previously identified out-of-memory root cause. OpenAI independently reported the same root cause that day.
- Wiz reported additional attack paths on August 24 and independently identified both disclosed vulnerabilities.
- OpenAI reported further attack vectors on September 18.
- PHP maintainers led remediation and release work, supported by Calif, OpenAI, Wiz, Cloudflare, hosting and infrastructure companies, government partners, and other security teams.
- PHP published the fixed releases on October 21, 2026.
OpenAI says Calif used GPT-5.6 Sol during its audit. Wiz Research says frontier models also helped its researchers inspect complex engine behavior, develop cross-platform proofs, validate patches, and create detection logic. The important lesson is not that an AI system found a bug alone. Expert researchers, PHP maintainers, infrastructure providers, and security tools worked together to turn findings into tested patches.
How were the bugs identified?
At a high level, researchers focused on how PHP recovers from fatal errors during request processing—especially out-of-memory failures.
PHP workers are optimized to handle many requests. Internal structures are created, reused, and cleaned up at precise points. If a fatal error interrupts that lifecycle, a partially initialized object or pointer to released memory must never survive into cleanup or a later request.
Researchers combined several defensive techniques:
- source-code review of memory and request lifecycle paths;
- sanitizer builds that expose unsafe memory access;
- reproduction environments matching PHP's supported platforms;
- repeated failure injection around memory limits and fatal errors;
- testing against real deployment modes such as
mod_phpand PHP-FPM; - patch validation and searches for related variants.
Wiz demonstrated unauthenticated remote code execution against representative WordPress, Drupal, and Joomla deployments. That does not mean those CMSs introduced the flaw. They were realistic targets used to prove the impact of vulnerable PHP behavior.
We intentionally do not reproduce exploit chains here. Public defenders have enough information to identify and patch affected runtimes without giving an operational recipe for attacking them.
Is WordPress affected by PHP2Shell?
Yes, a WordPress site can be exposed when its server uses a vulnerable PHP runtime. But this is not a WordPress core, plugin, or theme vulnerability.
WordPress.org's security notice is explicit: no WordPress update is required or planned for these issues. The fix is to update PHP on the host.
To check the PHP version used by WordPress:
- Open Tools → Site Health in WordPress Admin.
- Select Info.
- Expand Server and find PHP version.
- Compare it with the fixed releases listed below.
Your hosting control panel may also display the version. If you use managed WordPress, ask the provider to confirm—preferably in writing—that the runtime serving your site includes both CVE fixes. A generic statement that "security updates are automatic" is less useful than a package version or advisory.
What about Laravel, Symfony, Drupal, Joomla, and Magento?
They can all be affected indirectly because they run on PHP.
Updating Composer dependencies is good maintenance, but it does not replace a PHP runtime update. The same rule applies to:
- Laravel and Symfony applications;
- WordPress, Drupal, Joomla, and Magento sites;
- WooCommerce stores;
- custom PHP APIs and admin panels;
- PHP applications bundled into containers or appliances;
- background workers that also accept or process untrusted input.
The vulnerable paths live below the framework. Security middleware, authentication, and application-level validation may not stop an attack that occurs before normal application code or across reused worker state.
Which PHP versions are fixed?
The PHP project released these patched versions on October 21:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
PHP 8.1 and older no longer receive security releases from the PHP project. Some Linux distributions and long-term-support vendors backport fixes while keeping an older-looking version number. In that case, do not judge the package by the upstream version alone: check the distributor's security advisory and package changelog for both CVE-2026-109618 and CVE-2026-109619.
Because of the severity, PHP also published minimal source backports for PHP 7.4, 8.0, and 8.1. Those backports help specialized vendors and teams building from source; they do not turn unsupported branches into generally supported platforms. Moving to a supported PHP release remains the safer plan.
The 15-minute remediation plan
1. Inventory every PHP runtime
Start with:
php -v
php --ini
Do not stop there. The CLI can use a different binary and configuration from the web server. Check PHP-FPM pools, Apache modules, containers, serverless images, staging systems, cron workers, and old subdomains.
For WordPress, use Site Health. For containers, run the version check inside the deployed image:
docker exec <container-name> php -v
2. Install a package containing both fixes
Use the update mechanism supported by your operating system, hosting provider, container image, or PHP vendor. Typical starting commands are:
# Debian or Ubuntu
sudo apt update
sudo apt upgrade
# RHEL, Rocky Linux, AlmaLinux, or Fedora
sudo dnf upgrade
These commands are examples, not proof that a fixed package exists in every configured repository. Read the vendor advisory and verify the installed package afterward.
For Docker, rebuild from an explicitly patched base image, deploy the new image, and confirm that old containers have actually stopped. Merely changing the Dockerfile does not update running workloads.
3. Restart long-running workers
After updating, restart PHP-FPM, Apache, container workloads, and any long-lived PHP worker. This ensures the patched binary is loaded and removes old worker state.
4. Verify from the serving environment
Record evidence for each application:
- hostname and application owner;
- SAPI (
fpm-fcgi,apache2handler, and so on); - PHP or vendor package version;
- deployment and restart time;
- link to the vendor advisory confirming both CVEs;
- result of a basic application health check.
Avoid leaving a public phpinfo() page behind. It exposes unnecessary server
details.
5. Review for suspicious activity
Patching closes the known vulnerability; it does not prove that an exposed server was never attacked. Wiz recommends looking for signals such as:
- unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses;
- unexpectedly large or malformed
PHPSESSIDresponse cookies; - unexplained PHP worker crashes, restarts, or churn;
- child processes or outbound connections that do not match the application;
- modified PHP files, new scheduled tasks, web shells, or newly created admin users.
Because the bugs occur inside the runtime, application logs may contain little context. Correlate reverse-proxy, WAF, system, container, and process telemetry.
If you find credible signs of compromise, preserve evidence and use an incident response process. Rebuild from a trusted image, rotate application secrets, database credentials, API keys, session-signing keys, and administrative passwords as appropriate. Do not assume that deleting one suspicious file fully removes persistence.
What if you cannot patch immediately?
Only a patched runtime is a complete remediation. PHP's advisory lists temporary measures that can reduce specific attack paths, including:
- enforcing
memory_limit=-1at an administrative level applications cannot override; - setting conservative
post_max_sizeandupload_max_filesizevalues; - limiting decoded request size, multipart parts, headers, fields, and nesting at the proxy or web server;
- setting
session.upload_progress.enabled=0and restarting workers; - disabling
fatal_error_backtraceson PHP 8.5; - using strong container or cgroup memory boundaries.
Each mitigation has operational trade-offs and none makes an affected runtime safe. Follow the exact PHP project guidance, test changes against upload and session workflows, and schedule the real update immediately.
A WAF can add protection and buy time, but it cannot reliably model every runtime state or future exploit variation. Treat it as defense in depth, not as a substitute for patching.
What should worry you—and what should not?
Prioritize these situations
- An internet-facing site runs a vulnerable or unknown PHP build.
- PHP is embedded in an appliance or container that has not been rebuilt.
- The server uses Apache
mod_php. - You rely on an unsupported PHP branch without a confirmed vendor backport.
- Several customers share long-running PHP workers or secrets on the same system.
- Logs show repeated memory errors, malformed sessions, or unexplained worker crashes.
- Nobody can identify who owns the PHP runtime update.
Do not draw these conclusions
- "WordPress must release a patch." The fix belongs in PHP.
- "Updating every plugin solves it." Plugin updates do not replace the runtime fix.
- "Cloudflare or a WAF makes us safe." It reduces exposure but does not provide complete remediation.
- "Every PHP site has already been hacked." Serious exposure is not proof of compromise. Patch first, then investigate based on evidence.
- "Our static site is vulnerable because PHP exists elsewhere in the company." A static deployment that does not execute PHP is not directly affected, although any separate PHP APIs or admin tools still require review.
- "The terminal shows a fixed version, so production is fixed." The web SAPI may load a different binary, container, or package.
A checklist for owners and agencies
- Identify every web-facing and background PHP runtime.
- Confirm a fixed upstream release or explicit vendor backport for both CVEs.
- Rebuild containers and restart all long-lived workers.
- Verify the version from the environment serving traffic.
- Run application smoke tests after the update.
- Review proxy, WAF, worker, and system logs for warning signs.
- Escalate credible compromise indicators to incident response.
- Remove temporary mitigations only after the patch is verified.
- Document the result for customers and application owners.
If you need help inventorying a legacy PHP estate, validating an upgrade, or checking a WordPress deployment, contact the Dopebase team. For larger remediation, modernization, or recovery work, see our custom app development and engineering support.
Frequently asked questions
Does updating WordPress fix PHP2Shell?
No. WordPress says no WordPress core update is required or planned for these issues. Update the PHP runtime used by the web server.
Is my WordPress site vulnerable?
It may be exposed if its server runs an affected PHP build. Check Tools → Site Health → Info → Server, then confirm the package with your host. A current WordPress version alone does not answer the PHP question.
Does updating Laravel or Composer fix it?
No. Keep application dependencies current, but PHP2Shell is in the PHP engine. The runtime or vendor package must contain the fixes.
Are PHP 7.4, 8.0, and 8.1 safe after applying a backport?
A correctly applied vendor or source backport can address these two CVEs, but those branches remain unsupported by the PHP project and may have other risks. Upgrade to a supported PHP branch as soon as practical.
Can I rely on a WAF rule?
No. WAF rules and request limits are useful layers, especially during an emergency rollout, but PHP states that only updating is a complete solution.
How do I know whether the server was compromised?
There is no single definitive log entry. Review request anomalies, PHP worker failures, process activity, filesystem changes, new users, scheduled tasks, and outbound connections. If the system was exposed and shows credible indicators, use a formal incident response process and rotate secrets from a trusted environment.