PHP2Shell and Magento: What Self-Hosted Stores Must Fix Before It's Too Late

On 21 October 2026, PHP released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell. For Magento merchants, PHP2Shell Magento exposure is a self-hosting problem: on Magento Open Source, nobody patches PHP for you. On older versions, there may be no official patch at all.

Here's how to stabilize the store, check what got in, and turn the fix into an upgrade.

What PHP2Shell Means for Magento Stores

PHP2Shell is a pair of use-after-free (a memory bug where software keeps using memory after releasing it, letting an attacker place their own data there) flaws in the PHP runtime, both rated CVSS 9.2 (Critical). They allow remote code execution (an attacker runs their own commands on your server from the internet) without a login. Because PHP handles each request before Magento’s code runs, no Magento patch fixes it, and even maintenance mode doesn’t protect the store.

What an attacker can do on a Magento store

• Plant payment skimmers (malicious JavaScript that copies card details as shoppers type them at checkout) on checkout.
• Create hidden admin accounts for later access.
• Read database and API credentials leaked from memory.
• Inject spam pages that damage search rankings.
• Trigger PCI DSS and GDPR exposure.

Amazon's honeypots recorded an exploit attempt on 17 October, four days before the fix. No breach had been publicly confirmed at the time of writing this blog, which doesn't necessarily mean none happened.

Why Magento Open Source Stores Carry the Full Load

Magento Open Source is self-hosted, so PHP, the server and its security are your responsibility, or your host's.

If You Run Your Own Servers

Your DevOps team owns the updates, worker restarts and verification in every environment.

If a Hosting Provider Manages the Server

Do not assume it's done. Ask for written confirmation of the PHP version now serving your store, and whether staging was patched too.

If No One Is Sure Who Owns It

This is the most exposed position. Stores that changed agencies or hosts often inherit servers nobody fully documented.

Magento PHP2Shell Exposure Table

Your Magento version decides your options. Stores on 1.x, 2.4.4, 2.4.5 and 2.4.6 running PHP 8.1 come first this week. A backport secures them for now, and only an upgrade brings back regular patch coverage.

Magento 2.4.4 to 2.4.6 on PHP 8.1 Has No PHP2Shell Fix

PHP shipped fixes only for 8.2 and newer. PHP 8.1 and older get no official release, just source backports someone has to compile and test. Per Adobe's system requirements: Magento Open Source 2.4.4 to 2.4.6 have also reached end of support, with no extended-support option. The short-term answer is to secure the store within its current PHP version through a tested backport and hardening. The lasting answer is an upgrade.

Magento 1: no fix at all

Magento 1 reached end of life in June 2020, and most remaining stores run PHP 7.x or older. PHP 7.3 and earlier have no fix of any kind, so the plan is containment now and migration to Magento 2 next.

How to Patch a Magento Store Against PHP2Shell

Step 1: Find the PHP Version Actually Serving the Store

Check through the web server. The command-line binary often differs from the one serving pages. Check every environment, including staging.

Step 2: Update PHP and Restart Every Worker

Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a tested backport on PHP 8.1. Restart PHP-FPM or Apache, because running workers keep old code in memory.

Step 3: If You Can’t Patch Today, Contain

Temporary measures, in order of strength

• Take the store offline properly by stopping PHP-FPM and serving a static page
• Set session.upload_progress.enabled = 0 and restart workers
• Lower post_max_size and keep WAF rules in blocking mode

What doesn't count as containment

Maintenance mode, hiding errors or relying on a WAF alone. Attackers are already adapting payloads to slip past WAF rules.

Step 4: Regression-Test the Store

Check checkout, payments, search, ERP sync, cron and admin uploads. Extensions written for older PHP usually cause any breakage.

Magento-Specific Checks for Signs of Compromise

Patching doesn't remove what got in first. Review activity from 17 October for:

• New or changed admin accounts in the admin_user table
• Injected scripts in core_config_data, especially design head and footer settings, a favourite hiding place for payment skimmers (malicious JavaScript that copies card details as shoppers type them at checkout).
• Modified CMS blocks and pages carrying unfamiliar JavaScript
• Unknown PHP files in pub/, pub/media or upload folders
• Changed app/etc/env.php or unexpected cron entries
• PHP processes launching shells, curl or wget

Rotate What May Have Leaked

Rotate database passwords, admin passwords, integration tokens and payment gateway API keys used during the exposure window.

Check Payment Pages and Search Presence

PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 already require you to authorize every checkout script and detect unauthorized changes to them. Check the Security Issues report in Google Search Console for hacked-content warnings. If spam pages have hurt your rankings, our SEO team can help you recover them.

Protect Customer Data When Something Gets Through

In standard Magento 2, payment credentials are encrypted and passwords hashed, but customer names, emails, phone numbers and addresses sit in plain text. A leaked backup, stolen credentials or insider export exposes all of it.

PII Shield, our extension for Magento 2, adds field-level encryption (encrypting individual sensitive fields, such as a name or an email address, inside the database) to limit that damage:

• Encrypts personal data across customers, orders, invoices, shipments, carts and credit memos
• Built on Libsodium, the encryption library Magento itself uses
• Decrypts in real time for authorized users, so checkout, search and admin work normally

PII Shield does not replace patching. If someone copies your database, they get encrypted records that stay unreadable without the keys.

Get Codilar’s Expert Help Patching Your Magento Store

Stabilize in 48 Hours

Start with a free PHP2Shell Exposure Check, run read-only and with your written consent, with findings in 48 hours. Where action is needed, we patch PHP or secure the store within its current PHP version, targeting 48 hours for standard environments.

Secure What Matters

Skimmer and compromise sweep, credential rotation, custom hardening and SEO clean-up.

Strengthen for The Next One

A Magento upgrade to 2.4.8 or 2.4.9 on supported PHP, ideally with a Hyvä frontend in the same project, unmaintained extensions removed, PII Shield, and hosting and DevOps that ship the next patch in hours.

❝

The stores that recover fastest from incidents like this aren't the best-defended. They're the ones that can upgrade without fear.❞

Shahed Jamal | Practice Head - Adobe Commerce