PHP2Shell (CVE-2026-109618, CVE-2026-109619): What to Patch Now and How to Upgrade Old PHP

On October 20, 2026, the PHP security team warned of two critical vulnerabilities, each rated 9.2 of 10 on the CVSS v4.0 scale. Emergency patches released on October 21 address CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Together, these PHP RCE vulnerabilities can allow unauthenticated attackers to execute code remotely on servers processing PHP web requests.

Successful exploitation could expose sensitive business data, compromise servers, and disrupt web applications. Organizations running PHP-based systems should check their installed versions and apply available security updates immediately.

Act Now

1. Running PHP 8.2–8.5? Update to the fixed version of your branch immediately: 8.2.35, 8.3.36, 8.4.27, or 8.5.12.
2. Running PHP 5.x–8.1? These branches no longer receive official PHP releases. Restrict exposure, check for available vendor patches, and plan a migration to PHP 8.4 or 8.3. PHP 8.2 is not a practical long-term target, as its security support ends on December 31, 2026.
3. Can’t patch today? Limit internet access and apply temporary protections, including WAF rules. These measures cannot replace patching.

Current status. Exploitation attempts have been reported. Amazon Threat Intelligence detected an attempt on October 17, 2026, four days before the patches were released. Cloudflare also observed attacks, including attempts to bypass its WAF protections.

The UK’s National Cyber Security Centre advises organizations to consider taking vulnerable systems offline if they cannot apply patches or temporary mitigations promptly. Prioritize internet-facing PHP installations and investigate suspicious activity dating back to October 17.

What Is PHP2Shell and Why Is It Dangerous?

PHP2Shell is the name for two critical PHP vulnerabilities, both remote code execution (RCE) flaws in the PHP runtime: CVE-2026-109618 and CVE-2026-109619. Both affect how PHP manages memory while processing web requests.

CVE-2026-109618 involves memory corruption when PHP runs out of memory during request processing and cleanup. CVE-2026-109619 occurs when a PHP worker reuses an outdated internal state from a previous request.

According to the PHP security advisory released on October 21, these flaws can allow attackers to execute code on vulnerable servers without authentication. In some configurations, exploitation can occur before the application’s own code runs, bypassing application-level security checks.

This puts websites, e-commerce platforms, and other PHP-based systems at risk, even when their application code follows secure coding practices. Since both vulnerabilities exist in the PHP runtime itself, reviewing application code alone cannot eliminate the threat. Updating PHP to a patched version is necessary.

PHP Security Update: Which Versions Are Affected and Patched?

According to Sansec, PHP2Shell affects all PHP versions from 5.4, including branches that no longer receive fixes. According to the official PHP security advisory, security updates for PHP 8.2, 8.3, 8.4, and 8.5 were released on October 21, 2026.

The table below shows the fixed versions and their security support deadlines, as listed in PHP’s official support schedule.

PHP2Shell fixed versions and official security support deadlines

Organizations using Debian, Ubuntu, RHEL, or managed hosting should check whether their providers offer backported security patches. These fixes may retain an older PHP version number, so package release notes and security advisories are more reliable than version numbers alone.

PHP 8.2 security support ends on December 31, 2026, just two months after the PHP2Shell disclosure. Updating an existing PHP 8.2 installation to 8.2.35 is necessary to address the vulnerabilities. However, businesses planning a migration from an older PHP version should target PHP 8.4, supported until December 2028, or PHP 8.3, supported until December 2027.

How to Respond to PHP2Shell in the First 24 Hours

Organizations should act quickly to identify vulnerable PHP installations, apply security updates, and reduce the risk of attacks. The following steps can help IT teams prioritize their response.

1. Identify Every PHP Installation

Check production and staging servers, internal applications, Docker containers, CMS platforms, and third-party software. Run php -v to check the command-line version, but remember that websites may use a different PHP version.

2. Prioritize Publicly Accessible Systems

Start with websites, customer portals, and other applications exposed to the internet. Then review internal systems based on their importance and potential exposure.

3. Install the PHP Patch

Update PHP to a fixed version or apply a verified vendor patch. Check PHP-FPM, web server modules, and Docker images. Updating the host server alone does not update PHP inside containers.

4. Restrict Access if Patching Is Delayed

Use VPN access, IP allowlists, or available WAF protections. Temporarily restrict unnecessary file uploads or take vulnerable services offline if needed. These measures only reduce exposure.

5. Don’t Rely on PHP Configuration Changes

The official PHP security advisory recommends temporary measures, including session.upload_progress.enabled=0, memory_limit=-1, and, for PHP 8.5, fatal_error_backtraces=0.

Disabling PHP’s memory limit requires separate server-level memory controls, while changes to session and backtrace settings require restarting PHP workers. These measures only reduce specific attack risks. Installing security patches remains the only complete fix.

6. Look for Signs of Compromise

Look for unusual PHP processes, unexpected files, webshells, new scheduled tasks, unknown administrator accounts, and suspicious activity in server logs. Preserve the logs for further investigation. Sansec also reports that one of the flaws can expose server memory, so after patching, consider rotating credentials, session tokens, and API keys on internet-facing servers.

7. Avoid Untrusted Exploit Scripts

Don’t run unknown public proof-of-concept tools on production servers. Verify patch status through official security advisories and trusted vendor documentation instead.

After patching, test critical application functions, including logins, payments, integrations, and data processing. Monitor errors and server activity to confirm that business operations continue normally.

Running Unsupported PHP (5.x–8.1)? Why Is It Harder to Secure?

For businesses running older PHP applications, fixing PHP2Shell can be more complicated than installing a security update. These applications often depend on outdated software that may not work with newer PHP versions. As a result, upgrading can introduce compatibility issues and disrupt business operations.

Four common challenges make legacy PHP applications harder to secure:

1. Unsupported PHP Versions. PHP 5.x through 8.1 no longer receive official PHP releases. The PHP security team published minimal source backports for 7.4, 8.0, and 8.1, and some Linux distributions and commercial support providers may offer patched packages. These are temporary measures, so businesses should restrict exposure and plan a migration to a supported PHP version.
2. Outdated Frameworks and Libraries. Older versions of frameworks, CMS platforms, and third-party Composer packages may not support modern PHP releases. These dependencies often need to be updated alongside PHP.
3. Business-Critical Integrations. Legacy applications may connect to payment gateways, CRM and ERP systems, databases, and external APIs. An upgrade can affect these connections and interrupt daily operations.
4. Limited Test Coverage. Older systems often lack automated tests, making it difficult to identify compatibility problems before an update reaches production.

These challenges make PHP migration a separate development task that requires planning beyond an emergency security patch. Businesses should address immediate exposure first, then assess what needs to change before moving their applications to a supported PHP version.

How to Upgrade PHP Without Breaking Your Application

Upgrading a legacy PHP application requires careful planning, especially when it supports important business operations. A structured process helps identify compatibility problems, reduce downtime, and keep the application working after the update.

Audit the Codebase and Dependencies

Start by reviewing the application’s code, frameworks, libraries, and PHP extensions. Tools such as PHPCompatibility and PHPStan can help identify code that may cause problems with newer PHP versions. Run composer outdated to find dependencies that need updating. Check whether your Laravel, Symfony, WordPress, or Magento version supports the target PHP release. List components that require manual changes.

Automate Compatible Code Changes

Rector can automate certain PHP code changes, including changes to outdated syntax and deprecated features. This can reduce repetitive work, especially in large codebases. However, automated tools cannot reliably fix every compatibility issue. Developers should review the changes, check for differences in PHP behavior, and manually update code that depends on older libraries or application-specific logic.

Plan a Controlled Upgrade Path

Aim for PHP 8.4, or PHP 8.3 if compatibility requirements prevent an upgrade to 8.4. Large legacy applications may need several stages of code changes before they can run on a supported version. Test compatibility in an isolated staging environment and avoid deploying unsupported PHP versions to production. PHP 8.2 may serve as a temporary migration step, but it must be patched to 8.2.35 or later within that branch.

Test Application Behavior Before Deployment

Run unit, integration, and regression tests to identify problems introduced by the upgrade. Pay particular attention to logins, payments, database operations, and external integrations. For applications handling high traffic, include performance testing. Create backups and prepare a rollback plan before deployment so the team can restore service if serious issues appear.

Deploy With Minimal Downtime

Use blue-green or canary deployment when the application’s architecture supports these approaches. Gradually move traffic to the updated environment and monitor error rates, server performance, and application logs. After deployment, verify that critical business functions work as expected. Keep the previous environment available for rollback until the updated application is stable.

How Can Businesses Prevent the Next PHP Security Emergency?

PHP2Shell shows why regular security maintenance matters for PHP applications. Businesses can reduce future risks by keeping their software up to date and preparing for security issues before they become urgent.

Here are five steps to consider:

1. Maintain a PHP Version Inventory. Keep a record of PHP versions running across servers, applications, and Docker containers. Update this list whenever software or infrastructure changes.
2. Plan Upgrades Before End of Life. Check PHP’s official support schedule regularly. Upgrade frameworks, libraries, and other dependencies before their versions lose security support.
3. Automate Security Checks. Add dependency scanning and container image checks to CI/CD pipelines. Monitor security advisories to identify vulnerabilities that may affect your applications.
4. Schedule Regular Maintenance. Set aside time to install security updates, test application compatibility, and review outdated components. Regular updates help prevent the accumulation of technical debt.
5. Prepare an Incident Response Plan. Assign responsibilities, document patching procedures, and define how to check for security breaches. Include steps for testing updates and restoring services if problems occur.

Keeping track of PHP support deadlines and security advisories gives businesses more time to plan upgrades before critical vulnerabilities put their applications at risk.

How SCAND Helps Secure and Modernize PHP Applications

SCAND has over 25 years of software development experience, a team of 250+ engineers and 900+ completed projects. Our processes are certified under ISO 9001 and ISO 27001. SCAND provides PHP development services using Laravel and other web technologies. Our projects include an automated legal contract generation system and a medical courier management platform, both of which illustrate our experience with business applications that rely on multiple components and integrations.

If you are dealing with PHP2Shell or an outdated PHP application, we can help in three ways:

• Emergency patch and exposure check. We inventory PHP installations, including containers and vendor software, apply patches, set up temporary WAF protection, and check for signs of compromise with our DevOps engineers.
• PHP migration services. We audit compatibility, update dependencies, and move the application to PHP 8.3 or 8.4 as part of legacy application modernization, with software testing before the switch.
• Ongoing support. We monitor PHP and framework advisories, install updates, and plan upgrades before a version reaches end of life.

If your team needs extra capacity for a migration, you can hire PHP developers from SCAND.

Frequently Asked Questions (FAQs)

What is PHP2Shell?

PHP2Shell is the name given to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow attackers to execute code remotely without authentication. Both involve memory handling problems in the PHP runtime. Successful exploitation could compromise a server, expose sensitive data, or disrupt websites and business applications.

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

The PHP development team released fixes on October 21, 2026. The patched versions are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Organizations should update to the appropriate version for their PHP branch. Those using Linux distribution packages should also check for vendor-provided security updates.

Is PHP 7.4 or 8.1 affected, and will it be patched?

Yes. All PHP versions from 5.4 are affected (according to Sansec), and PHP 7.4 and 8.1 will not get official releases. The PHP security team published minimal backports for source builds, and some Linux distributions and vendors offer patched packages. Plan an upgrade.

Can a WAF or php.ini change protect my site?

A web application firewall (WAF) can help block certain malicious requests, while some php.ini settings may reduce exposure to specific attack methods. However, neither provides complete protection against PHP2Shell. The PHP security team recommends installing the available patches. Until then, businesses should restrict access to vulnerable applications wherever possible.

Should I upgrade to PHP 8.2, 8.3, or 8.4?

For a new migration, PHP 8.4 is the preferred choice, with security support until December 2028. PHP 8.3 is an alternative if your application is not yet compatible with 8.4. PHP 8.2 reaches end of life in December 2026, so use it only as a temporary migration step, with the latest security patches installed.