What is PHP2Shell?

01 What PHP2Shell is

PHP2Shell is a name used for two PHP vulnerabilities disclosed on October 21, 2026. The CVE identifiers distinguish the bugs; both concern how PHP handles memory and internal state across web requests. [1] [2]

CVE-2026-109618 · Out-of-memory corruption

An out-of-memory error can interrupt PHP while request data is only partly initialized. Cleanup code may then treat that unfinished data as valid. A crafted request can turn this unsafe error path into remote code execution. Apache mod_php has a demonstrated path that runs before application code starts. [3]

CVE-2026-109619 · Stale state between requests

A PHP worker can retain references to memory from an earlier request after that memory has been freed. A later request handled by the same worker can use those references before normal initialization resets them. Exploitation requires a suitable sequence of operations and depends on the configuration and affected state. [4]

02 Where exposure matters

These are runtime flaws beneath the website or application. A customer portal, public website or older internal service can depend on a vulnerable PHP build even when its application code is current. Updating a CMS or plugin alone does not establish that PHP is patched.

The confirmed code execution uses the web worker account’s privileges, not automatic root access. The potential damage depends on what that account can read, modify or reach. Review accessible application files, secrets and business data when assessing the consequences. [4]

Server integration matters. The advisories distinguish mod_php from PHP-FPM and other environments. A session lifecycle attack for the stale-state flaw was validated against mod_php and FPM, but the FPM path requires suitable application behavior. Do not treat a server choice alone as proof of safety. [4]

03 How to check your installation

Inventory the runtime actually serving each application:

• Identify the web runtime. Record the PHP branch, package revision, server integration, extensions and build options. A command-line PHP installation may differ from the one serving requests.
• Check vendor evidence. Look for a package advisory covering both CVEs. A vendor can backport fixes without changing the upstream version number.
• Check every deployment. Include separate application pools, containers and legacy sites, not just the primary website.

For upstream-supported branches, these were the first releases containing the October 21 fixes. Use the current supported release or your vendor’s fixed package rather than treating this table as a permanent latest-version list. [1]

PHP 8.1 and earlier are end of life upstream. The PHP security team nevertheless supplied minimal source backports for 7.4, 8.0 and 8.1. Evaluate those and any vendor fixes alongside CalCyber’s version-specific work. [1] [9]

04 What the source backports change

A backport adapts a fix to an older codebase. CalCyber’s work builds on upstream mitigations by Arnaud Le Blanc and Ilija Tovilo. For example, the PHP 7.4.33 backport carries the PHP project’s minimal, fail-stop mitigation into that version. [5] [6]

• Terminate the worker on relevant out-of-memory and overflow paths instead of continuing through unsafe cleanup.
• Clear request and executor state so references do not survive their request memory.
• Add overflow checks, reduce input-array allocations and limit multipart parts and headers.
• Disable session upload progress in this implementation.

Those details describe the PHP 7.4.33 backport, not every legacy branch. CalCyber’s older-version work also includes PHP 5.0.0 adaptations; exact-version differences need separate review and test evidence. [6] [7]

Expect operational tradeoffs. Worker termination can fail an in-flight request. Applications using upload progress need compatibility testing. Supported PHP releases use a different out-of-memory design: a soft failure at a safe execution point, plus termination at a higher hard limit. Do not assume the legacy backport behaves identically. [3]

05 How to use a backport responsibly

1. Prefer a supported update. Use a fixed upstream or vendor package when your application can take it.
2. Match the exact version. Select the corresponding source branch and pin a reviewed commit or release tag. Do not assume the default branch is your patched legacy version.
3. Build and test in staging. Exercise uploads, sessions, extensions, error handling and worker replacement. Keep a known working build and rollback plan.
4. Verify deployment. Restart or replace the relevant workers, confirm the web service uses the intended build, and monitor failed requests and availability.
5. Keep the migration plan. Record the patch and validation evidence, then continue moving the application to supported PHP.

Also check separate advisories. PHP’s October 23 notice describes CVE-2026-115560, involving unusual runtime changes to session serialization. PHP recommends disabling session upload progress until the next regular bugfix release for protection from that vector. Do not infer a backport’s coverage from its name. [8]

Review CalCyber’s free source backports

06 Common questions

Is this an automatic patching tool?

No. It is PHP source code. An administrator must select the correct version, build it, test it and deploy it.

Does a backport make end-of-life PHP fully supported?

No. It addresses a defined issue. Other PHP, extension and application vulnerabilities still require attention. [9]

Are all legacy branches validated?

Branch availability is not validation. Check the exact branch’s review, build and test evidence before using it in production.

Is the source free?

CalCyber’s source backports are available at no charge. Follow the applicable branch license notices; free source does not imply a maintenance or support guarantee.

07 References

1. PHP security announcement and source backport guidance
2. Plesk advisory identifying the PHP2Shell CVE pair
3. PHP advisory for CVE-2026-109618
4. PHP advisory for CVE-2026-109619
5. Upstream PHP 7.4 minimal mitigation
6. Version-specific PHP 7.4.33 backport
7. PHP 5.0.0 adaptation and upstream credits
8. PHP session upload progress notice from October 23
9. PHP supported-version policy