PHP2Shell and Magento: what Adobe Commerce stores should do now

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of critical PHP runtime flaws, and Sansec says researchers confirmed unauthenticated code execution against Magento 2.4.9. Any Magento Open Source or Adobe Commerce store on unpatched PHP is exposed. Update PHP to a fixed release, restart every worker, then check checkout pages for skimmers.

Our PHP2Shell explainer covers the bugs themselves. This post goes deeper for people who run Magento stores, from Sansec's warnings to skimmer checks after the patch.

What happened

The PHP fix landed in the same fortnight as a separate critical Magento bug, so many stores face two patches at once.

Exploitation status is disputed. Sansec cites Cloudflare's report of early attacks, while other responders said they had not seen in-the-wild exploitation when they wrote; our explainer lays out each claim. Either way, an unpatched store facing the internet is at risk today.

What Sansec is warning Magento merchants about

Sansec, which researches e-commerce malware, published its PHP2Shell post on 21 October. In our words:

• Your store code does not matter here. The bugs are in the PHP engine, so Magento, Shopware and WooCommerce stores are exposed even if their own code is clean.
• Magento 2.4.9 is confirmed. Researchers confirmed unauthenticated code execution on it, plus ten other PHP applications.
• Wide version range. Sansec says the vulnerable code goes back to PHP 5.4.0 from 2012, and that default configurations are vulnerable on both Apache mod_php and PHP-FPM. PHP's own advisory lists only its supported branches as fixed.
• Memory leaks, not only code execution. Sansec says one bug can leak freed memory in a PHPSESSID cookie, exposing passwords, session tokens, API keys or TLS private keys, even if the application never starts a session. It compares this to Heartbleed.
• The fix is on the server. No Magento or extension update changes this. Update PHP on every server, or ask your host to do it now.
• Remi was late. The volunteer Remi repository, common on RHEL-family servers, lacked the fix on 21 October; Sansec suggests distribution packages or a source build.
• Its own firewall product does not cover this. Sansec says the attack runs inside PHP before both store code and its Shield product, and tells merchants not to wait for a rule.

One labelling difference: Sansec attaches the session upload progress path to CVE-2026-109618, while PHP's advisory describes that CVE as out-of-memory corruption and ties upload progress to CVE-2026-109619. We follow PHP's labels. The fix is the same.

Why checkout and payment pages are the real risk

A store is a web page that asks strangers for their card number. An attacker who can run code on the server that builds that page can change what every shopper's browser receives. Three things can go wrong.

1. A skimmer gets added to checkout. A few lines of JavaScript copy what the shopper types and send it to the attacker. Sansec's malware notes say Magento skimmers usually hide in database fields such as core_config_data, cms_block or cms_page, and sometimes get appended to a JavaScript file on disk. A clean deploy from Git does not remove what lives in the database.
2. A backdoor stays behind. Patching PHP does not remove a web shell dropped in the meantime. Sansec says removing injected code is not enough unless you also find the root cause.
3. Secrets leak. If worker memory can be read, admin sessions, database passwords, gateway credentials and integration tokens are in scope. A stolen API key leaves no visible trace.

A gateway-hosted iframe or redirect keeps card data off your server, which helps. It does not stop someone who controls your server from changing the page that loads the iframe, swapping the redirect target, or adding a fake payment step. The PCI Security Standards Council's e-skimming guidance covers pages that embed payment forms in iframes for this reason.

Which PHP your Magento release can run

Supported PHP comes from Adobe's system requirements page (updated 13 October 2026), which says it is the same for cloud and on-premises. Fixed versions come from php.net; support dates from Adobe's lifecycle policy (updated 18 September 2026).

Stay on your current branch. Upgrade within it (8.3.x to 8.3.36). Moving from 8.2 to 8.3 is a compatibility project, and Adobe supports only the combinations it lists.

Stores on 2.4.4 and 2.4.5 have a harder day. Both list PHP 8.1 only, and php.net says 8.1 no longer gets updates from the PHP project. PHP published minimal source backports for 7.4, 8.0 and 8.1, and distributions or LTS vendors may ship patched packages. Otherwise, upgrade Magento to a line that supports 8.2 or later, or go offline or read-only until you can.

2.4.6 has a way out. It supports 8.1 and 8.2, so moving to 8.2.35 reaches an upstream fix without changing Magento. Test on staging. PHP 8.2 reaches end of life on 31 December 2026, per php.net.

Adobe Commerce Cloud versus self-hosted

Adobe's shared responsibility page for cloud infrastructure lists server-level security patching among Adobe's duties. It also says the merchant must keep platform services on supported versions, naming "the database, cache, search, PHP runtime, and web server", and must apply Commerce patches. Read together: Adobe patches the servers, and you choose and maintain the PHP version line in .magento.app.yaml.

We found no Adobe statement on PHP2Shell as of writing, so we cannot say whether patched builds have reached cloud environments. Check each one:

# Adobe Commerce on cloud infrastructure, using the magento-cloud CLI
magento-cloud ssh -e production
php -v
php -i | grep -E 'session.upload_progress.enabled|memory_limit|post_max_size'

Then ask Adobe support to confirm the PHP build on production and staging and when workers restarted. Adobe's PHP settings page says production changes need at least 48 hours' notice and can take up to 48 hours to apply. That covers PHP version and extension changes, one more reason not to switch branches this week.

Cloud projects sit behind Fastly. Adobe says its Fastly WAF runs on production only, with rules managed by Fastly and Adobe, including rules for new CVEs. Treat any WAF rule as a stopgap; Cloudflare described its own PHP2Shell rules that way, per The Hacker News.

Patching without a long outage

Most stores can patch PHP with seconds of disruption per server.

Step 1: Find out exactly what serves your store

bin/magento --version
composer show magento/product-community-edition 2>/dev/null | grep -m1 versions
composer show magento/product-enterprise-edition 2>/dev/null | grep -m1 versions
php -v                                   # CLI, used by cron and bin/magento
ps -o pid,lstart,cmd -C php-fpm8.3       # adjust to your FPM binary name
apachectl -M 2>/dev/null | grep -i php   # is mod_php loaded?

Check every web, cron and admin node; the CLI PHP that runs cron is a separate package from what serves shoppers.

Step 2: Stage the packages before you touch anything

On Debian and Ubuntu, download first so the risky part is only the restart:

sudo apt-get update
sudo apt-get install --download-only --only-upgrade 'php8.3*'
apt changelog php8.3-fpm | grep -m1 CVE-2026-109618

On RHEL-family servers, check which repository PHP comes from:

dnf list installed 'php*'          # the repo column shows remi, appstream, etc.
sudo dnf upgrade 'php*'
rpm -q --changelog php-fpm | grep -m1 CVE-2026-109618

Afterwards, confirm Magento's required extensions still load with php -m. Adobe lists them on its system requirements page, including ext-soap, ext-sodium and ext-xsl.

Step 3: Restart one node at a time

With two or more web nodes behind a load balancer:

1. Take one node out of the pool and let open requests finish.
2. Install the staged packages.
3. Restart PHP so no worker keeps the old binary in memory.
4. Check the node directly, then put it back.
5. Repeat for the next node.

sudo systemctl restart php8.3-fpm        # or: sudo systemctl restart apache2 (mod_php)
ps -o pid,lstart,cmd -C php-fpm8.3       # master start time should be just now
curl -fsS -o /dev/null -w '%{http_code}\n' -H 'Host: shop.example.com' http://127.0.0.1/

On a single server the restart is short, and if Varnish or Fastly sits in front, cached catalog pages can keep serving. Cart, checkout and admin always hit PHP. The restart clears OPcache, so the first requests are slower.

Step 4: Containers and Kubernetes

Rebuild from a patched base image and roll it out; a running pod does not change because a tag moved.

docker build --pull -t registry.example.com/magento-fpm:2026-10-21 .
docker run --rm --entrypoint php registry.example.com/magento-fpm:2026-10-21 -v
kubectl set image deployment/magento-fpm fpm=registry.example.com/magento-fpm:2026-10-21
kubectl rollout status deployment/magento-fpm

Our fleet-wide PHP patching guide covers image types and confirming every worker restarted.

Step 5: If you cannot patch today

Sansec lists stopgaps that buy time. PHP's announcement is blunt: "There are no complete mitigations, updating is the only safe choice."

• Block multipart requests at the web server. Sansec says every known trigger is a multipart request, parsed by PHP before Magento runs. It breaks admin image uploads and may break some checkout forms, so place a test order and remove the rule after patching.

# Temporary stopgap only: reject multipart bodies before PHP sees them.
# Breaks uploads. Remove after patching.
if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

• Go read-only. Sansec suggests allowing only GET and HEAD, which keeps browsing up but blocks login and orders. A static maintenance page with PHP-FPM stopped is safer still.
• Do not rely on Magento's maintenance mode. PHP parses each request before Magento shows the maintenance page, Sansec notes.
• PHP settings. Disable session.upload_progress.enabled and set memory_limit = -1 in php.ini or the FPM pool, not .user.ini. This conflicts with Adobe's usual memory_limit = 1G advice; Sansec says to watch memory and restore the limit after patching.

Our post on governments taking websites offline over PHP2Shell covers making the offline call.

Step 6: Apply the Magento patch in the same window

If APSB26-153 (BlockStrap) is not applied, do it in the same window. Sansec says a plain Composer install stays vulnerable, so you need Adobe's October release or isolated patch, and the September StyleSmuggler hotfix must stay in place. Sansec suggests confirming the fix by looking for resolveDeferredDirectives in the framework's Template.php:

grep -rl resolveDeferredDirectives vendor/magento/framework/

After the patch: checking for skimmers and backdoors

This checklist follows Adobe's incident response guidance and Sansec's notes on where skimmers hide. Table names assume no prefix.

1. Preserve logs first, as Adobe advises. Copy web server, PHP-FPM and Magento logs somewhere the web server cannot write.

2. Audit admin accounts. Remove anything you do not recognise and rotate every admin password.

SELECT user_id, username, email, created, logdate, is_active
FROM admin_user
ORDER BY created DESC;

3. Check head and footer HTML at every scope. Adobe tells merchants to review HTML Header and Footer configuration at all scope levels, including website and store view, and remove unknown JavaScript.

SELECT config_id, scope, scope_id, path, LEFT(value, 200) AS value_start
FROM core_config_data
WHERE path IN ('design/head/includes', 'design/footer/absolute_footer')
   OR value LIKE '%<script%';

4. Check CMS blocks and pages for scripts. Sansec's malware notes name these tables as common hiding places.

SELECT block_id, identifier, update_time FROM cms_block WHERE content LIKE '%<script%';
SELECT page_id, identifier, update_time FROM cms_page WHERE content LIKE '%<script%';

5. Compare code on disk with what you deployed. Adobe recommends comparing production with version control and quarantining anything suspicious.

git status --porcelain
find app lib pub vendor -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
find pub/media pub/static -type f -name '*.ph*'

Adobe specifically says to check the media folder for leftover executable code. Nothing in pub/media should be PHP.

6. Look at checkout as a shopper does. In a clean browser profile that has never logged into admin, go to the payment step with developer tools open and compare every script host against the list you expect. A rough first pass:

curl -s https://shop.example.com/checkout/cart/ | grep -oE 'https?://[^"/ ]+' | sort -u

Many scripts load later through RequireJS, so the browser check is the one that counts.

7. Check scheduled jobs and access paths. Review crontabs for the web user, and on cloud projects audit SSH keys, as Adobe advises.

crontab -l -u www-data

8. Rotate secrets that lived in PHP memory. Given Sansec's memory disclosure warning, rotate gateway credentials, integration and API tokens, the database password and admin passwords, as Adobe's incident guidance also lists. Test any encryption key change on staging first, because stored data depends on it.

9. Run a scanner. Adobe's free Security Scan Tool, in the Commerce account dashboard, runs more than 21,000 security tests for potential malware after you verify the domain.

10. If you find something, scope it. Adobe's guidance: bring in your integrator and security staff, establish whether card data was reachable and for how long, consider rebuilding from a known clean source, and reset every credential. Adobe warns of re-compromise within hours.

PCI DSS context

This uses only the PCI Security Standards Council's own pages. It is context, not compliance advice.

• PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 took effect on 31 March 2025, according to the Council's January 2025 announcement. The Council's March 2025 guidance says they aim to make sure payment page scripts are authorised, checked for integrity and monitored for tampering, along with security-impacting HTTP headers.
• The Council's guidance describes e-skimming as attacks on scripts running in shoppers' browsers, and says it applies to any entity whose web pages can affect e-commerce payment security, including through embedded iframes.
• For merchants on SAQ A, the Council removed 6.4.3, 11.6.1 and 12.3.1 from that questionnaire and added an eligibility criterion: the merchant must confirm the site is "not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)". The Council says this changes how compliance is reported and does not reduce the underlying requirements.
• The Council does not enforce compliance. It tells merchants to check validation duties with their acquirer or payment brands.

Code execution on your server means the scripts and headers on your payment pages can be changed. If you validate on SAQ A, revisit that eligibility statement this week, and talk to your acquirer early if you find signs of compromise.

What would have helped

The stores in the best position on 21 October could answer three questions fast: which PHP serves each store, how do we roll it, and would we notice a changed checkout page.

Practices any merchant or agency can use:

• A store inventory that includes the runtime. For each store: Magento line and patch, PHP version and SAPI, host or image, and who patches it.
• Staying inside support windows. Stores on 2.4.4 and 2.4.5 are pinned to PHP 8.1 and had no upstream fix on release day. Plan Magento upgrades around PHP end-of-life dates too.
• A rehearsed rolling restart. Two web nodes and a tested drain procedure turn a PHP patch into a non-event.
• Pinned, rebuildable images. Pin PHP base images by version, rebuild on a schedule with --pull, and keep a pipeline that can ship a new image within the hour.
• A payment page script inventory with change alerts. The list of every checkout script and why it is there, plus alerts on change, is what PCI's 6.4.3 and 11.6.1 describe, and it catches skimmers whatever the entry point.
• Head and footer scripts in Git, not the admin. Scripts pasted into admin configuration live in the database, outside code review.
• Credentials that rotate in minutes, so a memory disclosure bug is a chore, not a crisis.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.

Gold Open Source (gold.safeguard.sh, free, no login) offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher and Sigstore-signed, with evidence pages; an artifact loses its badge if it regresses. No patched build was in Gold before PHP's public fix. The habit that matters is pulling patched, signed components from a curated source and rebuilding fast.

Where Safeguard fits

Safeguard would not have prevented PHP2Shell. It does not patch servers, restart workers, search your database for skimmers or watch your checkout page. It helps you find where you are exposed and make the change.

• See which PHP your store images ship. safeguard scan --image <name> builds an SBOM of a container image, including OS packages such as PHP, and matches components against vulnerability databases. safeguard scan --dir . scans a Magento repository, including the Magento version in the Composer lockfile. Results land as JSON under ./output.
• Answer "which stores run this". The platform shows which projects contain a given component and version, so an agency can list every store still on a PHP 8.1 image or an old Magento line.
• Stop old images shipping. Policies and gates evaluated in the platform can block a build that still carries a vulnerable PHP package once the CVEs appear in your findings.
• Make the change with approval. The Safeguard CLI's assistant can edit a Dockerfile base tag or PHP version line and run your build and tests, asking before each command in its default mode, from the terminal, desktop app or phone.

Where it does not help: PHP on Adobe's cloud infrastructure or a managed host, PHP installed by hand on servers you never scan, skimmers stored in core_config_data or CMS content, browser-side script monitoring, PCI validation and blocking attack traffic. Database matching can lag a same-day advisory, and distro backports make version matching noisy, so confirm against your vendor's changelog.

Common mistakes

• Updating Magento and assuming PHP came with it. Composer updates application code. PHP is a server package or a base image.
• Checking only php -v. That is the CLI. The FPM pool or Apache module serving checkout may differ and may not have restarted.
• Jumping PHP branches under pressure. Stay on your branch and patch.
• Trusting Magento maintenance mode. PHP parses the request first.
• Leaving multipart blocking in place. It breaks uploads and some checkout forms.
• Cleaning the skimmer and stopping there. Malware returns unless the root cause and backdoors are found, Sansec warns.
• Reviewing checkout while logged in as admin. Check it as a new shopper would.

FAQ

Is Magento itself vulnerable to PHP2Shell?

The bugs are in PHP, not Magento's code. But Magento runs on PHP, and Sansec says researchers confirmed unauthenticated code execution against Magento 2.4.9. Treat any store on unpatched PHP as exposed.

Which PHP version should my Magento store run now?

The fixed release on the branch you already use: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, provided Adobe supports that branch for your Magento line. Stores on 2.4.4 or 2.4.5 need a vendor backport of PHP 8.1 or a Magento upgrade.

We are on Adobe Commerce Cloud. Is Adobe handling this?

Adobe's shared responsibility page puts server-level patching with Adobe and PHP version choice with the merchant. We found no Adobe statement on PHP2Shell as of writing, so run php -v in each environment and ask support to confirm the build and restart time.

Does a hosted payment form or iframe protect us?

It keeps card data off your server. It does not stop an attacker who controls your server from changing the page that loads the form, which is why PCI SSC guidance covers iframe pages too.

Can we just turn on Magento maintenance mode?

No. PHP parses each request before Magento shows the maintenance page. Use a static page with PHP-FPM stopped, or GET-only access at the web server.

Do we need to rotate keys even if we found no skimmer?

If the store faced the internet on unpatched PHP, it is reasonable, because Sansec warns one bug can leak memory holding passwords, tokens and keys. Start with gateway credentials, integration tokens and admin passwords.

Is BlockStrap related to PHP2Shell?

No. BlockStrap (CVE-2026-103849, APSB26-153) is a Magento flaw fixed on 13 October; PHP2Shell is in the PHP runtime. Most stores need both fixes.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions. None shows PHP2Shell or Magento.

The first shows the Safeguard CLI fixing a lodash CVE: it reads the finding, asks before each command, edits package.json, runs install and tests with approval, and pushes nothing. For PHP2Shell you would run safeguard scan --image against your Magento FPM image and ask the assistant to move the Dockerfile to the patched PHP tag on your branch, approving each build step.

Click through it at your own pace, or open it full screen.

The second is a desktop app session: the CLI session appears in the conversation list, you ask for work on your computer, pick the folder, and approve or deny each command and file edit, ending with an upgrade done and tests passing. An agency could use the same flow to bump one client store's PHP image and review every change before it runs.

Click through it at your own pace, or open it full screen.

The third is a real Android session: you send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. On a night like 21 October, the on-call engineer could approve a store image rebuild from a phone without approving anything else.

Click through it at your own pace, or open it full screen.

To try it, download Safeguard at https://safeguard.sh/download and read the CLI docs at https://docs.safeguard.sh/docs/cli . For the rest of the month, see October 2026 security incidents and what would have helped.

Quick check

Sources

• Sansec: PHP2Shell, critical PHP RCE (CVE-2026-109618, CVE-2026-109619)
• Sansec: BlockStrap, Magento and Adobe Commerce RCE (CVE-2026-103849)
• Sansec research index
• Sansec malware notes: GetCCInfo skimmer
• PHP news archive: advance notice and 21 Oct security releases (php.net)
• PHP manual: FPM configuration (php.net)
• Adobe: Adobe Commerce system requirements
• Adobe: Adobe Commerce lifecycle policy
• Adobe: Shared responsibility for Adobe Commerce on cloud infrastructure
• Adobe: Shared responsibility for Adobe Commerce as a Cloud Service
• Adobe: PHP settings on cloud infrastructure
• Adobe: Fastly WAF service
• Adobe: Respond to a security incident
• Adobe: Security Scan Tool
• PCI SSC: New information supplement on payment page security and preventing e-skimming
• PCI SSC: Important updates for merchants validating to SAQ A
• The Hacker News: PHP2Shell, what actually protects you

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.