As of October 26, 2026. Every host I checked for my clients has installed the fix by now. There are millions of attack attempts, and on October 26 the first successful attack was confirmed, on a test server run by security researchers with unfixed PHP. Germany’s federal cyber security agency BSI knows of no exploitation at scale so far. The first attack attempts came before the fix. Two things matter now: have the fix confirmed, and look for signs of a break-in. What is behind the flaw is explained in the guide PHP2Shell: what the critical PHP flaw means.
Find out the PHP version
What matters is the PHP version your website is served with. This is how to find it:
- 01
WordPress
Tools > Site Health > Info, section “Server”, line “PHP version”. It shows the exact version, such as 8.3.36.
- 02
Joomla
System > System Information, line “PHP Version”.
- 03
Shopware and others
In your host’s control panel, in the domain’s PHP settings. It often shows only the main version, such as 8.3; your host can tell you the exact one.
The version on the command line (php -v), for example over SSH, can differ from the one the website runs on, on hosting plans too. What counts is the web server’s.
Compare it with the fixed versions
Same number, still fixed
Many servers do not use the PHP project’s own builds but those of their Linux distribution or their host. These often build the fix in without changing the version number: Ubuntu 24.04 shows 8.3.6 before and after, and at hosts I have seen fixed builds that still show 8.3.35 or 7.4.33. So an older number does not necessarily mean the website is vulnerable. Only your host or administrator can confirm whether your server runs the fixed build.
Installed does not mean active
A fixed version only takes effect once the PHP processes have been restarted. If in doubt, ask about that too.
Another flaw since October 23
The PHP project has reported another flaw (CVE-2026-115560) that has no fix yet; it comes with the next regular PHP release. It can only be exploited if an application switches a particular session setting at runtime, which the PHP project calls unlikely. The setting session.upload_progress.enabled = 0 prevents it, and your host can set it.
| Your main version | Fixed from |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 and older | no new release from the PHP project, ask your host and switch (step 05) |
Ask your host
If your version is not clearly fixed, ask your host in writing, by email or through the contact form in the control panel. You can use this template; replace the details in angle brackets.
Subject: PHP2Shell (CVE-2026-109618, CVE-2026-109619): status for <your domain> Hello, regarding the critical PHP vulnerabilities PHP2Shell (CVE-2026-109618 and CVE-2026-109619), please briefly confirm the following for my website <your domain>, customer number <your customer number>: 1. Does the website already run on a fixed PHP version (8.5.12, 8.4.27, 8.3.36, 8.2.35 or a package with the fix built in), and were the PHP processes restarted afterwards? 2. If not: when will the fix be installed? 3. Is there a protective measure on your side until then? 4. If my website still uses PHP 8.1 or older: is there a fix for it, or should I switch to a newer version? Security agencies advise taking servers without the fix offline temporarily, so I would appreciate a prompt reply. Thank you and best regards <your name>
No fix yet: protect the website in the meantime
As long as your host has not confirmed the fix, the BSI advises disconnecting servers from the internet temporarily. These are the options:
A maintenance page without PHP
The web server delivers a plain HTML page for every address, and PHP does not run at all. Many hosts can switch a domain to a static page in the control panel or do it for you. For stores and websites with customer data, I consider this the right way until the fix is in place. Search engines treat a maintenance page with status 503 as temporary.
The WordPress or Shopware maintenance mode. It is delivered by PHP itself, and the flaw strikes before it takes effect.
Block form uploads at the web server
The known attacks use requests in the multipart/form-data format that forms with file uploads send. Rejecting these requests at the web server, before PHP sees them, keeps the website online but closes only the known path. Image uploads in the back end, many contact forms and some checkout steps stop working. Test forms and checkout afterwards.
Source: SansecCloudflare
If your website already runs through Cloudflare, rules against the known attacks are active there, on the free plan too. Cloudflare itself calls this a stopgap until the update.
Source: CloudflareBoth are stopgaps, not a solution. Only the fixed PHP version protects the website.
PHP 8.1 or older: switch now
PHP 8.1 and older versions no longer get new releases from the PHP project. For PHP 7.4 to 8.1 it has only published source code fixes, which some hosts and Linux distributions have built in; for 7.3 and older there is no fix. Ask your host whether your version is fixed. The only lasting solution is to switch: change to PHP 8.3 or 8.4 in your host’s control panel; PHP 8.2 only gets security updates until the end of 2026.
- 1Back up files and database first.
- 2Switch to PHP 8.3 or 8.4 in the control panel.
- 3Then check the most important pages, the forms and, for stores, the checkout.
The old version is no way out, because it stays vulnerable. Then a maintenance page without PHP belongs in front until the repair. Safest is a switch that was tested on a copy of the website first.
Look for signs of a break-in
According to Amazon, a first attack attempt came as early as October 17, four days before the fix was released. A website that is fixed by now may have been hit before.
New administrator accounts
Accounts nobody created. In WordPress under Users, in Shopware under Settings > System > Users.
PHP files in the uploads folder
Only images and documents belong there: in WordPress in wp-content/uploads, in Shopware in public/media.
New or changed files
Files that appeared or changed since October 17, 2026, without anyone updating anything.
Unknown cron jobs
Scheduled tasks in your host’s control panel that nobody set up.
Notices from your host
Emails about spam being sent, unusually high load or a find by the malware scanner.
- 1Take the website offline with a maintenance page without PHP.
- 2Make a copy of files and database for the analysis, do not delete anything blindly.
- 3Change all credentials: administrators, hosting control panel, FTP and SSH, database, interfaces and payment providers.
- 4Restore a clean state from a backup from before October 17, 2026, and only go back online once PHP is fixed.
Customer accounts, orders or inquiries from the contact form can be affected. This is not legal advice; if in doubt, clarify it with your data protection officer.
I describe this in detail in the guides WordPress hacked and Online store hacked.
Your own server: update and restart
If you run your own server or VPS, you or your administrator are responsible for PHP.
- 01
Update the packages
Through your distribution’s package manager. The security notices name the fixed packages, such as Ubuntu USN-8948-1, Debian 13 DSA-6574-1 and Debian 12 DLA-4848-1. Compare the package version, not the PHP version number.
Ubuntu · Debian - 02
Restart PHP-FPM and Apache
Only then does the fixed build run. Containers with PHP need to be rebuilt.
- 03
Panels and third-party repositories
Plesk, cPanel and other panels ship their own PHP packages, which you update through the panel. Not every third-party repository had the fix on October 21.
Help Net Security - 04
Until the update
session.upload_progress.enabled = 0 in php.ini or the FPM pool configuration reduces the attack surface, but according to the PHP project only for some of the attack paths. Set in a .user.ini file, it has no effect. It also protects against the further flaw CVE-2026-115560 of October 23; keep it set until the next PHP release.
PHP project · PHP project, Oct 23, 2026
Help from me
If you would rather not check this yourself, send me a message or call me. Please have the login details for your hosting account ready.
Check the PHP version
I find out which PHP version your website runs on and whether it is fixed.
Ask your host
I clarify with your host when the fix comes and what applies until then.
Protect it in the meantime
If the fix is still missing, I put a maintenance page without PHP in front and remove it once the fix is installed.
Check for traces
I look for new accounts, unknown files and scheduled tasks.
With the Doppelgänger, your website also runs as an exact copy on a server of its own in Germany. Every night, every file of the live website is compared with the approved state, so a break-in shows up early. I test a switch of the PHP version on the copy before it goes live.
Sources: PHP project, security advisory of Oct 21, 2026 · BSI, IT security notice 2026-297981-1032, version 1.2 of Oct 22, 2026 (in German) · Sansec, PHP2Shell, updated Oct 22, 2026 · Amazon Threat Intelligence, Oct 21, 2026 · watchTowr, PHP2Shell FAQ · Cloudflare, Oct 21, 2026 · Ubuntu, USN-8948-1 · Debian Security Tracker · Help Net Security, Oct 21, 2026 · PHP project, notice on CVE-2026-115560 of Oct 23, 2026 · BleepingComputer, Oct 26, 2026
Quick answers.
How do I find out my website's PHP version?
In WordPress under Tools > Site Health > Info; the PHP version is in the Server section. In Joomla under System > System Information. For Shopware and other systems, in your host's control panel in the domain's PHP settings. It often only shows the main version, such as 8.3; your host can tell you the exact one.
My website shows PHP 8.3.6. Is it unprotected?
Not necessarily. Many servers use the PHP packages of their Linux distribution, such as Ubuntu or Debian, or their host's own packages. They build the fix into their packages without changing the version number; Ubuntu 24.04 shows 8.3.6 before and after. Only your host or administrator can confirm whether your server runs the fixed build.
Does the WordPress or Shopware maintenance mode help?
No. Both maintenance modes are delivered by PHP, and the flaw strikes before WordPress or Shopware start. As a stopgap, only a maintenance page the web server delivers without PHP protects. Many hosts can switch a domain to a plain HTML page in the control panel or do it for you.
Should I take my website offline?
If your host has not confirmed the fix yet, the BSI advises disconnecting servers from the internet temporarily. For online stores and websites with customer accounts or forms with personal data, I consider that the right way until the fix is installed. Search engines treat a maintenance page with status 503 as temporary.
My website still runs on PHP 8.1 or older. What now?
Ask your host whether it has fixed your version itself; some hosts have. The only lasting solution is to switch to PHP 8.3 or 8.4 in your host's control panel. These versions are fixed and still maintained. Make a backup first and then check the most important pages, the forms and, for stores, the checkout. If the website does not work with the new version, going back to the old one is no solution, because it stays vulnerable; then a maintenance page without PHP belongs in front until the repair.
How can I tell whether my website has already been attacked?
Typical signs are new administrator accounts nobody created, PHP files in the uploads folder where only images belong, unknown scheduled tasks (cron jobs) in the control panel and notices from your host about spam or malware. What to do if you find something is in the guides WordPress hacked and Online store hacked.
Do I have to report a break-in to the data protection authority?
If personal data could be affected, such as customer accounts, orders or inquiries from the contact form, usually yes: within 72 hours of becoming aware of it (Art. 33 GDPR), unless a risk to the people affected is unlikely. This is not legal advice; if in doubt, clarify it with your data protection officer.