EveryHost: Magento Dedicated Hosting UK

    Insights

    PHP2Shell and Magento 2.4.4/2.4.5: what to do if you are stuck on PHP 8.1

    By Simon Bumford, Founder of EveryHost6 min read

    PHP2Shell is two flaws in PHP itself, not Magento, so the fix is a PHP update, and stores on 2.4.4 or 2.4.5 need a patched PHP 8.1 build now and an upgrade plan next.

    Upgrades and security patching 0333 577 6191
    Your Magento stack
    • nginx
    • PHP
    • MariaDB or MySQL
    • OpenSearch
    • Valkey or Redis
    • Varnish
    Matched to your Magento version

    What PHP2Shell is

    PHP2Shell is the security industry's name for two vulnerabilities in the PHP runtime, published by the PHP project on 21 October 2026. PHP does not use that name. It calls them RCE via OOM corruption (CVE-2026-109618) and RCE via stale global state (CVE-2026-109619). Both can allow unauthenticated remote code execution.

    PHP rates both 9.2, critical, on CVSS v4.0. The National Vulnerability Database scores them separately on CVSS 3.1: 9.8 for CVE-2026-109618 and 8.1 for CVE-2026-109619. PHP says they affect "all PHP installations serving web requests", naming PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk on mod_php. Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all released on 21 October 2026.

    On 26 October 2026 CISA added both CVEs to its Known Exploited Vulnerabilities catalog, meaning it has evidence of exploitation in the wild. No authoritative source reports attacks aimed specifically at Magento stores. For the background, see our full PHP2Shell guide.

    Who is affected

    MagentoSupported PHPFixed PHP to use
    2.4.98.58.5.12
    2.4.88.4, 8.38.4.27 or 8.3.36
    2.4.78.3, 8.28.3.36 or 8.2.35
    2.4.68.2, 8.18.2.35
    2.4.58.1Patched vendor build only
    2.4.48.1Patched vendor build only

    PHP versions are from Adobe's system requirements, which are set per patch level, so check the exact patch release your store runs.

    Stores on 2.4.4 and 2.4.5 are the hard case. Those releases support only PHP 8.1, which reached end of life on 31 December 2025 and received no fixed release. PHP published minimal source backports for 7.4, 8.0 and 8.1 as branches in its source repository, for "people building from source or without access to an LTS vendor", and directs everyone else to their vendor: "Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version."

    Why a Magento patch cannot fix this

    The flaws are in PHP, not Magento code. A Magento security patch, a later patch release on the same PHP, or an extension update does not change the PHP runtime. The update has to come from whoever provides your PHP packages.

    When a vendor backports a fix to PHP 8.1, the version number does not change, so php -v proves nothing. Patched builds report what they always reported: Ubuntu 22.04 reports 8.1.2 (USN-8948-1, package 8.1.2-1ubuntu2.28) and AlmaLinux 9's php:8.1 module reports 8.1.32. The proof is the package changelog, and the package name differs by platform: ea-php81-php-common on cPanel EasyApache 4, php81-php-common for a Remi Software Collection, alt-php81-common on CloudLinux alt-php, php8.1-common on Ubuntu. Some vendors name no CVE IDs in changelogs, in which case the version is the only check. Restart every PHP worker afterwards.

    Two things before you go looking: Debian ships no php8.1 package, so PHP 8.1 there comes from a third-party repository, and Remi has no patched PHP 8.1 either.

    If you are on 2.4.4 or 2.4.5, ask your host to confirm in writing which PHP 8.1 package each environment runs, that it carries the fix for CVE-2026-109618 and CVE-2026-109619, and that all PHP workers were restarted.

    Interim measures, and their limits

    PHP is explicit that these reduce exposure and nothing more: "There are no complete mitigations, updating is the only safe choice."

    PHP's advisory lists the measures, including a memory_limit change, with a warning not to substitute RLIMIT_AS or RLIMIT_DATA, "as these can cause the vulnerable allocation failure". Getting this wrong makes things worse, so read PHP's advisory rather than a summary, and have whoever runs your server apply it.

    Two Magento-specific points. Magento ships five files that set memory_limit, all at 756M, including .user.ini in the root and in pub, and a PHP-FPM pool php_value will not override .user.ini, so a change needs php_admin_value. Separately, PHP advises keeping session.upload_progress.enabled=0 until its next regular bugfix release, under CVE-2026-115560, announced but not yet published in full. Magento's own code contains no reference to session upload progress in 2.4.4, 2.4.5 or current development, so switching it off is not expected to affect the store. Third-party extensions were not surveyed.

    Upgrade path

    1. Now: run a patched PHP 8.1 build from your distribution or an LTS vendor, confirmed by the package changelog or version, with workers restarted.
    2. Next: plan the move off 2.4.4 or 2.4.5 to Magento 2.4.8 or 2.4.9. Adobe's standard support ended on 12 April 2025 for 2.4.4 and 12 August 2025 for 2.4.5, and the security-only period running to 31 May 2027 applies to Adobe Commerce licences, not Magento Open Source.
    3. Do not stop at PHP 8.2. It reaches end of life on 31 December 2026, and Adobe's own lifecycle policy flags PHP 8.2 as putting PCI compliance at risk from the end of 2026.
    4. Test on staging first, then move PHP and Magento together.

    What to ask, whoever hosts you

    Treat this as a hosting question first. Ask which PHP package each environment runs, whether it carries the fix, and when the workers were last restarted. Then book the Magento upgrade, so you are not depending on an end-of-life PHP branch.

    On Adobe Commerce cloud infrastructure, Adobe places responsibility for keeping platform services on supported versions with the merchant, the PHP runtime included, while version changes are carried out by Adobe at your request through a support ticket. Ask Adobe which PHP patch release your environments run.

    If you are looking to move, we will take on a 2.4.4 or 2.4.5 store as it stands. We would rather host an older store properly than leave it where nobody is watching it, and we will not make the upgrade a condition of moving. We will encourage you to plan that upgrade, either with your own developer or with us, because an end-of-life PHP branch is a position you want to leave rather than settle into.

    This page is general technical guidance based on public sources. It is not an assessment of any particular store.

    For how we handle upgrade planning and patch windows, see Magento upgrades and security patching.

    Sources

    All accessed 3 November 2026.

    Frequently asked questions

    Only on a patched PHP 8.1 build from a distribution or LTS vendor. Those two Magento releases support PHP 8.1 only, and PHP published no fixed 8.1 release. PHP's direction is to contact your vendor or upgrade to a supported version. The practical answer is to get a patched 8.1 build in place now and plan the Magento upgrade next.

    Not with php -v. A backported fix does not change the version number: Ubuntu 22.04 still reports 8.1.2 and AlmaLinux 9's module still reports 8.1.32. Check the package changelog for CVE-2026-109618, using the right package name for your platform, for example ea-php81-php-common on cPanel EasyApache 4 or php8.1-common on Ubuntu. Some vendors name no CVE IDs in their changelogs, in which case compare the package version against the vendor's advisory.

    No. The flaws are in the PHP runtime, so no Magento patch, patch-release upgrade or extension update changes them. The fix comes from whoever provides your PHP packages, and every PHP worker has to be restarted afterwards.

    CISA added both CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog on 26 October 2026, which it does on evidence of exploitation in the wild. No authoritative source reports attacks aimed specifically at Magento or Adobe Commerce stores.

    With EveryHost, yes. We will take the store on as it stands rather than making the upgrade a condition of moving, because an older store is safer somewhere it is being watched than somewhere it is not. We will encourage you to plan the upgrade to 2.4.8 or 2.4.9 afterwards, with your own developer or with us.

    Prefer 2.4.8 or 2.4.9. Adobe's standard support for 2.4.7 ends on 31 May 2027, so stopping there buys a short-lived position. Avoid landing on PHP 8.2 as part of the move, because PHP 8.2 reaches end of life on 31 December 2026 and Adobe's lifecycle policy flags it as putting PCI compliance at risk from the end of 2026.

    Stuck on Magento 2.4.4 or 2.4.5?

    If you want the PHP position checked and the upgrade to 2.4.8 or 2.4.9 planned properly, we can go through it with you and your developer.

    Upgrades and security patchingTalk to us Call 0333 577 6191