By Aims Infosoft | #1 Magento Solutions Provider | PHP and Magento Security
Two critical flaws in PHP can let a remote attacker run code on a vulnerable web server without signing in. The PHP project released fixes on October 21, 2026 for CVE-2026-109618 and CVE-2026-109619, now commonly called PHP2Shell.
The bugs are in PHP itself, so updating WordPress, Magento, or another application does not fix them. If your site serves requests through PHP, check the runtime and install the appropriate vendor-supported security update promptly.
This guide explains what PHP2Shell is, which systems to check, which PHP releases contain the fixes, and the four steps to take now, with extra checks for Magento store owners.
What Is PHP2Shell? (Quick Answer)
PHP2Shell is the name used for two PHP memory-safety vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that may let a remote attacker run code on a web server without signing in. The fix is a PHP update: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor package confirmed to contain the October 21, 2026 patches.
- Fixes released: October 21, 2026
- CVEs: CVE-2026-109618 (out-of-memory handling) and CVE-2026-109619 (stale request state)
- Impact: memory corruption that can lead to unauthenticated remote code execution
- Affects: PHP serving web requests, including Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed
- Highest demonstrated risk: Apache mod_php, with an attack path that runs before application code starts
- Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35
- Does a Magento or WordPress update fix it? No. The flaw is in the PHP runtime
How Do the Two PHP2Shell Vulnerabilities Work?
PHP2Shell covers two separate flaws. Both can be reached through crafted requests, but they arise in different circumstances.
CVE-2026-109618 involves out-of-memory handling. In some request-processing paths, PHP can run out of memory while internal request data is only partly initialized. Cleanup may then treat that incomplete data as valid, leading to memory corruption and potentially remote code execution. The PHP team says the demonstrated risk is highest with Apache mod_php; researchers showed an attack path that runs before application code starts.
CVE-2026-109619 involves stale request state. A PHP worker can retain a reference to memory belonging to an earlier request after that memory has been released. If a later request reaches the same worker and uses the stale state before it is reset, the result can be memory corruption and, under the right conditions, remote code execution.
The specific exposure depends on the PHP build, configuration, extensions, web server, and request handling. Treat all web-facing PHP installations as needing review, even if your setup differs from a demonstrated exploit.
Which Systems Should You Check for PHP2Shell?
The PHP advisory covers PHP installations serving web requests, including:
- Apache with
mod_php - PHP-FPM
php-cgi- FrankenPHP
- LiteSpeed
That includes sites built with Magento, WordPress, Drupal, Joomla, Laravel, and custom PHP applications.
Look beyond the main website. Hosting control panels, containers, bundled vendor products, staging servers, and separate applications may each run their own PHP version. If you use managed hosting, ask the provider which PHP runtime serves your site and whether its package contains the October 21 fixes.
Which PHP Releases Fix PHP2Shell?
The PHP project lists these fixed versions:
| PHP branch | Fixed release |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
Linux distributions and hosting companies may backport the fixes without changing the upstream version number. Check the vendor’s security notice or package revision rather than relying on the version string alone.
PHP 8.1 and earlier are no longer routinely supported by the PHP project. Some vendors may provide their own patched packages, but availability varies. Confirm directly with your distribution or host, and plan a move to a currently supported PHP branch.
What Should You Do Now? (4-Step PHP2Shell Response)
Step 1: Inventory your PHP runtimes
List every internet-facing server, container, hosting account, control panel, and vendor product that serves PHP. Record the version, how it is deployed, and who supplies updates. Prioritize systems that accept requests from the public internet.
Step 2: Install and verify the fix
Upgrade to the fixed release for your branch, or install a package your operating-system or hosting vendor confirms contains the patches. Restart PHP workers or web services if your deployment requires it. Then verify the package actually handling requests; updating a CLI-only PHP installation may leave the web runtime unchanged.
Step 3: Use temporary controls only while arranging an update
PHP’s advisories describe limited configuration measures for specific exploit paths. These measures can affect application behavior and do not make an unpatched installation fully safe. Follow the official advisory and your platform provider’s instructions, then complete the update as soon as possible.
A separate PHP notice published October 23 describes another, configuration-dependent session issue. PHP recommends setting session.upload_progress.enabled = 0 until a regular bugfix release for that issue. The relevant exposure requires an unusual combination of session serializer settings and an application changing the serializer at runtime. This setting should not be confused with a complete mitigation for PHP2Shell; consult the current PHP notice to assess whether it applies to your application.
Step 4: Review exposure and investigate signs of compromise
Where your architecture permits it, limit direct access to PHP services while patching. A reverse proxy, firewall, or private network may reduce exposure, but does not replace installing the PHP fix.
If a server was reachable while vulnerable, review web and PHP logs and look for unfamiliar files, scheduled tasks, accounts, or outbound connections. Investigate PHP or web-server workers launching shells, download tools, or unrelated interpreters. Preserve relevant logs and bring in your incident response team if you find suspicious activity. Patching closes the vulnerability but does not remove an attacker’s files or persistence from an earlier compromise.
What Should Magento Store Owners Know About PHP2Shell?
Magento relies on PHP to handle requests, so a flaw in PHP can be reached before Magento’s application code and security checks run. A Magento security patch or extension update cannot repair the underlying PHP runtime.
If an attacker obtains code execution as the web-server user, the impact depends on that account’s permissions and the server setup. In a Magento deployment, sensitive files such as app/etc/env.php contain database connection details. Review them and other critical files against known-good deployment copies after applying the PHP update.
As part of your normal incident response, also review:
- Magento administrator accounts
- Recently changed webroot and
pubfiles - Theme and layout templates
- Server logs
- Outbound process activity
A Magento-focused security scan can help identify suspicious changes, but investigate findings rather than treating a clean scan as proof that no compromise occurred.
Keep PHP and the Application in View
PHP2Shell is a reminder that application security depends on the software underneath it. Start by locating every web-facing PHP runtime, apply a vendor-supported fix, and verify that the updated runtime is serving requests. If any system was exposed before patching, include it in your incident review.
For a closer look at both CVEs, the affected PHP setups, and the commands to check which PHP build serves your site, read our earlier advisory: PHP2Shell: Two Critical PHP Flaws Let Attackers Run Code Without Logging In.
PHP2Shell FAQs
What is PHP2Shell?
PHP2Shell is the name used for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that may let a remote attacker run code on a vulnerable web server without signing in. The PHP project released fixes on October 21, 2026.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux distributions and hosting companies may backport the fixes without changing the upstream version number, so check the vendor’s security notice or package revision rather than the version string alone.
Does updating Magento or WordPress fix PHP2Shell?
No. The bugs are in PHP itself, so updating WordPress, Magento, or another application does not fix them. You need to update the PHP runtime that serves your site.
Which PHP setups should be checked for PHP2Shell?
Any PHP installation serving web requests, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Also check hosting control panels, containers, bundled vendor products, staging servers and separate applications, which may each run their own PHP version.
Is PHP 8.1 or older protected against PHP2Shell?
Not by default. PHP 8.1 and earlier are no longer routinely supported by the PHP project. Some vendors may provide their own patched packages, but availability varies, so confirm with your distribution or host and plan a move to a supported PHP branch.
Does setting session.upload_progress.enabled = 0 fix PHP2Shell?
No. PHP recommends that setting for a separate, configuration-dependent session issue described in its October 23 notice. It is not a complete mitigation for PHP2Shell; the fix is installing the patched PHP release.
What should Magento store owners check after patching PHP?
Compare app/etc/env.php and other critical files with known-good deployment copies, then review administrator accounts, recently changed webroot and pub files, theme and layout templates, server logs and outbound process activity. Investigate scan findings rather than treating a clean scan as proof that no compromise occurred.
How Aims Infosoft Can Help
Aims Infosoft works with Magento and PHP-based stores on security updates and incident investigation. We can help you confirm which PHP runtime serves your site, coordinate the update, or review a store after exposure.
Contact Aims Infosoft for PHP2Shell help
Aims Infosoft | #1 Magento Solutions Provider | 10+ Years | 50,000+ Stores Served | 52+ Products | 12+ Extensions
References & Sources
- PHP security release and advisory information: https://www.php.net/?p=6507
- CVE-2026-109618: PHP advisory: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- CVE-2026-109619: PHP advisory: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- PHP notice on the October 23 session issue: https://www.php.net/archive/2026.php#2026-10-23-1
- ENISA joint statement: https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities
- Canadian Centre for Cyber Security advisory: https://www.cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619
