Your result
The result says whether the site runs on PHP, which version it announces, who hosts it, and what to do today.
Not sure? Send me the link to your site and I’ll tell you within 24 hours whether it is affected and what to do. Free, no commitment.
Send my website link Prices and how the remote work goesRather have me handle it? PHP and website update done remotely, after a backup and a test on a copy. Free diagnosis, work from €190, reply within 24 hours.
See the offer and pricesOn 21 October 2026, PHP published fixes for two critical vulnerabilities that let an attacker take over a server without a password. They affect WordPress sites, PrestaShop or WooCommerce stores, business software, intranets, extranets and any tool installed on a server. That same day, the French State took the prefecture and Météo-France websites offline as a precaution, then the tax portal, the CAF, Ameli and URSSAF the next day; the Netherlands, Finland and the UK did the same. This tool reads the home page of your site, spots PHP, its version and your hosting provider, and tells you what to do: nothing, check, or update today.
Tool built by Léo Guillaume, freelance developer near Rennes, France. I update and secure websites, online stores and business software for small businesses, remotely, and I reply within 24 hours.
Updated on
What happened
Two vulnerabilities in the core of PHP, nicknamed PHP2Shell, known since a leak on 20 October and fixed the next day. Here is what the official sources say, without drama.
9.2 / 10
CVE-2026-109618 and CVE-2026-109619 allow code to run on the server from a plain web request, before the site itself runs. Every way of serving PHP is concerned (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed), mod_php being the most exposed.
Source: php.net, security advisory of 21 October 202621 October 2026
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both flaws. PHP 8.1 and older receive no new version: only source patches exist for 7.4, 8.0 and 8.1, to compile or to obtain from your host. PHP 8.2 ends anyway on 31 December 2026.
Source: php.net, releases of 21 October 2026Alert CERTFR-2026-ALE-014
CERT-FR (ANSSI) recommends isolating the affected systems, then moving to a maintained and fixed version. The workarounds (disabling session.upload_progress, blocking multipart uploads) reduce the attack surface for only one of the two flaws: they do not replace the update.
Source: CERT-FR (ANSSI), 21 October 2026From 17 October
Amazon’s honeypots (MadPot) received a first exploitation attempt on 17 October, four days before the fixes, from an anonymisation network; more followed on the 21st between 02:00 and 08:00 UTC, before the embargo was lifted. Cloudflare enabled firewall rules for all its customers from 03:02 UTC and sees attackers changing their payloads to get around them. On the 22nd, Wordfence saw the attacks continue, with no known compromise. A site that is not updated stays exposed to each new variant, firewall or not.
Source: Amazon Threat Intelligence, 21 October 2026; Cloudflare; Wordfence, 22 OctoberPrefectures, tax portal, CAF, Ameli
On the afternoon of 21 October, the Interior Ministry took every prefecture website offline at the request of ANSSI (“preventive maintenance”), Météo-France closed its forecast and weather-warning sites, and part of the tax portal was unavailable. On the 22nd, the CAF (family benefits), Ameli (health insurance), URSSAF and CNES went into maintenance in turn, and Orange suspended a few sites and apps of its subsidiaries. No hack reported: a precaution while the update is installed. On 23 October at 11:40 Paris time, Météo-France, ameli.fr and urssaf.fr were answering again; caf.fr, impots.gouv.fr and the prefecture websites still showed a maintenance page.
Source: France 3, 21 October; Clubic, 22 October at 10:53 Paris time; websites checked on 23 October at 11:40 Paris timeNetherlands, Finland, UK, Denmark
The Netherlands switched off DigiD, MijnOverheid and the site of its own cyber security centre, Finland its public online services, British councils and the Met Police their websites, Denmark its school platform. When states unplug rather than take the risk, a business site running PHP has no reason to feel safe.
Source: The Record, 21 October 2026What I do for you: I read the version actually served, I update PHP or change the branch, I check that the site, the store or the tool still works, and I write down what was done. Remotely, within 24 hours.
Hour by hour
Four days between the first attack attempt and the fix, then two days of public sites taken offline. Times in UTC (Paris is UTC+2).
Amazon’s honeypots receive a PHP2Shell exploitation attempt from an anonymisation network. Nothing is public yet: the flaws are still under embargo.
The two CVE identifiers start circulating around 15:00 UTC. That evening, watchTowr confirms the flaws are real and PHP announces a fix for the next day at 14:00 UTC.
For every customer, free plan included. During the day attackers change their payloads to get around them: the filter helps, it does not replace the update.
Proof-of-concept exploits circulate from 02:00 UTC and Amazon sees new attempts from other infrastructure. Sansec observes the first attacks at 07:43 UTC, seven hours before the fix. o2switch had disabled session.upload_progress at 06:07 UTC; Infomaniak opens a maintenance at 13:00 UTC.
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, slightly ahead of schedule. Nothing for PHP 8.1 and older, apart from source patches to compile.
The French Interior Ministry takes the prefecture websites offline at the request of ANSSI, Météo-France closes its own, part of the tax portal goes into maintenance. The Netherlands, Finland, the UK and Denmark do the same.
o2switch waits for the CloudLinux packages, OVHcloud rolls out firewall rules and a maintenance, Infomaniak announces the end of its own on the 22nd at 01:00 UTC. Your site is fixed only once the displayed version has changed.
The CAF, Ameli, URSSAF and CNES go into maintenance in turn; Orange suspends a few sites and apps of its subsidiaries while the fixes are installed. Wordfence sees the attacks continue, with no known compromise. On the 23rd at 09:40 UTC, Météo-France, ameli.fr and urssaf.fr answer; caf.fr, impots.gouv.fr and the prefectures are still under maintenance.
Who is affected
The flaw is in PHP, not in one CMS in particular. Anything served by PHP and reachable from the internet is affected, whatever name you give it.
Most business websites run on one of them, so on PHP. The fix happens on the server, not in the CMS.
An online store takes payments and keeps addresses: the most profitable target for an attacker, and the most costly to lose.
A custom tool built in PHP (Laravel, Symfony or in-house code), even reserved to your staff or clients by password, is affected: the flaw plays before the login page.
Dolibarr, GLPI, Nextcloud, Moodle, a phpBB forum, a wiki, a ticketing tool: if they are reachable from the internet, they are exposed like a public site.
Wix, Squarespace, Shopify, Webflow, Jimdo, Google Sites do not run PHP for your site, and maintain their servers themselves. Nothing to do on your side.
An application in Node.js, Python or .NET is not touched by this flaw. Node.js did publish its own security fixes on 21 October: same reflex, same day.
Branch by branch
The fix only exists for the branches still maintained. Compare the number shown by your hosting with this list.
| Your branch | Where it stands | Fixed version |
|---|---|---|
| PHP 8.5 | Newest branch, security fixes until December 2029 | 8.5.12Published on 21 October 2026 |
| PHP 8.4 | Active branch, security fixes until December 2028 | 8.4.27Published on 21 October 2026 |
| PHP 8.3 | Security fixes until December 2027 | 8.3.36Published on 21 October 2026 |
| PHP 8.2 | Security fixes until 31 December 2026 | 8.2.35Last fixed branch: plan the move to 8.3 or 8.4 before the end of the year |
| PHP 8.1 | End of life since 31 December 2025 | No official versionSource patch to compile, or a package backported by the host, otherwise change branch |
| PHP 8.0 and 7.4 | End of life | No official versionSource patch published by PHP for 7.4 and 8.0, to compile yourself |
| PHP 7.3 and older, PHP 5 | End of life for years, affected since PHP 5.4 according to watchTowr | NothingChanging branch is the only way out, after a test of the site on a copy |
Newest branch, security fixes until December 2029
Published on 21 October 2026
Active branch, security fixes until December 2028
Published on 21 October 2026
Security fixes until December 2027
Published on 21 October 2026
Security fixes until 31 December 2026
Last fixed branch: plan the move to 8.3 or 8.4 before the end of the year
End of life since 31 December 2025
Source patch to compile, or a package backported by the host, otherwise change branch
End of life
Source patch published by PHP for 7.4 and 8.0, to compile yourself
End of life for years, affected since PHP 5.4 according to watchTowr
Changing branch is the only way out, after a test of the site on a copy
The number that counts: the one your site really uses (X-Powered-By header, phpinfo page, WordPress Site Health), not the one of a command line on the server. And on Debian or Ubuntu, a package can carry the fix without changing its number: in that case, ask for a written confirmation.
Host by host
On shared hosting, the host installs the new PHP version. Here is what each one has announced since 21 October 2026, re-read on the morning of 22 October (Paris times); the situation changes by the hour, and only the version shown in your hosting panel counts.
| Host | What it announced or did | Where it stands |
|---|---|---|
| o2switch | session.upload_progress disabled at 08:07, then waiting for the CloudLinux packages for PHP 8.3.36 and 8.4.27 (binaries still from 6 October at 16:40) | Temporary protection, installation not announcedClubic reading of 21 October, 18:25; nothing new on the 22nd at 09:00 |
| OVHcloud | Workaround at 10:00, firewall rules, then PHP 7.4 to 8.5 fixed on all shared clusters | Fixed, maintenance open until the 22nd at 13:18OVHcloud status page, 21 October 19:53 |
| Infomaniak | Maintenance opened on 21 October at 15:00, until the 22nd at 03:00: mitigations and fixes deployed, no action required, except moving a site on an unmaintained PHP version | Fixes deployed since the 21st at 17:04Infomaniak status page, 21 October, re-read on the 22nd at 09:00 |
| SiteGround | Protection rules on all servers and affected features disabled before the fixes were published | Protection announced, no action requiredSiteGround blog, 21 October 13:30, no update on the morning of the 22nd |
| Cloudflare (in front of your site) | Default firewall rules for all customers, free plan included, since 03:02 UTC; modified attack payloads observed | Partial filter, the server still needs the updateCloudflare blog, 21 October |
| IONOS | Security update being installed on all systems, short interruptions possible | In progress, completion announced within 24 hoursIONOS status page, 21 October 18:11 then 22 October 06:54 |
| Hostinger | Protection added, PHP update complete on all managed hosting servers | Fixed, except VPS and PHP 8.1 or olderStatus page, 22 October 08:44 |
| PlanetHoster | Fixes still being deployed, file uploads blocked | No action announced, except on 8.1 or olderPlanetHoster notice, 21 October 16:00 then 22 October 06:30 |
| LWS | No public statement found | Ask supportSearch on the morning of 22 October |
| Gandi | No public statement found | Ask supportSearch on the morning of 22 October |
| alwaysdata | Fixed versions deployed on all servers, temporary measures lifted | Fixed, no action requiredalwaysdata status page, 21 October 18:02 |
session.upload_progress disabled at 08:07, then waiting for the CloudLinux packages for PHP 8.3.36 and 8.4.27 (binaries still from 6 October at 16:40)
Clubic reading of 21 October, 18:25; nothing new on the 22nd at 09:00
Workaround at 10:00, firewall rules, then PHP 7.4 to 8.5 fixed on all shared clusters
OVHcloud status page, 21 October 19:53
Maintenance opened on 21 October at 15:00, until the 22nd at 03:00: mitigations and fixes deployed, no action required, except moving a site on an unmaintained PHP version
Infomaniak status page, 21 October, re-read on the 22nd at 09:00
Protection rules on all servers and affected features disabled before the fixes were published
SiteGround blog, 21 October 13:30, no update on the morning of the 22nd
Default firewall rules for all customers, free plan included, since 03:02 UTC; modified attack payloads observed
Cloudflare blog, 21 October
Security update being installed on all systems, short interruptions possible
IONOS status page, 21 October 18:11 then 22 October 06:54
Protection added, PHP update complete on all managed hosting servers
Status page, 22 October 08:44
Fixes still being deployed, file uploads blocked
PlanetHoster notice, 21 October 16:00 then 22 October 06:30
No public statement found
Search on the morning of 22 October
No public statement found
Search on the morning of 22 October
Fixed versions deployed on all servers, temporary measures lifted
alwaysdata status page, 21 October 18:02
How to check yourself: in cPanel (o2switch, PlanetHoster, LWS), Plesk (IONOS) or the customer area (OVHcloud, Infomaniak), open the “PHP version” setting of your site. 8.2.35, 8.3.36, 8.4.27 or 8.5.12 are fixed. On 8.1 or older, the host will not fix it: change branch after a backup.
Sources: status pages of OVHcloud, IONOS, Hostinger, Infomaniak and alwaysdata, PlanetHoster notice, SiteGround and Cloudflare blogs, Clubic article of 21 October (18:25), re-read on the morning of 22 October. An old version number alone does not prove the flaw (some Linux distributions backport fixes without changing the number): when in doubt, ask for a written confirmation.
Check your PHP version
The tool above reads what the server shows. For the exact version, look in your hosting panel or in WordPress: here is the path, from the official guides re-read on 21 October 2026 (French hosts, menu labels translated).
Tools, then Site Health, Info tab, Server section: the “PHP version” line. Updating WordPress, a theme or a plugin does not change this number: only the hosting does.
cPanel, Software section, “Select PHP Version” tool: the drop-down shows the current version. Pick 8.3 or 8.4 then “Apply”. The extensions ticked by default stay ticked.
Customer area, Web Cloud, Hosting plans, your plan, General information tab: “Global PHP version”. To change it, Configuration frame, “…” button, “Modify the configuration”. Or the app.engine.version line of the .ovhconfig file at the FTP root.
Customer area, Hosting section, PHP menu, “Open”: tick the domain, “Change PHP version”, choose the version and save. The switch takes a few minutes.
Manager, Web Hosting, click the product name, “More information”, “Edit”, choose the version, “Save”. The change is immediate and going back to a vulnerable version is then blocked.
Plesk: Websites & Domains, PHP section of each site. On a server, php -v gives the command-line version; the phpinfo() page or the X-Powered-By header says which one really serves the site, then apt or dnf to update and a restart of PHP-FPM.
In order
The same path for a showcase site, a store or business software. Count an hour if you control the hosting, a day if you depend on a provider.
Enter your website link in the tool above. Then confirm in your hosting panel (cPanel, Plesk, customer area) or, on WordPress, in Tools, Site Health, Info, Server. The version that counts is the one the site uses, not the one of a command line.
On shared hosting, the host installs 8.2.35, 8.3.36, 8.4.27 or 8.5.12 on its servers; you change branch yourself if you are on 8.1 or older. On your own server, update the package and restart PHP-FPM or Apache. Backup outside the server first.
An announced fix is not an installed fix. Run the tool again, or look at the X-Powered-By header and the PHP info page. Then test the home page, the login to the admin and, for a store, a payment.
Look in the server logs for unusual multipart requests since 20 October. Change the admin passwords if in doubt. And note the date: PHP 8.2 ends on 31 December 2026.
Frequently asked questions
Yes if the server has not been updated, whatever the WordPress version. The fix is in PHP, not in WordPress nor in a security plugin. Check the PHP version in Tools, Site Health, Info tab, Server section, and ask your host if it is not 8.2.35, 8.3.36, 8.4.27 or 8.5.12.
WordPress, PrestaShop, Joomla, Drupal, Magento, WooCommerce, SPIP, TYPO3 and most agency-built sites run on PHP. Wix, Squarespace, Shopify, Webflow and Jimdo do not. For a custom tool, ask the person who built it: Laravel and Symfony are PHP, Node.js, Python and .NET are not. The tool on this page reads these signs on your home page.
On shared hosting, the host installs the new PHP version on its servers, for the 8.2 to 8.5 branches. You have nothing to install, but you must check in a day or two that the version has changed. If your site stayed on PHP 8.1, 8.0 or 7.x, the host will not fix it: you have to change the version in cPanel, Plesk or the customer area, after a backup and a test.
Three questions, in writing: which PHP version serves the application, has it been updated since 21 October 2026, and which logs were checked. An internal tool reachable from the internet, even with a password, is exposed: the flaws play before the login page. If the provider no longer answers, I can take over the server.
The PHP project no longer publishes versions for these branches. Two options: install the backported package if your host or your Linux distribution provides one, or move to PHP 8.3 or 8.4. Changing branch means checking the CMS, the theme and the extensions, with a backup and a test on a copy. If that is not possible right away, take the application offline or put it behind a web application firewall.
No. CMS updates do not touch PHP, which runs underneath the CMS. A security plugin does not fix the flaw either: it can block some requests, not all. Only a fixed PHP version closes the door.
Look at the server access logs since 17 October, the date of the first attempt seen by Amazon: large multipart POST requests to pages that never receive any are a signal. Look for recent .php files in upload folders (uploads, cache), unknown admin accounts, new scheduled tasks. When in doubt: backup, change the passwords, and if personal data is affected, notify your data protection authority (72 hours in the EU). As of 22 October, Wordfence saw the attacks continue with no known compromise through this flaw: reassuring, but no reason to wait.
Not for this site: these builders do not run PHP for you, and their server is maintained by them. Do check your other tools: a store, an intranet, management software installed at a host or on a company server may run on PHP.
Because of this same flaw. On 21 October the French Interior Ministry took the prefecture websites offline at the request of ANSSI, Météo-France closed its own, and part of the tax portal went into maintenance; on the 22nd, the CAF, Ameli, URSSAF and CNES followed. It is neither an outage nor an announced hack: preventive maintenance while the fix is installed and checked. On 23 October at 11:40 Paris time, Météo-France, ameli.fr and urssaf.fr were answering again, but caf.fr, impots.gouv.fr and the prefecture websites were still under maintenance. Your data is not at stake: the CAF keeps its usual filing deadlines, your personal or business tax account can still be reached through the login links on the maintenance page, and for urgent matters, prefectures post on their social networks.
Once the fix is installed and checked, service by service. Météo-France reopened on the morning of 22 October, ameli.fr and urssaf.fr were answering on the 23rd at 11:40 Paris time. At the same time, caf.fr, impots.gouv.fr and the prefecture websites still showed a maintenance page, with no return date announced; the Interior Ministry speaks of “as soon as possible”. Your tax accounts remain reachable through the login links. This page will be updated.
The nickname given to the two flaws CVE-2026-109618 and CVE-2026-109619: a specially crafted web request lets an attacker run commands on the server (a “shell”) through PHP, without an account or a password. There is no “PHP2Shell virus” to detect on your computer: it is a defect of the PHP engine itself, on the server, fixed by the 21 October 2026 versions.
For a public site taken offline as a precaution (tax portal, CAF, Ameli, prefecture), no: no intrusion has been announced. For your own site left online without the fix during 21 October, yes: change the admin passwords (CMS, FTP, database) once the update is done. And beware of e-mails claiming to come from your host, the tax office or “ANSSI” asking you to “verify your credentials”: scams always follow this kind of news.
It reads the home page of your site once, like a browser, with the server headers, and queries the name servers of the domain. It recognises the PHP version if shown, the platform (CMS, site builder) and often the host. It scans nothing, sends no payload and keeps your address for no more than a few minutes of cache. It cannot see a hidden version, applications on other addresses, or a backported fix without a version change: in those cases, only the host’s answer or access to the server settles it.
Blog
The full article on the vulnerability, and two reads to regain control of a site or a tool nobody looks after anymore.
Two critical vulnerabilities in PHP were patched on October 21, 2026. Are your WordPress sites, PrestaShop or WooCommerce stores, custom applications, or internal networks at risk? Learn who is impacted, what your hosting provider is doing, and what actions you should take today.
OVHcloud web hosting: Where to find your PHP version, how to switch to 8.3 or 8.4 from the customer portal or the .ovhconfig file, which version to select, and what OVH announced on October 21st.
At o2switch, the default cPanel PHP version is 8.1, which no longer receives official patches. Where to navigate to switch to 8.3 or 8.4, which version to choose, and what o2switch did on October 21st.
At IONOS, the PHP version is set per domain through the customer portal. Where to click, which version to choose after the October 21, 2026 vulnerability, and what PHP Extended Support offers.
Hostinger claims 'no action required,' but a site stuck on PHP 8.1 will receive no security updates. Where to find and change the PHP version in hPanel, which version to choose, and what Hostinger announced on October 21.
Infomaniak proactively patched PHP 7.4, 8.0, and 8.1—something few hosting providers do. Here’s what they rolled out hour by hour on October 21st, how to update your PHP version in the Manager, and why you should upgrade even if you’re not directly affected.
PlanetHoster deploys patches and temporarily blocks file uploads. Where to change the PHP version in N0C, cPanel, or WHM depending on your account, which version to choose, and the pitfall of the dropdown menu that goes all the way down to PHP 4.4.
Your Lovable-, Bolt-, or Cursor-built app is running ‘almost’ smoothly? How to determine if it can be salvaged—and how a developer can take it over.
A brochure website and a custom business tool address different needs. How to determine which will truly benefit you, based on what costs you the most right now.
Send me the link to the site, the store or the tool. I check the version actually served, I update PHP or change the branch, I test, and I write down what was done. Reply within 24 hours.