EveryHost: Magento Dedicated Hosting UK

    Insights

    PHP2Shell: the PHP code-execution flaw every Magento store needs patched now (CVE-2026-109618, CVE-2026-109619)

    By Simon Bumford, Founder of EveryHostLast updated 13 min read

    On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical bugs, CVE-2026-109618 and CVE-2026-109619, that the researchers who found them call PHP2Shell. Both let an attacker run code on a web server, as the web server's own user, by sending crafted HTTP requests with no login. The flaw is in PHP itself, so it affects Magento Open Source, Adobe Commerce and Mage-OS exactly as it affects WordPress or Laravel, and no Magento patch can fix it. The fix is a PHP update on the server. PHP's own words: "There are no complete mitigations, updating is the only safe choice." This guide covers which PHP version your Magento needs, how to check whether your server has it, what the interim measures do to a Magento store, and what the UK's NCSC is telling organisations to do.

    See plans and prices 0333 577 6191
    How PHP2Shell gets in
    PHP workermod_php / FPMGETGETmultipartmemorymemory_limit$ iduid=www-dataPHP 8.4.27soft limit, no crash

    Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, 21 October 2026. No Magento patch can close it.

    What PHP2Shell is, in plain English

    PHP2Shell is two separate bugs in the PHP engine, reported to PHP by four researchers and fixed together on 21 October. PHP rates both Critical with a CVSS 4.0 score of 9.2. NVD scores them separately on the older CVSS 3.1 scale: 9.8 Critical for CVE-2026-109618 and 8.1 High for CVE-2026-109619, the difference being attack complexity. Neither needs an account, a session or any Magento-specific feature.

    • CVE-2026-109618, "RCE via OOM corruption". When a request pushes PHP over its memory limit, PHP bails out of the request immediately. In some code paths that happens while PHP has only half built its internal request data, and the clean-up that follows treats the half-built data as real. Attackers can force the out-of-memory moment with crafted multipart requests, the kind browsers send for file uploads, without exceeding the limits the server appears to enforce. PHP validated a working exploit against Apache with mod_php on default settings, and says PHP-FPM is susceptible on source analysis.
    • CVE-2026-109619, "RCE via stale global state". A PHP worker handles many requests in a row. After a fatal error or a timeout, some of PHP's global bookkeeping can keep pointing at memory from the finished request even though that memory has been freed. The next request on the same worker can then act on it before PHP resets things. PHP lists memory disclosure among the impacts: the researchers showed a worker's memory, which can hold other visitors' passwords, session tokens and API keys, can be read remotely. For this bug PHP states that remote code execution was validated on PHP-FPM, so FPM is not a theoretical case here.

    Who is at risk, from PHP's advisory: "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." That last clause is the important one for shops: the attack lands before Magento runs a single line, so Magento's own protections, its maintenance mode and its admin URL make no difference.

    Is my Magento store affected?

    Yes, if it serves pages through PHP, which every Magento store does. PHP has published fixed releases for the 8.2, 8.3, 8.4 and 8.5 lines and minimal source backports for 7.4, 8.0 and 8.1, which are otherwise out of support. Anything older is unsupported and should be treated as affected. The question is not whether your store is affected but which PHP line it runs, because that decides which fix you need and whether a vendor has to supply it.

    Magento releasePHP it runs on (Adobe's requirements)Fixed PHP you need
    2.4.9, Mage-OS 3.x8.5 (Mage-OS also 8.3, 8.4)8.5.12 (or 8.4.27, 8.3.36 on Mage-OS)
    2.4.8, Mage-OS 2.x8.4 or 8.38.4.27 or 8.3.36
    2.4.78.3 or 8.28.3.36 or 8.2.35
    2.4.68.2 or 8.18.2.35, or a vendor backport for 8.1
    2.4.4 and 2.4.58.1A vendor backport only: PHP itself no longer ships 8.1 releases
    Magento 1PHP 7.x and olderMagento 1 itself has had no upstream fix since the platform ended in 2020. PHP 7.4 did get a backport, and some distributions patched 7.2, 7.3 and 7.4

    Two things follow from that table. A store on Magento 2.4.4, 2.4.5 or 2.4.6 on PHP 8.1 depends entirely on its host or distribution backporting the fix, and the end of life page explains why those lines were already overdue for an upgrade. And a store on 2.4.9 cannot sidestep this by staying on an older PHP: 2.4.9 requires PHP 8.5, so 8.5.12 is the only fixed version it can run.

    How to check whether your server is patched

    Check the PHP that serves the store, not the one on the command line, because they can differ. In the Magento admin, Stores, Configuration, Advanced, Developer is not where it lives; the simplest reliable read is a one-line file in the document root that prints `phpversion()`, loaded once over HTTPS and deleted immediately. Magento's sample nginx configuration denies PHP files other than its own entry points, so on that setup the file needs a temporary exception in nginx, removed afterwards. On the server, `php-fpm -v` or `php -v` tells you the CLI build, and `php-fpm` pool settings tell you which build nginx talks to.

    The version you want to see is 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or higher. There is one trap. Control panels that backport the fix into out-of-support PHP lines often do it without changing the version number. On cPanel, EasyApache 4 release 25.91 updates ea-php82 to 8.2.35, ea-php83 to 8.3.36, ea-php84 to 8.4.27 and ea-php85 to 8.5.12, but ea-php74, ea-php80 and ea-php81 keep their existing version numbers and carry the fix as a backport. On those, `php -v` cannot tell you whether you are patched; the EasyApache package changelog can, and so can your host.

    Where the fixes stand as of the evening of 21 October 2026:

    PlatformStatus
    PHP source releases8.5.12, 8.4.27, 8.3.36, 8.2.35 released; minimal backports published for 7.4, 8.0, 8.1
    cPanel EasyApache 4Release 25.91: ea-php82 to ea-php85 updated; ea-php74, 80 and 81 backported with no version change. cPanel's own interface PHP updated in 138.0.18, 136.0.50, 134.0.66 and 110.0.153
    Plesk for LinuxUpdated 3 Nov 2026: 8.2.35, 8.3.36, 8.4.27 and 8.5.12 available, plus patched end-of-life builds for 7.4.33, 8.0.30 and 8.1.34 that keep the same version number with a 21 October build date. The Plesk engine fix shipped in Obsidian 18.0.81 Update 4 and 18.0.80 Update 11
    Plesk for WindowsUpdated 3 Nov 2026: 8.2.35, 8.3.36, 8.4.27 and 8.5.12 now available
    UbuntuUSN-8948-1: 24.04 php8.3 8.3.6-0ubuntu0.24.04.13, 22.04 php8.1 8.1.2-1ubuntu2.28, 26.04 php8.5 8.5.4-0ubuntu1.5
    Debiantrixie php8.4 8.4.27-1~deb13u1 (DSA-6574-1); bookworm php8.2 8.2.35-1~deb12u1 (DLA-4848-1)
    AlmaLinuxUpdated 3 Nov 2026: every stream AlmaLinux ships is now patched, including php:8.1 on AlmaLinux 9 (ALSA-2026:A014, php-fpm 8.1.32, version string unchanged) and php:8.0 on AlmaLinux 8. Red Hat shipped no php:8.1 fix, so this one is AlmaLinux's own work
    Remi repositoryUpdated 3 Nov 2026: fixed builds published 22 October. Note there is no patched PHP 8.1 from Remi, and Remi describes its 8.1 packages as best-effort rather than a supported line

    Those rows will date quickly. Each vendor's page is linked in the sources below; check it rather than this table if more than a day has passed.

    One later development, added 3 November 2026. On 23 October PHP published an informational advisory asking anyone who set `session.upload_progress.enabled=0` as a mitigation to leave it off until PHP's next regular bugfix release, under a separate issue, CVE-2026-115560. PHP has announced that id but not yet published a full advisory or a score for it. On PHP 8.5 only, PHP also lists `fatal_error_backtraces=0` as a mitigation.

    If you cannot update within the hour

    PHP's advisory gives temporary measures and is blunt about them: they "do not make an installation safe" and "only an update is a complete solution". Use them to shorten the exposed window, not to replace the update. Three of them matter specifically to Magento.

    Setting `memory_limit` to -1 is the main stopgap for the first bug, and Magento quietly undoes it. PHP's advice is to remove the configurable memory limit so the controllable out-of-memory failure cannot be triggered, and to set it "in a way applications can't override". Magento 2.4.9 ships `memory_limit = 756M` in `.user.ini` and `pub/.user.ini`, a `php_value memory_limit 756M` line in `pub/.htaccess`, and `fastcgi_param PHP_VALUE "memory_limit=756M"` in its sample nginx configuration. Any of those puts a finite limit straight back. Corrected 7 November 2026: the setting only holds if nothing later replaces it. Under PHP-FPM, `php_admin_value` in the pool beats `.user.ini`, but Magento's nginx `PHP_VALUE` line replaces even that. In a test we ran on PHP-FPM 8.4.13, sending Magento's line gave 756M, and `ini_set()` still failed, so the value looks locked. On nginx, either take `memory_limit` out of that `PHP_VALUE` line and keep the pool setting, or add `fastcgi_param PHP_ADMIN_VALUE "memory_limit=-1"` in the same location block. On Apache with mod_php, use `php_admin_value` in the Apache configuration, which `.htaccess` cannot override. Expect memory use to climb, and put a container or cgroup limit around PHP as a boundary; PHP warns specifically against `RLIMIT_AS` and `RLIMIT_DATA`, because they trigger the vulnerable path themselves. PHP is clear that this does not close the path and is not a complete mitigation, so treat it as a stopgap until PHP is updated.

    Blocking multipart requests at the web server stops the known trigger and breaks parts of Magento. Multipart is how product images, CSV imports and some storefront forms are sent, so a blanket block disables admin uploads and may affect checkout for some extensions. If you use it, test an order and an admin image upload straight afterwards, and remove it once PHP is updated. PHP documents blocking multipart only for applications that do not use multipart form data, which Magento does, so this one needs care. Lowering `post_max_size` and `upload_max_filesize` is a gentler version of the same idea.

    `session.upload_progress.enabled = 0` helps with the second bug only. It closes the confirmed session paths and nothing else, and it has to be set in `php.ini`, the FPM pool or the server configuration and followed by a restart of every worker: `ini_set()` and `.user.ini` are too late. PHP also says to remove any deprecated or invalid `php_value` lines applied per request, because diagnostics raised before a request is initialised are one of the confirmed routes for the second bug, and hiding them with `error_reporting`, `display_errors` or `@` does not help.

    Maintenance mode is not a mitigation. PHP parses the request before Magento checks the maintenance flag. Taking the store offline at the web server or firewall is, and the NCSC lists it as a last resort where neither the update nor the mitigations can be applied.

    Has it been exploited?

    Updated 3 November 2026: yes. On 26 October 2026 CISA added both CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog, with a federal remediation due date of 29 October 2026. CISA's own assessment records exploitation as active for both. No authoritative source reports attacks aimed specifically at Magento or Adobe Commerce stores, and PHP's and Adobe's advisories still make no exploitation claim of their own.

    As published on 21 October, before the CISA listing: technical details leaked publicly on 20 October, a day before the release, and PHP had already said it would release early if that happened. Several security vendors reported early attack traffic around the release, though at least one later retracted its attribution of that traffic to these CVEs. Treat every unpatched, internet-facing PHP server as exposed.

    If a store sat unpatched after the 20th, check it rather than assume. Sansec's and Wiz's indicators are unusual multipart requests followed by memory-limit errors, bursts of HTTP 500 responses, unusually large or malformed `PHPSESSID` cookies, and PHP workers restarting without explanation. A patch does not remove anything an attacker installed before it; the Magento malware clean-up page covers what to look for and what we charge if you want us to look.

    Timeline

    • August 2026: the first code-execution paths are found and reported to PHP. The GitHub advisories credit four reporters by handle: lcfr-hax, sagitzadik-wiz, tomash-areion and amyb-oai. Exact reporust.
    • 27 August to 18 October: PHP's security team works the fix: the change replaces the hard memory-limit exit with a soft limit handled at a safe point.
    • 20 October: PHP pre-announces a security release for 14:00 UTC the next day. Details leak on social media the same day.
    • 21 October, 03:02 UTC: Cloudflare's WAF rules go live for all plans; Cloudflare later reports attack traffic.
    • 21 October, about 14:00 UTC: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 ship, with backports for 7.4 to 8.1. cPanel's EasyApache 4 25.91, Ubuntu's USN-8948-1 and Debian's fixes land the same day. The NCSC publishes its alert.

    What the NCSC says

    The UK's National Cyber Security Centre published "Critical security issue affecting PHP" on 21 October, and runs an opt-in Early Warning service that notifies subscribed organisations about exposed services. Its advice, in order: find every PHP installation and prioritise the internet-facing ones; apply vendor updates as they appear, including for appliances that bundle PHP; update to the fixed PHP version; apply PHP's hardening steps and, where you cannot update yet, PHP's temporary mitigations; if neither is possible, consider taking the system offline; and if a system could not be updated promptly, check it for signs of compromise before trusting it. Its Dutch counterpart maintains a public inventory of products that bundle PHP.

    What this looks like on managed hosting

    On a managed server the PHP update is the host's job, and the right question to ask is a specific one: which PHP version is serving the store right now, and is it one of the fixed ones or a confirmed backport. If the answer is a version number from the table above, you are done. If it is "we are waiting on the control panel vendor", ask which vendor and check that vendor's page yourself, because the dates above show they are not all moving at the same speed.

    This is the part of hosting that is invisible until a week like this one. On every EveryHost plan the operating system and the server stack, PHP included, are our responsibility to keep updated, on staging first and then production; the store's own code stays with your developer. The managed Magento VPS plans start from £119 a month + VAT and dedicated Magento servers from £249, both with the nginx and PHP-FPM stack rather than mod_php, which PHP ranks as the highest-risk configuration for this bug. The Magento upgrades and security patching page sets out who does what, and the full price list is on plans and prices. If you would rather talk it through, get in touch.

    PHP2Shell arrived eight days after Adobe's own October security bulletin for Magento. If you have not yet applied that, our guide to checking whether your Magento store is patched covers both the Magento side and the server side in one pass, and BlockStrap explains what the October Magento patch fixes.

    Sources

    All accessed 21 October 2026.

    Frequently asked questions

    Yes. CVE-2026-109618 and CVE-2026-109619 are bugs in the PHP engine, so every Magento Open Source, Adobe Commerce and Mage-OS store is affected until the server's PHP is updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor backport for 8.1 and older. No Magento patch fixes it, and Adobe had published no bulletin about it as of 21 October 2026.

    Magento 2.4.9 runs on PHP 8.5, so it needs 8.5.12. Magento 2.4.8 needs 8.4.27 or 8.3.36, 2.4.7 needs 8.3.36 or 8.2.35, and 2.4.6 needs 8.2.35 or a vendor backport for 8.1. Magento 2.4.4 and 2.4.5 run only on PHP 8.1, which PHP no longer releases, so they depend on a backport from the host or distribution.

    As of 21 October 2026, Cloudflare and watchTowr both report attack attempts, while PHP's advisory does not state exploitation and CISA had not listed either CVE. Details leaked a day before the fix. Treat every unpatched server as exposed.

    Only partly. PHP says no configuration makes an installation safe and only the update does. Setting memory_limit to -1 blunts the first bug, but Magento's own .user.ini, .htaccess and nginx sample configuration reimpose a 756M limit. php_admin_value in the FPM pool beats .user.ini but not the nginx PHP_VALUE line, so on nginx also remove memory_limit from that line or set it with PHP_ADMIN_VALUE. WAF rules from Cloudflare and Imunify360 block the known request shapes, not every variant.

    EasyApache 4 release 25.91 carries it. ea-php82 to ea-php85 show the new versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. ea-php74, ea-php80 and ea-php81 keep their old version numbers and carry the fix as a backport, so check the EasyApache package changelog or ask your host rather than relying on php -v.

    No. PHP processes the request before Magento checks the maintenance flag, and PHP says the attack can land before any application code runs. Taking the site offline at the web server or firewall does protect it, which the NCSC lists as a last resort.

    Want the server side handled for you?

    On every EveryHost plan the operating system and the server stack, PHP included, are ours to keep updated, staging first. See the plans, or ask us which PHP version your store should be on.

    See plans and pricesTalk to us Call 0333 577 6191