PHP2Shell and Magento 2: How to Check Your Store Is Patched and What to Ask Your Host

TL;DR

PHP2Shell is the nickname for two critical bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619, fixed on October 21, 2026 [1] [7]. No Magento patch or extension update touches them. Your Magento version still matters: it decides which PHP you can run, and 2.4.4 and 2.4.5 are stuck on PHP 8.1, which got no official fix [1] [15]. Find out which PHP your website runs, send your host five questions, then check Magento's own patch level.

Key Takeaways

• The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; Linux distributions ship patched builds with their own version numbers [1] [7].
• The Magento admin footer shows Magento's version, and php -v shows the command-line PHP, which can differ from your website's PHP [14].
• Apache with mod_php is the most urgent case; PHP-FPM is less exposed and still needs the update [1] [2] [3].
• On Magento 2.4.4 or 2.4.5, ask which backported PHP 8.1 build you're on: PHP 8.1 is past its end of life and got no fixed release [1] [6] [15].
• Ask your host five things in writing, including whether workers were restarted and logs reviewed back to October 17 [7] [13].
• After PHP, check Magento's own security patch level; it's a separate job.

What PHP2Shell is, and why a Magento update won't fix it

The bottom right of your Magento admin shows your Magento version, something like 2.4.8-p5 [14]. It tells you nothing about PHP, the program that runs Magento's code on your server, and PHP is where this problem lives.

PHP2Shell is the name in use for two vulnerabilities the PHP project fixed on October 21, 2026 [1] [10]. PHP says they "can allow unauthenticated remote code execution" [1]: someone with no login could run their own code on your server, with the permissions of the web server's PHP process [2]. In plain terms:

• CVE-2026-109618 (out of memory). When PHP runs out of memory at the wrong moment, it can stop halfway through setting up a request, and the cleanup that follows treats the half-built data as valid [1].
• CVE-2026-109619 (stale global state). Some internal PHP state outlives the request it belongs to, and a later request handled by the same PHP worker can use it before it's reset [1].

PHP rates both 9.2 out of 10 on CVSS v4.0, Critical [1] [2] [3]. The US National Vulnerability Database scores them on the older CVSS v3.1 scale at 9.8, Critical, and 8.1, High [4] [5].

Magento patches and extension updates change Magento's code and leave the PHP underneath alone, so they can't fix PHP2Shell on Magento; a PHP update does [1]. As of October 23, 2026 we haven't found a Magento-specific notice from Adobe, so PHP's advisory and Adobe's PHP requirements table are the references for now.

The fix also came out a day early. Disclosure was planned for October 22, details leaked online on October 20, and the release moved to October 21 at 14:00 UTC [7] [8].

Sources for the table: [1] [6].

Is your Magento store exposed?

PHP's answer is that every installation serving web requests is at risk, naming PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed [1]. How exposed you are comes down mostly to how PHP is connected to your web server.

Apache with mod_php. PHP considers this the highest risk, because the demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs [1]. Both bugs were taken all the way to remote code execution against mod_php in the advisories' own validation [2] [3]. Magento still ships settings blocks for mod_php in its pub/.htaccess file, so a Magento store on Apache can be running this way [16].

nginx with PHP-FPM. Adobe's tested combinations list nginx for every current Magento release [15]. The session upload-progress route of CVE-2026-109619 was validated against PHP-FPM; upload progress is on by default, and the path works with a normal FPM pool, though it needs a suitable operation in the application [3]. For CVE-2026-109618, PHP's source analysis says FPM is susceptible, but no complete FPM exploit has been demonstrated [2]. Red Hat calls remote code execution on PHP-FPM "difficult in practice" [9]. Difficult still means possible, and an FPM store needs the same update.

What's confirmed about attacks, in date order:

1. October 17. Amazon's honeypot network logged an exploitation attempt four days before disclosure, then broad attempts after the release. Amazon says it's unclear whether any would have succeeded, and tells defenders to investigate from at least October 17 [13].
2. October 21. CISA had not observed exploitation when it published its alert, and told organisations that can't update, or run PHP 8.1 or older, to take PHP systems offline until patched or updated [10]. Canada's Cyber Centre reported a public proof of concept and no active exploitation identified [12]. A security firm quoted by SecurityWeek saw attempts reach its sensors as the patches landed, none successful [8].
3. October 23. Neither CVE is in CISA's Known Exploited Vulnerabilities catalog, whose latest release is dated October 21 [11].

None of the sources behind this article documents a successful compromise. That can change in a day, and Amazon's date means a store left unpatched since October 17 should be treated as possibly probed.

How to check your PHP version in five minutes

A version number turns up in several places, and they don't all describe the same thing:

The command-line PHP and the website's PHP can be separate installs, so php -v can give a clean answer about the wrong one. A phpinfo() page, opened through the website, reports the PHP actually answering web requests, with its version and configuration [17]. It shows all of that to anyone who opens it, so whoever creates it should read it and delete it in the same sitting.

Even the right number can mislead. Linux distributions patch the PHP they ship without moving to PHP's version numbers. Ubuntu's fixed builds are 8.3.6-0ubuntu0.24.04.13 on Ubuntu 24.04 and 8.1.2-1ubuntu2.28 on Ubuntu 22.04 [7]. Next to PHP's fixed 8.3.36, 8.3.6 looks thirty releases behind, yet it carries the fix. Ubuntu installs security updates automatically every 24 hours, but the running PHP still has to be restarted [7].

So don't compare numbers. Ask the host for the exact build and whether it includes the fixes for both CVEs. You've probably had a host answer "we're on the latest PHP" before; this time, ask for the build string.

Stuck on an older PHP because of your Magento version?

Your Magento version caps which PHP branch you can run. These are the combinations Adobe lists, and Adobe says it doesn't validate or support anything outside them [15]:

The bottom two rows are the hard case. PHP 8.1 is past its end of life and got no fixed release, only a minimal source backport for people who build PHP themselves or have no long-term-support vendor [1] [6]. A 2.4.4 or 2.4.5 store is patched only if its host or Linux distribution applied a backport; Ubuntu 22.04's PHP 8.1 build has one [7]. If your host can't name a patched 8.1 build, your store isn't patched. CISA's advice for PHP 8.1 or older is to take the systems offline until they're patched or updated [10].

A 2.4.6 store can move to PHP 8.2, which has the official 8.2.35 fix but leaves PHP's security support on December 31, 2026 [6]. On 2.4.7 and 2.4.8, PHP 8.3 is supported until December 31, 2027 [6]. Getting off PHP 8.1 for good means a newer Magento version; our guide to upgrading Magento 2.4.x without breaking your analytics covers the patch order.

Five questions to ask your host today

Send these in one message and ask for written answers. They're for your host or developer to act on; none of them is a setting to change yourself.

1. Are both the website's PHP and the command-line PHP on a build with the fixes for CVE-2026-109618 and CVE-2026-109619? Ask for the build string of each [1] [7].
2. Were all PHP workers restarted after the update? A patched package does nothing until the running PHP processes reload it; Ubuntu's own instructions end with restarting the web server or rebooting [7].
3. Does my store run on Apache with mod_php, or on PHP-FPM? The answer tells you how urgent everything else on this list is [1].
4. What did you change while waiting for the update, and is it still in place? PHP lists measures that reduce exposure but "do not make an installation safe" [1]. For CVE-2026-109619 it's session.upload_progress.enabled=0, set in php.ini, the FPM pool or the server configuration, never through ini_set() or .user.ini, then a restart of every worker [1] [3]; pm.max_requests=1 helps if performance isn't a factor [3]. For CVE-2026-109618 it's an administratively enforced memory_limit=-1 that no pool, directory or application setting overrides [1] [2]. On Apache with mod_php, Magento's pub/.htaccess sets memory_limit to 756M, so the host has to account for that file [16]. CISA says a web application firewall may give some protection [10]. None of this replaces the update.
5. Will you review the logs back to October 17? That's the date Amazon recommends starting from [13]. CISA asks defenders to watch for PHP worker processes launching shells or downloading tools [10], and Canada's Cyber Centre adds web server, application and authentication logs [12]. PHP itself warns that a clean log isn't proof of safety [3].

What should you check after your host says it's done?

Ask for evidence on the first question: a fresh phpinfo() page showing a fixed build, deleted right after [17], or the build string from the server's package manager [7].

Then turn to Magento itself, because a patched PHP says nothing about Magento's own patch level. September's StyleSmuggler zero-day was a Magento bug with its own Adobe hotfix, and our Magento security update for September 2026 lists it and the command that confirms it's applied. September's fixes plus a patched PHP build with restarted workers covers both layers.

FAQ

Does a Magento security patch fix PHP2Shell?

No. The bugs are in PHP, so only a PHP update fixes them: 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a distribution build that carries the fixes [1] [7].

Is my store safe if it runs PHP-FPM instead of mod_php?

Safer, but it still needs the update. One route of CVE-2026-109619 was validated against PHP-FPM [3], and PHP lists FPM among the setups at risk [1].

My store runs Magento 2.4.5. What are my options?

Magento 2.4.5 supports only PHP 8.1 [15], and PHP published no fixed 8.1 release [1]. Your host needs a backported 8.1 build, like Ubuntu 22.04's [7]; the lasting fix is a Magento version that runs PHP 8.2 or newer [15].

Has any store actually been hacked through PHP2Shell?

As of October 23, 2026, none of the sources in this article documents a successful compromise. The attempts are real: Amazon logged the first on October 17 and broad attempts after the release [13].

If fixing PHP turns into a Magento upgrade, check your extensions' PHP support before the move. Our Magento 2 Google Analytics 4 extension added PHP 8.4 in v1.15.0 (April 22, 2025) and PHP 8.5 in v1.17.0 (May 18, 2026) [18].

Sources

1. PHP security advisory: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities, PHP News Archive 2026, October 21, 2026, retrieved October 23, 2026, https://www.php.net/archive/2026.php#2026-10-21-5
2. RCE via OOM corruption (CVE-2026-109618), GHSA-w8hw-w9fx-j79w, php-src security advisory, retrieved October 23, 2026, https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
3. RCE via stale global state (CVE-2026-109619), GHSA-6wmf-4rv5-p3rp, php-src security advisory, retrieved October 23, 2026, https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
4. CVE-2026-109618, National Vulnerability Database (NIST), retrieved October 23, 2026, https://nvd.nist.gov/vuln/detail/CVE-2026-109618
5. CVE-2026-109619, National Vulnerability Database (NIST), retrieved October 23, 2026, https://nvd.nist.gov/vuln/detail/CVE-2026-109619
6. Supported Versions, PHP, retrieved October 23, 2026, https://www.php.net/supported-versions.php
7. PHP2Shell vulnerability fixes available, Ubuntu blog (Canonical), retrieved October 23, 2026, https://ubuntu.com/blog/php2shell-vulnerability-fixes-available
8. PHP2Shell patches land as first exploitation attempts hit sensors, SecurityWeek, retrieved October 23, 2026, https://www.securityweek.com/php2shell-patches-land-as-first-exploitation-attempts-hit-sensors/
9. RHSB-2026-013, PHP request handling memory corruption, Red Hat security bulletin, retrieved October 23, 2026, https://access.redhat.com/security/vulnerabilities/RHSB-2026-013
10. Critical Vulnerabilities in PHP Require Immediate Patching, CISA alert, October 21, 2026, retrieved October 23, 2026, https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
11. Known Exploited Vulnerabilities Catalog, CISA, catalog version 2026.10.21, checked October 23, 2026, https://www.cisa.gov/known-exploited-vulnerabilities-catalog
12. AL26-026, Critical vulnerabilities impacting PHP, Canadian Centre for Cyber Security, October 21, 2026, retrieved October 23, 2026, https://cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619
13. Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, AWS Security Blog, retrieved October 23, 2026, https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
14. Check the Commerce version, Adobe Commerce developer documentation, retrieved October 23, 2026, https://developer.adobe.com/commerce/php/development/versioning/check-version
15. System requirements, Adobe Commerce installation guide (Experience League), retrieved October 23, 2026, https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/system-requirements
16. pub/.htaccess, magento/magento2 repository (2.4-develop branch), retrieved October 23, 2026, https://github.com/magento/magento2/blob/2.4-develop/pub/.htaccess
17. phpinfo, PHP Manual, retrieved October 23, 2026, https://www.php.net/manual/en/function.phpinfo.php
18. WeltPixel Google Analytics 4 User Guide and Change Log (v1.15.0 and v1.17.0 entries), retrieved October 23, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html