PHP2Shell: What Happened to PHP and How to Secure Your Website

Last updated: October 22, 2026.

On October 21, 2026, the PHP team released emergency security fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively referred to as PHP2Shell. Under specific circumstances, they may allow remote code execution without authentication. The flaws affect the PHP runtime itself, not just WordPress, Symfony or Laravel. Official patches are available, but that does not mean every server has installed them.

What is PHP2Shell?

PHP powers server-side operations for websites, online stores and business applications. With PHP2Shell, specially crafted HTTP requests can trigger unsafe memory states. In a successful exploit, an attacker may execute code with the privileges of the compromised PHP process, potentially accessing files, configuration secrets and databases available to that process. Not every website is exploitable in the same way: the PHP version, execution mode and configuration all matter.

The technical details of the two vulnerabilities

CVE-2026-109618: an out-of-memory handling flaw

Under specific out-of-memory conditions, PHP can interrupt execution before internal structures have been initialized correctly. Subsequent processing of those structures can cause a dangerous memory error. A particularly serious documented scenario affects Apache mod_php and can be triggered before application PHP code starts executing. As a result, even a properly secured Symfony controller cannot fix a vulnerability in the underlying runtime.

CVE-2026-109619: use-after-free

The second vulnerability involves a reference to memory that has already been freed. PHP workers may process multiple requests in succession, and certain error conditions can leave invalid internal state for a subsequent request. This class of bug is called use-after-free (UAF). The precise prerequisites are detailed in the official CVE-2026-109618 advisory and CVE-2026-109619 advisory.

Timeline: how the incident unfolded

Cloudflare reported observing malicious requests. Observed attack traffic does not prove that every attempt succeeded. There is no reliable public global count of compromised servers.

Which PHP versions have been patched?

Important: Linux distributions may backport a security fix while retaining an older PHP version number. Verify the full package release and security changelog rather than relying solely on php -v.

How did hosting and security vendors respond?

Cloudflare

Cloudflare introduced WAF rules and an additional mechanism called Full Transaction Detection, which analyzes requests and responses. This provides a useful temporary layer of protection, but it does not fix PHP and may not cover every exploit variant. Make sure attackers cannot bypass Cloudflare by connecting directly to your origin server. Read Cloudflare's analysis.

Ubuntu

Canonical published USN-8948-1 with security fixes for supported Ubuntu releases, including a PHP 8.1 backport for Ubuntu 22.04. With these distribution-maintained packages, it may be possible to address the specific CVEs without immediately migrating an application to a new major PHP branch.

cPanel, CloudLinux and legacy PHP versions

cPanel released EasyApache4 fixes, including packages for PHP 7.4, 8.0 and 8.1. CloudLinux/TuxCare also provided vendor-specific packages for certain legacy environments. This does not mean that any arbitrary PHP 7.x installation is safe: the exact vendor package and revision must be verified. See cPanel's official notice.

Shared hosting, VPS and Docker

On managed shared hosting, the provider usually maintains the PHP runtime. On a self-managed VPS or cloud virtual machine, the customer is often responsible. Docker environments require an updated PHP base image and a new deployment: patching the host operating system does not automatically update PHP inside the container.

Are Symfony, Laravel and WordPress applications protected?

Not automatically. An up-to-date framework does not repair a vulnerability in the PHP runtime. Operating systems, PHP, web servers, framework dependencies and application code all need their own security maintenance. Updating a CMS plugin is not a substitute for patching PHP2Shell.

Temporary mitigations and their limitations

The official advisories discuss restrictions on HTTP POST and multipart requests, disabling session.upload_progress.enabled for certain scenarios, isolating PHP processes and limiting worker reuse. Under specific conditions, memory_limit=-1 is also discussed, but this can create a serious risk of uncontrolled memory consumption and must not be applied as a universal recommendation. Setting pm.max_requests=1 can significantly reduce performance. Blocking all multipart requests may break legitimate file uploads and forms. None of these measures replaces an official security patch.

Practical checklist for technical teams

1. Inventory production applications. Record domains, PHP versions, operating systems, hosting vendors and responsible administrators.
2. Check the actual runtime. php -v is only a starting point: inspect PHP-FPM or mod_php separately. On Ubuntu/Debian, review dpkg -l 'php*' and package changelogs.
3. Verify patch status. Compare the installed upstream version or vendor backport against the official advisory. Confirm installation, not just availability in a package repository.
4. Prepare backups and staging tests. Establish a rollback plan and test compatibility wherever possible.
5. Apply the security update. For standard Ubuntu/Debian installations, appropriate system upgrades typically include sudo apt update and sudo apt upgrade. Follow vendor guidance for custom repositories.
6. Restart PHP workers. Verify Nginx or Apache actually serves requests through the patched runtime.
7. Test business-critical operations. Check logins, sessions, shopping carts, checkout, payments, uploads, APIs, CRM/ERP integrations, cron jobs and queues.
8. Investigate possible compromise. Review HTTP, WAF, PHP and operating system logs. Patching does not automatically remove malicious code that may already be present.
9. Establish ongoing maintenance. Maintain an asset inventory, security advisory monitoring, backups and an owner for each system.

PHP2Shell explained in plain English: questions and answers

Does this affect a simple company website?

Potentially, yes, if it runs on a vulnerable PHP runtime. An online store is not required for the issue to matter.

Can someone attack the site without knowing a password?

Under specific conditions, yes. The possibility of unauthenticated code execution is what makes these vulnerabilities critical.

Is Cloudflare sufficient protection?

No. A WAF adds protection against known techniques, but does not replace the PHP patch.

Will upgrading WordPress or Symfony fix the problem?

No. PHP is a separate runtime component and must be patched independently.

Who is responsible on shared hosting?

Usually the hosting provider. Request written confirmation that both CVEs have been addressed in your specific environment.

Do I have to migrate straight to PHP 8.5?

Not necessarily. If your maintained PHP branch or vendor package has an official fix, you may apply that security update first. Plan and test a major-version migration separately.

Does patching prove that nobody compromised my site previously?

No. The patch addresses the known vulnerability going forward. Suspected past intrusions require a separate investigation of logs, files, accounts and processes.

What should I do if I do not have an IT team?

Ask your hosting provider whether CVE-2026-109618 and CVE-2026-109619 have been fixed for your account. For a self-managed VPS, contact an experienced system administrator.

Conclusion

PHP2Shell demonstrates that website security depends on infrastructure as well as application code. As of October 22, 2026, security fixes are available, but only a check of your actual production environment can confirm they have been installed.

Need help checking or updating PHP?

Sirius Software develops and maintains PHP/Symfony applications, online shops, CRM/ERP systems and integrations. We can help assess PHP versions and exposure, verify patches, update runtimes, migrate legacy applications and test systems after deployment.

Send us your website address, PHP version (if known) and hosting information. We can discuss the required technical checks and next steps. Contact Sirius Software.

Official sources

• PHP security releases
• PHP advisory for CVE-2026-109618
• PHP advisory for CVE-2026-109619
• Cloudflare analysis
• Ubuntu security notice
• cPanel security announcement