PHP2Shell and CodeIgniter or CakePHP Apps

As of 23 October 2026, PHP has fixed both PHP2Shell flaws in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Neither the CodeIgniter nor the CakePHP project had published a PHP2Shell statement that we could find as of that date. Exploitation attempts are widely reported, but confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog.

The direct answer: PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a flaw in the PHP engine, so every CodeIgniter or CakePHP app on an unpatched PHP build is exposed. Neither framework was named by the research teams, but that means it wasn't tested in public, not that it is safe. The fix is a patched PHP build on the server and a restart of every PHP process. Updating the framework doesn't change it.

The bigger risk with these two frameworks is age. Many CodeIgniter 3 and older CakePHP apps were built years ago, still work, and sit on PHP versions the PHP project no longer supports. This guide covers PHP support for each framework version, what to do with legacy apps, and how to patch and verify. For background, read what PHP2Shell is.

Are CodeIgniter and CakePHP Apps Affected?

Yes, through PHP. PHP describes CVE-2026-109618 as out-of-memory handling that "can interrupt PHP while internal request data is only partially initialized," and CVE-2026-109619 as internal state that "can survive after its backing memory has been freed" and be reused by a later request on the same worker. On the most exposed setup, Apache with mod_php, PHP's advisory says the first flaw "happens entirely before any application-specific code begins execution." Your framework never gets a chance to filter the request.

Calif and Wiz, the research teams PHP credits, published lists of apps they attacked successfully. Calif's list includes Laravel and Symfony but not CodeIgniter or CakePHP, and Wiz demonstrated only WordPress, Drupal and Joomla. The Dutch National Cyber Security Centre (NCSC-NL), which tracks affected software, lists "CodeIgniter 4 framework" and CakePHP as Vulnerable. Those entries are a general judgment that anything served by an affected PHP runtime is exposed, not a test result. Either way, the answer is the same: patch PHP.

What the Projects Have Said

We checked both projects' news channels on 23 October 2026:

• CodeIgniter: the forum's News and Discussion board had no PHP2Shell thread. The newest release, CodeIgniter 4.7.5, came out on 9 October, before the PHP release.
• CakePHP: the Bakery, CakePHP's official blog, had no PHP2Shell post. Its newest release, 5.4.3, came out on 3 October.

No statement is expected, since there is nothing for either project to patch. If one appears later, follow it. Other PHP app vendors that did publish, such as TYPO3, Matomo and PrestaShop, all said the same thing: the fix is in PHP, not in the app.

CodeIgniter PHP Requirements

The CodeIgniter 4 requirements page says "PHP version 8.2 or newer is required" and "we only maintain the latest version." It also lists the minimum CodeIgniter release for each PHP branch:

The same page warns: "If you are still using a PHP version below 8.2, you should upgrade immediately. The end of life date for PHP 8.2 will be December 31, 2026."

CodeIgniter 3 is a different story. Its user guide says "PHP version 5.6 or newer is recommended. It should work on 5.3.7 as well, but we strongly advise you NOT to run such old versions of PHP." So a CodeIgniter 3 app may still be running on PHP 5.6, 7.x or 8.0, none of which get releases from the PHP project.

CakePHP PHP Requirements and Support

CakePHP's project wiki (edited 16 October 2026) gives the PHP range and security support for each branch:

The CakePHP 5 installation guide lists PHP 8.2 as the minimum, with 8.5 supported. It adds a line that matters for verification: "Your web server's PHP version must match your CLI PHP version." The wiki also notes that CakePHP "is maintained by volunteers" and that it can't promise security backports for end-of-life versions.

Legacy Apps on Old PHP: Your Options

An app that can only run on PHP 8.1 or older has no official PHP2Shell release to install. PHP says "PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes." It also published minimal source-only backports for 7.4, 8.0 and 8.1 for people who build PHP themselves. You have four realistic paths, often in combination:

1. Get a backported PHP build. Your Linux distribution or hosting control panel may ship a fixed package for your old branch. A backported package usually keeps its old version number, so confirm the fix in the package changelog, not with php -v.
2. Move to a supported PHP if the app allows it. CakePHP 4.6 runs on PHP 8.2 and newer, so a 4.6 app on PHP 7.4 can usually move up. CodeIgniter 4 apps on 4.2.11 or later can run on PHP 8.2.
3. Isolate the app. CISA says organizations that "continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated." ENISA's joint statement similarly suggests isolating exposed applications "from public networks until fixes can be applied." For an internal tool, that can mean allowing access only over a VPN or from the office network.
4. Plan the rebuild. A CodeIgniter 3 or CakePHP 2.x app will need a framework upgrade or a rebuild to reach supported PHP. That is a project, not an emergency fix, and it starts with a tested backup, as our backup and recovery guide explains. Our guide to upgrading old PHP safely explains how to sequence it.

If you take an app offline, Beazley Security advises using "a maintenance response or network restriction rather than disabling the PHP handler, which can expose application source code and credentials." Those credentials often include database passwords in config files.

Who Patches PHP for Your App

Neither framework comes with a hosted platform, so the answer depends on where the app lives:

• Shared or managed hosting: usually the host. Ask which PHP build serves your site now and whether workers were restarted. Get the answer in writing.
• A VPS or dedicated server: you, or whoever you pay to manage it. Install the fixed packages and restart PHP.
• Docker: you. Rebuild every image from a fixed PHP base and replace the running containers.
• An agency or freelancer built it: check whether your contract covers server maintenance. Some cover the code only.

Step by Step: Patch and Verify

1. Find every copy of the app. Production, staging and any old test copy still online. To keep updates routine afterward, see our security patching best practices.
2. Find the PHP that serves it. Check the web-facing PHP, not just the terminal. CakePHP's docs expect the two to match, and on many servers they don't. Our PHP version guide shows safe ways to check.
3. Install the fix. Use PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, or a backported distribution package.
4. Restart every PHP process. PHP-FPM or Apache, plus any queue workers or daemon scripts started from the command line. Our restart guide has commands for each setup.
5. Confirm. Recheck the serving version, build date or package changelog, and test the app's forms and file uploads.
6. Review logs from 17 October onward, the earliest date an exploitation attempt has been reported. Look for unusual multipart POST requests, memory-exhaustion errors and new PHP files.

What Not to Rely On

• Framework updates. They don't touch the PHP engine.
• .htaccess PHP settings. Both frameworks commonly ship .htaccess files for URL rewriting, and some apps add php_value lines to them. PHP's advisory says per-directory settings are applied very early in the request, and it lists "invalid or deprecated settings applied per request that emit diagnostics" as something to remove. Move needed PHP settings into php.ini or the FPM pool, and don't treat .htaccess changes as protection.
• ini_set() in your bootstrap. PHP says not to rely on ini_set() or .user.ini for its interim settings. They take effect too late.
• Hiding errors. PHP says turning off error display or reporting "does not help."

If you can't patch today, the settings that do reduce exposure, and what each can break, are in our interim mitigations guide.

Conclusion

CodeIgniter and CakePHP apps need the same fix as every PHP app: a patched PHP build and a restart. What makes them harder is that many are legacy apps on PHP versions with no official release. Patch what you can today, isolate what you can't, and turn the oldest apps into a planned upgrade. If the app was custom-built and nobody is sure where it runs, our guide to finding forgotten PHP servers starts with the inventory. For help patching or isolating an old app, our emergency PHP patching service can step in. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions