Website Broken After the PHP Security Update?

Table of Contents

1. Can a PHP security patch break my website?
2. Why does my import, reindex or feed stop halfway with no error?
3. Why can't I upload product images after the hosting PHP update?
4. Why are product variants or attributes not saving?
5. Why did checkout get slow after the PHP patch?
6. My host says PHP is patched, but `php -v` shows an old version. Am I safe?
7. Which processes still run the old PHP?
8. Do I need to change passwords and API keys after php2shell?
9. My store runs PHP 7.4 or 8.1. What now?
10. The day-after checklist
11. FAQ

Summary

On October 21, 2026, PHP released fixes for two critical php2shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619, CVSS 9.2), but after updating, online stores can quietly run into broken imports, failed file uploads, unsaved product variants and a slow checkout. The causes are usually one of four: the new hard memory limit, temporary mitigations that were never removed, processes still running the old PHP, or a forced move off an end-of-life version. The article explains how to recognize each problem, how to fix it and what to check first, and whether you need to change passwords and keys.
 

Website Broken After the PHP Security Update? What the php2shell Fixes Quietly Break in E-commerce

Your host patched PHP. Now product images won't upload, the nightly import stops halfway, or checkout feels slow. Here's why, and what to check.

On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2 and both allowing remote code execution without a login. The pair is known as "php2shell". A public exploit circulated before the patch, and Amazon's threat intelligence saw the first attack attempt on its honeypots on October 17.

Hosts patched fast. That's good. But most articles stop at "update PHP now". This one is about the day after: what can go wrong in an online store once the patch and the emergency fixes are in place, how to recognize it, and how to fix it.

Can a PHP security patch break my website?

Usually not by itself. A point release within the same branch, say 8.3.35 to 8.3.36, is binary-compatible and a drop-in replacement. Updates that break themes, plugins and extensions are jumps between versions, like 8.1 to 8.3.

So if your site misbehaves after this week, the cause is almost always one of four things:

1. A real behavior change inside the patch - in how PHP handles memory.
2. Temporary mitigations your host or admin applied and never removed.
3. Processes that still run the old, unpatched PHP.
4. A forced upgrade from an end-of-life PHP version.

Let's go through them.

Why does my import, reindex or feed stop halfway with no error?

Because the patch introduced a hard memory limit.

The fix adds a new setting, `memory_hard_limit_percent`. `memory_limit` becomes a soft limit, and a second, higher limit now sits above it: by default twice your `memory_limit`, up to 1G; above 1G it's `memory_limit` plus 1G.

Crossing the soft limit gives the familiar error:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted

Crossing the hard limit ends the process immediately with exit code 137. Shutdown functions and destructors don't run, there's no error page and nothing in the PHP error log. PHP-FPM only logs something like:
WARNING: [pool www] child 15646 exited with code 137 after 2.123035 seconds from start

The actual message is only recorded if the pool has `catch_workers_output = yes`, which Debian's default pool doesn't set:
Hard memory limit of 268435456 bytes exhausted (tried to allocate 400003072 bytes)

And nginx returns a 502 with:
recv() failed (104: Connection reset by peer) while reading response header from upstream
Laravel and most error trackers catch fatal errors in a shutdown function, so they see the soft limit but never a hard-limit kill.

Where this hits e-commerce: memory-heavy jobs - product imports from ERP or PIM, Magento reindexing, feed generation for Google Shopping and marketplaces, bulk price updates, PDF invoices, image processing. The job dies mid-run and leaves half-updated data behind.

How to fix it:

• Turn on `catch_workers_output = yes` in your PHP-FPM pools and alert on `exited with code 137`.
• Find the code paths that need more than twice your `memory_limit`. Usually that's a job loading a whole catalog into memory instead of processing it in batches.
• Don't set `memory_hard_limit_percent = 100` - it turns every normal out-of-memory error into a hard kill.
• Re-check server sizing. A worker can now grow to the hard limit, so "workers × memory_limit" is no longer the worst case. If the container limit is lower, the kernel's OOM killer will step in first.

Why can't I upload product images after the hosting PHP update?

Most likely a temporary mitigation is still active. Blocking multipart requests at the web server was one of the measures recommended before the patch, and it breaks every file upload except on explicitly allowed paths.

Typical symptoms:

• 403 Forbidden when uploading product images in the WooCommerce, Magento, PrestaShop or Shopware admin.
• Customers can't attach photos to return or warranty requests.
• B2B customers can't upload order files or CSVs.
• Uploads in Laravel apps, including Livewire, fail.

A related but harmless one: if a custom upload progress bar stopped moving, `session.upload_progress.enabled` was switched off. Some hosts did this on every server and locked the setting on shared plans. The upload itself still completes.

How to fix it: once the patched PHP is serving your site, remove the multipart block from the web server and from Cloudflare or any other proxy, then test uploads and forms.

Why are product variants or attributes not saving?

This is the quietest failure of the lot. One of the recommended hardening steps was lowering input limits, including `max_input_vars` (default 1000).

When a form sends more variables than `max_input_vars`, PHP keeps the first ones and drops the rest. The application never receives them, and the admin still shows "Saved". PHP only leaves a warning in the log:
PHP Warning:  Unknown: Input variables exceeded 1000.

In a store this means: a configurable product with hundreds of variants, a large attribute set, a long shipping rate table or a B2B price list saves only partly. You'll find out when a customer pays the old price, or when finance finds a margin gap.

How to fix it: check `max_input_vars`, `post_max_size` and `max_input_nesting_level` against what your largest admin forms actually send, and restore values your platform needs.

Why did checkout get slow after the PHP patch?

Two common reasons:

• `pm.max_requests = 1` was a mitigation that forces PHP-FPM to start a new worker for every request. It works, but it costs speed. Under load, that shows up first on heavy pages like cart and checkout.
• Read-only mode. Some sites blocked every request except GET and HEAD. The catalog stays up, but logins, forms and checkout stop.

Both should be reverted once the patched build is running.

My host says PHP is patched, but `php -v` shows an old version. Am I safe?

Maybe. Two separate traps here:

• The command line isn't the website. `php -v` checks the CLI binary, which can differ from the PHP your web server uses. Check the version the site reports while serving a request.
• Distributions keep old version numbers. Ubuntu, Debian and Red Hat backport fixes without changing the upstream version, so a patched Ubuntu 24.04 still reports something like 8.3.6. Read the package changelog or the distribution's advisory. One quick check: on patched builds, `php -r 'var_dump(ini_get("memory_hard_limit_percent"));'` returns an empty string; on unpatched ones it returns `false`.

And if you manage servers yourself: Laravel Forge's automatic security updates do not patch PHP. You update each server yourself.

Which processes still run the old PHP?

Updating the package isn't enough. Every process that runs PHP must be restarted: PHP-FPM, Apache with mod_php, Octane and queue workers. With mod_php, a graceful restart keeps the old library loaded - Apache needs a full stop and start.

In e-commerce, the forgotten ones are:

• Magento message queue consumers and cron
• Laravel Horizon and queue workers
• ERP, PIM and OMS sync daemons
• Feed and export generators running under supervisor or systemd

To check whether anything is still running a deleted library, this should print nothing:
grep -lE ' /(usr|lib|opt).*deleted$' /proc/[0-9]*/maps

Do I need to change passwords and API keys after php2shell?

If the server was reachable before it was patched - yes, it's the safe call. The researchers showed the bugs can leak live worker memory, which can hold passwords and API keys, and a memory leak leaves no web shell or new process behind. Patching doesn't remove anything an attacker already took or left.

For an online store, rotate:

• payment gateway API keys and webhook secrets
• ERP, PIM, OMS and marketplace API tokens
• database passwords
• admin accounts and SMTP credentials

Then look for web shells, new cron jobs and new admin users. When checking logs, start from October 17, not October 21.

My store runs PHP 7.4 or 8.1. What now?

This is where things break for real.

PHP released fixes only for 8.2 to 8.5. Some vendors backport fixes to older branches, but PHP 7.3 and older on cPanel without CloudLinux, and any PHP on CentOS 7, will get no fix at all. You're not alone: 22.7% of the live sites mySites.guru monitors run PHP 8.1 or older.

And 8.2 itself reaches end of life on December 31, 2026, so if you're moving anyway, aim for 8.3 or newer.

What typically breaks in a jump like 7.4 → 8.3:

• payment and shipping modules from abandoned vendors
• ionCube-encoded extensions that need a loader for the new PHP version
• old themes and template overrides
• platform versions pinned to old PHP: older Magento 2.x releases, PrestaShop 1.6 and early 1.7, Joomla 3, OpenCart 3
• custom code relying on behavior that newer PHP deprecated or removed

The right order is: platform and extensions first, PHP second, with a staging copy and a full test of checkout, payments and integrations before the switch.

The day-after checklist

Today

• Confirm the PHP version the site reports while serving a request.
• Restart all PHP processes, including workers, consumers and cron-driven jobs.
• Get a written list from your host of every temporary mitigation applied, and when it will be removed.

This week

• Smoke-test the money paths: image upload, CSV import, saving your largest product, a full order with the payment callback, reindex and feeds.
• Search PHP-FPM logs for `exited with code 137`; enable `catch_workers_output`.
• Restore a real `memory_limit` if it was set to -1 - after the patch, -1 means no soft and no hard limit. Check the CLI too: Debian ships `memory_limit = -1` for it by default.
• Check `max_input_vars` and `post_max_size` against your largest admin forms.
• If you were exposed: look for signs of compromise and rotate secrets.

Before Black Friday

• Plan the move off PHP 8.1 and older, and from 8.2 to 8.3+.

FAQ

 

What is php2shell?

The nickname for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, fixed on October 21, 2026. Both allow unauthenticated remote code execution.

Which PHP versions are fixed?

8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older have no official release.

Will updating WordPress, WooCommerce or Magento protect me?

No. The flaws are in PHP itself, below the platform. Only the PHP update fixes them.

Does turning off session upload progress protect my site?

Partly. It blocks one confirmed path for one of the two bugs. Updating is the only complete fix.

What does "exited with code 137" mean after the PHP update?

In the PHP-FPM log, it means the process hit the new hard memory limit introduced by the patch. "Exited on signal 9 (SIGKILL)" is different - usually the kernel's OOM killer.

Is it safe to remove the temporary mitigations now?

Once the patched PHP is serving your site and every PHP process has been restarted - yes. You can leave upload progress off if you don't use it.