PHP Patch
CVE-2026-109618 · CVE-2026-109619CVSS 9.2 CriticalRemote code execution without loginPHP 5.4 – 8.5.11
PHP vulnerability response for Magento & Adobe Commerce

A compromised store leaks card data and customer records.

The new PHP flaws allow remote code execution and memory leaks on the server that runs your checkout. On Magento, that server handles payments, customer accounts and admin sessions.

Affected versions

Is the PHP Magento & Adobe Commerce runs on affected?

5.4 – 8.1No fix comingEnd of life. Upgrade to 8.2+
8.2Fixed in8.2.35
8.3Fixed in8.3.36
8.4Fixed in8.4.27
8.5Fixed in8.5.12

Run php -v on the server. A patched version on disk only protects you after every PHP worker restarts. Distro packages can carry backported fixes under older version numbers, so we confirm against your vendor's changelog.

Why Magento & Adobe Commerce is exposed

What makes these sites a target.

  • Extensions hold back upgrades

    Third-party modules often limit which PHP version a store can run. Older Magento 2.3 and early 2.4 stores often sit on end-of-life PHP.

  • Checkout and APIs take heavy traffic

    Large form posts, REST and GraphQL calls, and catalog imports are exactly the request types these exploits use.

  • Many processes to restart

    PHP-FPM pools, cron jobs and message-queue consumers each run PHP, and each must restart on the patched version.

  • Compliance consequences

    If a breach exposes card data, PCI DSS obligations follow. Patching quickly and keeping records helps your position.

What we do

How we fix it on Magento & Adobe Commerce.

The first commands we run, read-only:

php -v
bin/magento --version
ps aux | grep -E 'php-fpm|queue:consumers' | grep -v grep
  • Inventory

    We record Magento, PHP and extension versions, and check each extension against patched PHP releases.

  • Stage and test

    We run the upgrade on staging and test checkout, payment methods, indexers and integrations.

  • Upgrade and restart

    We upgrade PHP in a planned window and restart PHP-FPM, cron and queue consumers.

  • Harden and verify

    We add WAF and Varnish or load balancer rules, lock down php.ini, and record each step for your PCI file.

Wherever it runs

Any cloud, any VPS, any server.

The fix is the same everywhere: a patched PHP build, restarted workers and hardened settings. We work on VMs, containers, Kubernetes, serverless runtimes and control-panel hosting.

AWSMicrosoft AzureGoogle CloudOracle CloudDigitalOceanAkamai / LinodeVultrHetznerOVHcloudIONOSShared hostingOn-premises & colo
Services

Pick how much you want us to do.

Start here

Exposure check

  • Every PHP version and server you run, listed
  • Clear verdict: exposed or not, and how urgent
  • Written report with next steps

Fixed fee, credited toward remediation

Consulting

Guided remediation

  • Upgrade plan for your platform and hosting
  • Temporary hardening while you wait
  • Edge and WAF rules written for your routes
  • We review your team's work and verify it

Hourly or fixed package

Ongoing

Patch watch

  • We track PHP and platform advisories
  • Quarterly version and config checks
  • Priority response for the next critical CVE

Monthly retainer

How an engagement works

From first call to verified fix.

  1. Authorize

    You sign a short scope and authorization. We don't scan or touch any system without it.

  2. Inventory

    We record every PHP version, server, container and worker process in scope.

  3. Plan

    You get a fixed quote, a schedule and a rollback plan before any change.

  4. Patch and restart

    We upgrade PHP and restart every worker so no vulnerable code stays in memory.

  5. Verify

    We confirm the fix on every host and hand over a written report.

Signs of an attack?

Don't restart the server yet.

If you see shells or tools like curl launched by PHP processes, PHPSESSID cookies longer than 256 bytes, or a spike in PHP worker crashes, contact us before you patch. Restarting wipes the memory evidence that shows what an attacker did. We preserve that evidence first, then work with an incident response firm if the investigation needs one.

Questions

Magento & Adobe Commerce questions.

We're on Adobe Commerce Cloud.

Adobe manages part of that stack. We review your configured PHP version and the services you control, and work with Adobe support as needed.

Can we avoid downtime during checkout hours?

Yes. We schedule the change for your quietest window and keep a tested rollback.

Will our payment extensions keep working?

That's what the staging test is for. We test each payment method before production.

Book an exposure check

Find out where you stand this week.

Tell us what you run on Magento & Adobe Commerce and where it's hosted. We'll reply within one business day with a time for the exposure check.

Email us

Include your platform, approximate number of sites or servers, and your hosting provider.