By Aims Infosoft | #1 Magento Solutions Provider | Security Advisory
Two critical vulnerabilities in PHP itself can let an attacker run code on a web server without logging in. The PHP project released security updates on October 21, 2026 for CVE-2026-109618 and CVE-2026-109619, the pair now widely discussed as PHP2Shell.
The risk applies to any PHP installation that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP security team says the risk is highest for Apache mod_php, where researchers demonstrated an attack that runs before any application code. Magento, WordPress, Laravel and every other PHP application sits on top of the runtime, so updating your CMS does not fix it.
Here is what PHP2Shell is, which PHP versions fix it, and what to do now, including the extra checks Magento store owners should run.
What Is PHP2Shell? (Quick Answer)
PHP2Shell is the name for two separate memory-safety flaws in the PHP runtime, CVE-2026-109618 (out-of-memory handling) and CVE-2026-109619 (stale request state). Both can be reached with crafted HTTP requests and no account, and both can lead to remote code execution. The only complete fix is updating PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to a vendor package that includes the October 21, 2026 fixes.
- Released: October 21, 2026 (PHP security updates)
- CVEs: CVE-2026-109618 and CVE-2026-109619
- Impact: remote code execution through crafted HTTP requests
- Authentication needed: none
- Affects: PHP serving web requests: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed
- Highest risk: Apache mod_php, where an attack before application code has been demonstrated
- Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (or your vendor’s patched package)
- Does a Magento or WordPress update fix it? No. The flaw is in PHP itself
- Temporary settings: reduce risk only; updating PHP is the only complete mitigation
How Does CVE-2026-109618 (Out-of-Memory Handling) Work?
PHP uses an early-exit mechanism when an operation runs out of memory. In some situations that exit can leave request data only partly initialized. During request cleanup, PHP may then use that invalid data, which creates a path to remote code execution.
The PHP project has confirmed a pre-application exploit path for Apache mod_php. PHP-FPM handles a failed request startup differently, so the demonstrated mod_php scenario does not automatically apply to every setup. The PHP advisory still treats all web-facing installations as at risk and recommends updating.
How Does CVE-2026-109619 (Stale Request State) Work?
Some PHP state can outlive the request that created it. If the request’s memory is freed before that state is reset, a later request handled by the same worker can run into a stale reference. Depending on the operations involved, this can also lead to remote code execution.
The PHP project describes several conditions that can contribute to this flaw, and the exact exposure depends on the PHP version, configuration, extensions and request handling. A setting that blocks one confirmed attack path should not be treated as a complete fix.
Who Is Affected by PHP2Shell?
The PHP security advisory covers PHP installations that serve 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. The vulnerability is in PHP itself, so a CMS or extension update alone does not fix it.
Check every runtime, not only the PHP version behind your main website. Hosting control panels, containers, scheduled jobs that expose PHP endpoints and vendor applications can each bundle a separate PHP installation. On managed hosting, ask your provider which PHP build serves your site and whether it includes the October 21 security fixes.
Which PHP Versions Fix PHP2Shell?
The PHP project lists these fixed releases:
| PHP branch | Fixed version |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
Linux distributions and long-term support vendors may ship the fix under their own version numbers. Confirm it with your operating-system or hosting vendor instead of relying only on the upstream PHP version string.
PHP 8.1 and earlier no longer receive routine updates from the PHP project. PHP provided minimal source backports for 7.4, 8.0 and 8.1 to help vendors and people who build PHP from source, but whether a backport reaches your server package depends on your distributor or host. Ask them directly, and plan an upgrade to a supported PHP release.
What Should You Do Now? (4-Step PHP2Shell Response)
✅ 1. Find every PHP runtime.
Inventory internet-facing servers, hosting control panels, containers and third-party products that bundle PHP. Record the PHP version, how it is deployed and who is responsible for updating it. Start with systems that accept public HTTP requests.
✅ 2. Install a patched package and verify it.
Update to the fixed release for your branch, or install the package your distribution or host confirms contains the fix. Restart the PHP workers and web services if your deployment requires it, then check the version or package revision that is actually serving requests. The command-line PHP can differ from the PHP behind your website:
# Command-line PHP (may not be the build that serves your website)
php -v
# PHP-FPM build (the binary name varies, e.g. php-fpm8.3)
php-fpm -v
# Distribution package revision (Debian/Ubuntu, then RHEL-based)
dpkg -l | grep php
rpm -qa | grep phpIf you rely on Remi’s volunteer-maintained repository, the PHP advisory said updated packages would not be available there on release day. Check its current status, and use distribution packages or a source build as your operations team directs.
✅ 3. Treat temporary settings as risk reduction only.
If you cannot update immediately, review the configuration mitigations in the official PHP advisory with your platform administrator. For CVE-2026-109619, disabling session upload progress blocks the confirmed session-related paths but not every variant. CVE-2026-109618 has separate suggested measures, including how PHP’s memory limit and request-size controls are managed. These settings can change application behavior and availability, so apply them only with a clear understanding of your workload.
PHP states that these measures do not make an installation safe. Updating to a fixed release is the only complete mitigation.
✅ 4. Limit exposure and look for signs of compromise.
Where your architecture allows it, restrict direct access to PHP services while you patch. A web application firewall, reverse proxy or private network can limit exposure, but none of them replaces the PHP update.
If a server was publicly reachable while vulnerable, review the PHP and web server logs, and look for unexpected files, changed scheduled tasks, unfamiliar accounts and unusual outbound connections. PHP worker processes that launch shells, download tools or unrelated interpreters deserve investigation. Preserve the relevant logs and involve your incident response team if you find signs of compromise.
What Should Magento Store Owners Know About PHP2Shell?
Magento runs on PHP, so a vulnerable PHP runtime can put a store at risk before Magento’s own code handles the request. A Magento security patch or extension update does not repair a flaw in the PHP runtime underneath it.
If an attacker gains code execution as the web server user, the impact depends on that account’s permissions and the server’s configuration. It can include reading files that account can access, changing site files, or reaching application credentials. In Magento, app/etc/env.php holds the database connection settings, so treat it as sensitive and check it for unexpected changes.
After you apply the PHP fix, review the store for signs of compromise as part of your normal incident response process:
- Compare
app/etc/env.phpand other sensitive files with known-good deployment copies. - Review recent Magento admin accounts and investigate any you don’t recognize.
- Check the webroot,
pub, theme and layout files for unexpected changes or externally hosted scripts. - Review server and PHP logs for unusual requests and process activity.
- Run a reputable Magento-focused security scan and investigate any findings.
Don’t assume that patching removes files or persistence left behind by an earlier compromise. If you find suspicious activity, preserve the evidence and investigate the server before returning it to normal service.
The Priority Is the PHP Update
PHP2Shell is a runtime-level issue: two critical vulnerabilities with unauthenticated attack paths, and fixed versions already available. Identify every web-facing PHP runtime, install and verify the vendor-supported fix, and use temporary configuration changes only as a short-term measure while you finish that work.
PHP2Shell FAQs
What is PHP2Shell?
PHP2Shell is the name for two critical memory-safety vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619. Both can be reached with crafted HTTP requests and no login, and both can lead to remote code execution. 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 providers may ship the fix under their own package versions, so confirm with your vendor that the package serving your site includes the October 21, 2026 fixes.
Does updating Magento or WordPress fix PHP2Shell?
No. The vulnerabilities are in PHP itself, not in Magento, WordPress, Drupal, Joomla or Laravel. You need to update the PHP runtime that serves your site; a CMS or extension update alone does not fix it.
Which PHP setups are affected by PHP2Shell?
PHP installations that serve web requests, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for Apache mod_php, where researchers demonstrated an attack that runs before application code.
Is PHP 8.1 or older safe from PHP2Shell?
Not by default. PHP 8.1 and earlier no longer receive routine updates from the PHP project. Minimal source backports exist for 7.4, 8.0 and 8.1, but whether your server package includes them depends on your distributor or host. Ask them, and plan an upgrade to a supported PHP release.
Can I disable session upload progress instead of updating PHP?
Only as a temporary measure. Disabling session upload progress blocks the confirmed session-related paths for CVE-2026-109619 but not every variant, and it does not address CVE-2026-109618. The PHP project says updating to a fixed release is the only complete mitigation.
How do I check whether my Magento store was compromised?
After patching PHP, compare app/etc/env.php and other sensitive files with known-good copies, review recent Magento admin accounts, check the webroot, pub, theme and layout files for unexpected changes, review server and PHP logs, and run a Magento-focused security scan.
How Aims Infosoft Can Help
Patching PHP sounds simple until you find three different PHP builds across your servers, a host that ships its own package versions, and a store that was reachable while it was vulnerable. We work with Magento and PHP-based stores on security updates and incident investigation.
If you need help confirming which PHP runtime serves your site, coordinating a safe update, or reviewing a Magento store after exposure, reach out.
👉 Contact Aims Infosoft for PHP2Shell Patch Assistance →
Aims Infosoft — #1 Magento Solutions Provider | 10+ Years | 50,000+ Stores Served | 52+ Products | 12+ Extensions
References & Sources
- PHP security advisory and release information — https://www.php.net/archive/2026.php#2026-10-21-5
- 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
- ENISA joint statement on critical PHP vulnerabilities — https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities
- Huntress research on PHP2Shell — https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
