PHP Security Update 2026: What Magento store must do now

On October 21, 2026, PHP shipped an emergency patch for two critical flaws, called PHP2Shell. The hole is in PHP itself, the language every Magento store runs on, and attackers were already probing for it the day the patch landed.

This blog post points out which Magento versions are exposed, which PHP version to install, and seven steps to take this week.

Two RCE vulnerabilities, CVSS 9.2

Both vulnerabilities are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your server already runs one of those, you can skip to step 6.

However, these are not fixed by the PHP project: PHP 8.1 and older. These branches are end-of-life.

Besides that, code execution is the worst case, not the only one. Researchers showed an attacker can read live memory from the PHP worker process without running any code. On a Magento server that memory holds admin sessions, API tokens and payment gateway credentials belonging to other requests.

The risk is highest on Apache with mod_php, where an unauthenticated request can trigger the first flaw before any application code runs. Most Magento production stacks use Nginx or Apache with PHP-FPM, which narrows the attack path but does not close it. RCE on FPM was confirmed.

Find your row

Magento only supports specific PHP versions per release. That decides which fixed PHP you can move to, and whether you can move at all. Check this table below:

If you are on 2.4.7 or newer, this is a routine PHP minor update. Your hosting provider may have already done it. Check, don’t assume.

If you are on 2.4.4 or 2.4.5, you are locked to a PHP version that the PHP project no longer patches. A backport from your distribution may arrive, or it may not. This is the clearest signal yet that staying on those releases has stopped being a cost saving.

Seven steps to take this week

1. Check which PHP is actually serving requests: Use php -v to view the CLI version. The PHP-FPM pool can be different. Ask your host if unsure.

2. Update to the fixed version for your branch: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On managed hosting, ask for the exact number, not “the latest”. On your own server, use your distribution’s packages.

3. Restart every PHP worker, then review memory_limit. A reload is not always enough. The patch adds a hard memory cap that kills the process outright when hit. Magento needs at least 756M, and 2G for setup:di:compile and static content deploy. Undo any memory tightening you did as a workaround.

4. Can’t update today? Apply PHP’s mitigations at pool or server level, not in .user.ini or ini_set(). They reduce exposure. They do not make you safe.

   memory_limit = -1
   post_max_size = 8M        ; 32M if admins need to upload product images
   upload_max_filesize = 2M  ; must stay below post_max_size
   session.upload_progress.enabled = 0
   fatal_error_backtraces = 0 ; PHP 8.5 only
   

   On Magento, 8M breaks admin image and import uploads. Use 32M and test imports.

5. Test on staging before a minor jump. 8.4.26 to 8.4.27 is safe. 8.1 to 8.2, or 8.2 to 8.3, is not: deprecated functions, changed return types, third-party modules never run on the new branch.

6. Rotate credentials once patched. Worker memory could be read while you were exposed. Admin passwords, REST and GraphQL integration tokens, payment gateway keys, third-party API keys. Force-expire admin sessions. One hour of work.

7. On 2.4.4, 2.4.5 or 2.4.6? Plan the upgrade. Standard support has ended for all three, and two are stuck on a PHP branch with no official fix. 2.4.8 or 2.4.9 gets you patched the same day as everyone else.

Not sure where you stand? Send us your store URL for a free security health check. If any of the seven steps is more than you want to handle, we do them for you.

The bottom line

PHP is the floor every Magento store stands on. When the floor gets patched, the store has to move with it. For most stores on 2.4.7 and newer this is an afternoon. For stores on older releases it is a decision that has been postponed long enough.

Update, restart, rotate, verify. Then decide whether you want to be in this position again next time.