Security alertUpdated
Critical PHP flaw: if your website runs on PHP, act now.
Through two vulnerabilities known as PHP2Shell, an attacker can run code on your server without logging in. WordPress, WooCommerce, Drupal, Joomla, Magento and Laravel sites are all exposed. The fix has been out since 21 October — we check your setup, patch it, and then make sure nothing happened in the meantime.
- Identifiers
- CVE-2026-109618, CVE-2026-109619
- Severity
- Critical — CVSS 9.2
- Login needed
- No
- Affected
- PHP 5.4 up to 8.5
- Fixed in
- 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35
- No official fix
- PHP 8.1 and older
- Exploitation
- Attack attempts reported by Cloudflare and watchTowr
Free check
Is your website affected? Find out in 10 seconds.
Enter your address and we read what your server reveals publicly. Or type your PHP version if you already know it.
Risk
What it means for a company.
Your server can be taken over
Code execution without a login: an attacker can install malware, send spam, redirect your visitors or skim card details from your shop’s checkout.
Your server’s memory can be read
Even without running code, the flaw can leak server memory — passwords, API keys, session tokens — whether or not your site has a login.
The data protection duty is yours
If personal data leaks, GDPR generally requires reporting it to the data protection authority within 72 hours. An update costs far less.
Who is affected
Which PHP version do you run?
Every PHP installation that serves web pages is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php carries the highest risk.
8.5.12, 8.4.27, 8.3.36, 8.2.35 or later
Patched
Nothing to do on PHP — check that every server and subdomain runs it.
8.2 – 8.5, older patch release
Vulnerable
Update to the patched release of your branch. Note that 8.2 reaches end of life on 31 December 2026.
7.4 – 8.1
Vulnerable, no official release
Move to 8.3 or 8.4, or use your host’s or distribution’s patched package. PHP only published a source-level backport.
5.4 – 7.3
Vulnerable, no fix
Upgrade to a supported version urgently; until then, stopgap protection or maintenance mode.
Shoprenter, Unas, Shopify, Wix
Provider’s responsibility
They run and patch the servers. Custom add-ons or your own servers next to them may still be exposed.
| Your PHP | Status | What to do |
|---|---|---|
| 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later | Patched | Nothing to do on PHP — check that every server and subdomain runs it. |
| 8.2 – 8.5, older patch release | Vulnerable | Update to the patched release of your branch. Note that 8.2 reaches end of life on 31 December 2026. |
| 7.4 – 8.1 | Vulnerable, no official release | Move to 8.3 or 8.4, or use your host’s or distribution’s patched package. PHP only published a source-level backport. |
| 5.4 – 7.3 | Vulnerable, no fix | Upgrade to a supported version urgently; until then, stopgap protection or maintenance mode. |
| Shoprenter, Unas, Shopify, Wix | Provider’s responsibility | They run and patch the servers. Custom add-ons or your own servers next to them may still be exposed. |
What we do
What we do, starting today.
One accountable team from first check to written report — so you don’t have to work out which advice applies to your setup.
- 01
Inventory
We find every place PHP runs: live site, staging and forgotten subdomains, containers, admin panels. We check the version in the web context, not just on the command line.
- 02
Patch
We update PHP or coordinate with your host. On old PHP (7.4–8.1) we move you to 8.3 or 8.4 and test that your plugins and theme still work.
- 03
Stopgap protection
If the update can’t happen right away, we narrow the attack surface with the official interim settings and request filtering — knowing they are no substitute for the fix.
- 04
Follow-up checks
We review the logs for the known traces, check admin users and changed files, and rotate passwords, API keys and WordPress security keys where needed.
- 05
Written report
What we found, what we fixed, what risk remains. Something you can hand to management or your insurer.
Stopgap
Can’t update today? Do this in the meantime.
The interim settings from the PHP security advisory. They reduce exposure, but by PHP’s own words they do not make an installation safe.
memory_limit = -1Set with php_admin_value so the application can’t override it (CVE-2026-109618).
post_max_size = 8MKeep it low; up to 32M if you need uploads.
session.upload_progress.enabled = 0CVE-2026-109619.
fatal_error_backtraces = 0PHP 8.5 only.
Then restart every PHP worker (PHP-FPM, Apache).
- With memory_limit = -1 a single request can use all of the server’s memory: watch it.
- WordPress or shop maintenance mode does not help: PHP parses the request before the application checks the flag.
- Cloudflare’s WAF rules only help if your server accepts traffic from Cloudflare alone.
- Don’t install unknown “fix” plugins or copy-pasted snippets.
Warning signs
Signs your server may have been targeted.
- Unusual multipart (upload-style) requests followed by memory-limit errors
- Repeated HTTP 500 errors
- Unusually long or malformed PHPSESSID cookies
- Unexplained PHP worker restarts
None of these proves a break-in. If you see them: update, treat the server as potentially compromised, and rotate the passwords and keys it holds.
Questions, answered.
What is PHP2Shell?
The name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. They are memory-safety bugs in how PHP handles fatal errors, especially running out of memory: an attacker can run code on the server, or read its memory, without logging in. PHP released the fixes on 21 October 2026.
Is my WordPress site affected?
Yes, if your server runs an unpatched PHP between 5.4 and 8.5 — whatever your WordPress version and plugins. Researchers demonstrated the attack without login on current WordPress, Drupal, Joomla and Magento. The bug is in PHP, not WordPress, so a WordPress update won’t fix it.
I’m on shared hosting. Won’t my host handle it?
Your host usually updates PHP on the server, but on most plans you choose which PHP version your site uses. If it is set to 8.1 or older, there may be no fix for it. Check the selected version in your control panel and ask your host when the patch was installed.
I have a Shoprenter or Unas shop. Do I need to do anything?
Hosted shop platforms (Shoprenter, Unas, Shopify, Wix) run and patch their own servers, so there’s nothing to do on PHP. Any site, blog or integration you run on your own server alongside it is worth checking.
Is being behind Cloudflare enough?
No. Cloudflare deployed rules for the known attack patterns, even on the free plan, but they are a stopgap and only count if your server accepts traffic from Cloudflare alone. They don’t replace the update.
We run PHP 7.4. What now?
The PHP project ships no official release for 8.1 and older (only a source-level backport for 7.4–8.1). The real fix is moving to 8.3 or 8.4. With old WordPress plugins or custom code that takes testing — which we do.
How do I know if my site was hacked?
Only the server’s logs and files can tell for sure. Typical traces: memory-limit errors after unusual requests, many 500 errors, odd PHPSESSID cookies. If the site was vulnerable before the patch, rotating passwords and API keys is worth it — we do that during the follow-up checks.
How much does the fix cost?
We give you a fixed price before touching anything. It depends on how many servers and which PHP versions are involved: an update within a supported branch is quick work; a move from 7.4 needs more testing. For our partners, security updates are part of the monthly fee.
Sources
Sources.
This page is based on the official PHP advisory and the researchers’ publications. We update it as the situation changes.
Don’t wait for the first incident.
Send us your address. We tell you the same day whether you’re affected and what fixing it costs.