What happened on October 21,
The two vulnerabilities are referenced as CVE-2026-109618 and CVE-2026-109619, with the nickname PHP2Shell. They are rated 9.2 out of 10. In practice, a well-crafted web request is enough to execute code on the server before the site or application even loads. No account, no password, no site bug needed: the flaw is in PHP itself.
The story began with a leak. On Tuesday, October 20, in the late afternoon, a post on Hacker News announced two critical vulnerabilities under embargo. The company watchTowr confirmed that night that they were real, and PHP announced a patch for the following day at 2 PM UTC. In the meantime, pages claiming to publish an exploit circulated, Cloudflare activated firewall rules for all its clients starting at 3:02 AM UTC, and saw attackers modifying their payloads to bypass them. We have since learned that Amazon’s honeypots had received a first exploitation attempt as early as October 17, four days before the patches. The patches were released Wednesday with a slight lead: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
The most telling signal: in the afternoon, the French Ministry of the Interior took all prefecture websites offline at the request of ANSSI, citing « preventive maintenance of all its internet sites exposed to a critical security vulnerability, » and Météo-France closed its forecast and alert sites on its own initiative. Part of the tax authority’s portal was also taken down, according to the press, and the next day the CAF (family benefits), Ameli (health insurance), URSSAF and CNES went into maintenance in turn, while Orange suspended a few sites and apps of its subsidiaries. The Netherlands shut down DigiD and MijnOverheid, Finland its online public services, British local councils and Danish services did the same. None of these sites reported any breaches: it was a precautionary measure, exactly what CERT-FR recommends when you can’t patch immediately. If the government shuts down its own sites rather than risk it, a PHP-powered business site has no reason to think it’s safe.
The game-changing detail: PHP 8.1, 8.0, 7.4, and older versions will no longer receive updates. The project published source patches for 7.4, 8.0, and 8.1, which you can compile yourself or obtain from your host, but no official version will be automatically installed. According to W3Techs, about one in four PHP sites still runs on PHP 7. If that’s yours, no one will fix it for you.
CERT-FR, ANSSI’s team, released alert CERTFR-2026-ALE-014 the same day: isolate affected systems, then switch to a maintained and patched version. Workarounds circulating—like disabling session.upload_progress or blocking file uploads—reduce the attack surface for one of the two flaws. They do not replace the update.
What is PHP2Shell? The nickname for the two vulnerabilities: a specially crafted web request allows executing commands on the server—a « shell »—through PHP, without an account or password. There is no PHP2Shell virus to hunt for on your computer. It’s a flaw in the PHP engine itself, on the server, and it’s fixed by the October 21 versions.
Which PHP versions are patched?
The fix only exists for still-supported branches. PHP 8.5 is updated to 8.5.12, PHP 8.4 in 8.4.27, PHP 8.3 in 8.3.36 and PHP 8.2 in 8.2.35, and it's the last corrected branch: it ends on December 31, 2026, so switching to 8.3 or 8.4 is inevitable before the end of the year. PHP 8.1 has been end-of-life since December 31, 2025, PHP 8.0 and 7.4 have been unsupported for even longer: for these three, PHP has released source patches to compile yourself, and some hosts or Linux distributions include them in their packages. PHP 7.3 and older, PHP 5: nothing, and watchTowr considers all versions since PHP 5.4 as affected. Switching branches is the only solution.
The number that matters is the one your site actually uses, not the one from a server command line: hosting can run multiple versions side by side.
How to check your PHP version at OVH, o2switch, IONOS, or Infomaniak
On WordPress or WooCommerce: Tools, then Site Health, tab Info, section Server, line « PHP Version ». Updating WordPress, a theme, or a plugin does not change this number.
At o2switch: in cPanel, under Software, the tool « Select PHP Version » displays the current version in a dropdown menu. Choose 8.3 or 8.4, then « Apply », keeping the default extensions checked. Note that the default « native » version is PHP 8.1, which has no patches: the full step-by-step guide and what o2switch did on October 21 is in the o2switch guide.
At OVHcloud: customer portal, Web Cloud, Hosting, your hosting, General Information tab, line « Global PHP version ». To change it, under Configuration, click the « … » button, then « Edit Configuration ». Those more comfortable can also modify the app.engine.version line in the .ovhconfig file at the root of the FTP. The details, including the grayed-out button and the .ovhconfig file, are in the OVHcloud guide.
At IONOS: customer portal, Hosting section, PHP menu, « Open », select the domain, « Modify PHP version », choose and save. The switch takes a few minutes, and the setting applies per domain. The details, including what the « PHP Extended Support » from IONOS means, are in the IONOS guide.
At Infomaniak: Manager, Web Hosting, click on the product name, « More Information », « Edit », choose the version, « Save ». The change is immediate, and reverting to a vulnerable version is then blocked. Infomaniak also patches PHP 7.4, 8.0, and 8.1 on its own, which almost no other host does: the hourly breakdown is in the Infomaniak guide.
At Hostinger: hPanel, Websites, « Manage », then « PHP Configuration » under « Advanced », choose the version, « Update ». The version applies to all sites on the plan, and Hostinger states « no action required », which does not cover a site still on 8.1: the Hostinger guide explains why.
At PlanetHoster: in N0C, « Languages », « PHP », choose the version, then « Apply »; on an older cPanel account or on HybridCloud, the path changes, and file uploads may return a 403 error tonight due to the host’s emergency measures: everything is in the PlanetHoster guide.
On a VPS, a dedicated server, or Plesk: In Plesk, under Websites & Domains, go to the PHP section for each site. On a server, running `php -v` shows the command-line version, but it's the `phpinfo()` page or the X-Powered-By header that reveals which version actually serves the site. Then use `apt` or `dnf` to update, followed by a restart of PHP-FPM or Apache.
In any case, the numbers to look for are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. The verification tool reads the number when the server displays it and identifies the hosting provider to guide you to the correct path.
Are you affected? Website, store, software, intranet
We often talk about « websites, » but the vulnerability doesn’t care what you call it. It looks at what’s running on the server.
Your brochure website running on WordPress, Joomla, Drupal, SPIP, or TYPO3 uses PHP. Affected.
Your online store running on PrestaShop, WooCommerce, Magento, or Thelia uses PHP. Affected, and it’s the most appealing target for an attacker: there are payments and addresses involved.
Your business software, intranet, extranet, or customer portal, if they were developed in PHP (Laravel, Symfony, or custom code), are affected even if they’re password-protected. The vulnerability triggers before the login page. An internal tool used only by your employees but accessible from the internet is exposed like a public site.
Tools installed on a server, such as Dolibarr, GLPI, Nextcloud, Moodle, a phpBB forum, a wiki, or a ticketing tool, are in the same situation.
Not affected: website builders like Wix, Squarespace, Shopify, Webflow, Jimdo, or Google Sites. They don’t run PHP for you, and they manage their own servers. An application built in Node.js, Python, or .NET isn’t affected by this vulnerability either. Small caveat: Node.js released its own security patches on the same day, October 21. Same reflex, same timing.
If you don’t know what your site runs on, the verification tool reads it from your homepage: it detects the platform, the PHP version when displayed, and often the hosting provider. Otherwise, the question to ask your provider is simple: « Which PHP version does this site use, and has it been updated since October 21? »
What your host does, and what they don’t
In shared hosting, PHP belongs to the hosting provider. You cannot install it yourself; you only choose a branch (8.1, 8.2, 8.3…) in your account. The provider, however, installs the patched versions on their servers for the still-supported branches, from 8.2 to 8.5.
On the evening of October 21st, here’s what I could gather. o2switch disabled the affected functionality as early as 8:07 AM, but at 4:40 PM, its servers were still running the versions from October 6th, waiting for CloudLinux packages scheduled for that evening. OVHcloud announced firewall rules on its shared clusters and a maintenance campaign. Infomaniak opened a maintenance window from 3:00 PM to 3:00 AM the next day, with fixes deployed by its teams and no action required, except for sites still running an older, supported PHP version. For IONOS, Hostinger, PlanetHoster, LWS, or Gandi, I found no public announcement at that time.
What you need to do in any case: check in a day or two that the version has actually changed. An announced patch is not an installed patch. And if your site is running PHP 8.1 or lower, the hosting provider won’t touch it: it’s up to you to upgrade to 8.3 or 8.4 via cPanel, Plesk, or your client area, after a backup and testing, because an old theme or extension may not be compatible.
The three questions to ask your provider
Many websites and tools were built three, five, or eight years ago by an agency or freelancer you no longer see. Now is the time to reach out to them via email to keep a record.
First question: what PHP version is currently running the site or application? The answer should be a precise number, like 8.3.36, not ‘it’s up to date.’
Second question: has it been updated since October 21, 2026, and by whom?
Third question: have the server logs been reviewed since October 20th? Large multipart POST requests targeting pages that don’t expect them are the red flag to look for.
If no one responds within the day, or if the provider no longer exists, that’s exactly the kind of situation I handle: I take over access, update, test, and let you know what’s been done.
And if your site is still running PHP 7 or 8.1?
This is the trickiest and most common scenario among small businesses. Two options.
Backported package: some hosting providers and Linux distributions (Debian, Ubuntu) integrate patches into older versions without changing the version number. You should ask them in writing if this has been done. An old version number doesn’t prove the vulnerability on its own, but in doubt, you need confirmation.
Branch upgrade: switch to PHP 8.3 or 8.4. This is the real solution, and it’s also what you’ll eventually have to do, since PHP 8.2 support ends on December 31, 2026. It requires verifying that your CMS, theme, and extensions support the new version, backing up your data outside the server, and testing on a copy before switching. An hour for a simple site, half a day for an e-commerce platform with many modules.
If neither option is possible today, the CERT-FR recommendation is clear: take the application offline or place it behind an application firewall until the necessary steps are taken.
Taxes, CAF, Ameli, prefectures: when will they be back, and should we be worried?
If you landed here because impots.gouv.fr or caf.fr displays ‘under maintenance’, your Ameli account won’t open or your prefecture’s website isn’t responding: it’s this vulnerability, and it’s intentional. The Ministry of the Interior refers to ‘preventive maintenance’ and ‘as soon as possible’ for bringing the sites back online; the CAF speaks of maintenance and keeps its usual filing deadlines. Services come back one by one: Météo-France reopened on the morning of October 22, ameli.fr and urssaf.fr were answering on the 23rd at 11:40 Paris time, and at the same time caf.fr, impots.gouv.fr and the prefecture websites still showed a maintenance page. Your data is not at risk, no breach has been announced, and there’s nothing you need to do for these sites.
One precaution only: emails and SMS claiming to be from the tax office, your hosting provider, or ‘ANSSI’ asking you to ‘verify your credentials’ will start appearing in the coming days. Scams always follow this kind of news.
Updating WordPress isn’t enough
This is the confusion I hear most often. ‘I’ve done the updates, everything’s green.’ WordPress, PrestaShop, or plugin updates don’t affect PHP, which runs underneath. A security plugin may block some requests, but not all, and attackers have already modified their payloads to bypass Cloudflare’s rules. The only real fix is updating PHP on the server to the patched version.
How to tell if it’s already too late
The first attack attempts were seen by Amazon on its honeypots as early as October 17, four days before the patch, then continuously from the morning of the 21st. On the 22nd, Wordfence saw the attacks continue with no known compromise through this flaw: reassuring, but if your site stayed exposed, you need to check it.
In your server access logs, look for unusual multipart POST requests since October 17. In your file upload directories (uploads, cache, tmp), check for recent .php files you didn’t place there. In your admin panel, look for unknown admin accounts and new scheduled tasks. If in doubt: immediate backup, change all admin passwords, and if customer personal data is involved, notify the CNIL within 72 hours.
What I can do for you
I’m a freelance developer near Rennes, and I work remotely across France. For this vulnerability, I do something simple: I check the actual PHP version running on your site, shop, or tool, update PHP or switch branches, verify everything still works, and write you a report of what was done. If your provider isn’t responding, I can recover access and take over.
Start by checking your site for free, it takes ten seconds. And if the result isn’t what you hoped for, write to me: I’ll reply within 24 hours.
Sources: security advisories and patched versions on php.net, CERTFR-2026-ALE-014 alert from CERT-FR, prefectures and Météo-France offline, France 3 at 6:56 PM on October 21st, public sites down in the Netherlands, Finland, and the United Kingdom, The Record, Cloudflare firewall rules, hosting providers listed by Clubic at 6:25 PM on October 21st, Infomaniak status page, Node.js security patches from October 21, 2026, October 17 exploitation attempt seen by Amazon, Ameli, CAF, tax portal and URSSAF down, Clubic on October 22 at 10:53 AM, attacks continue with no known compromise, Wordfence on October 22.
