Monaco Sites Offline: Patch PHP Now
Monaco took its government, Palace and Mairie websites offline over the PHP2Shell flaws. What the alert means for your business site and what to do this week.
On the evening of Wednesday 21 October 2026, anyone trying to reach the Prince's Government website, the Prince's Palace site, the Monaco Digital Security Agency (AMSN) or the Mairie de Monaco found a maintenance page instead. Nobody had been hacked, as far as anyone has said. The Government's Directorate of Information Systems and Infrastructure (DISI), working with the AMSN, had decided to cut external access on purpose, because two critical flaws had just been disclosed in PHP, the language that runs a very large share of the world's websites.
If your business website runs on WordPress, WooCommerce, PrestaShop, Magento, Drupal, Laravel or any custom PHP code, this story is about you as much as it is about the Principality. This article explains what happened, what the flaws are in plain language, and the handful of things to do before the end of the week.
What happened in Monaco
The suspension was precautionary. The Government said its sites would stay unreachable from outside until security checks and software updates were complete, while staff could still reach them from internal workstations. The Mairie confirmed its own shutdown the same day, which also took down the sites of the Jardin Exotique, the Académie Rainier III, the Espace Léo Ferré and the online magazine Monaco Vivre Ma Ville. It reassured residents that existing Civil Status appointments remained valid and that document requests submitted before the cut-off were safely registered.
Monaco was not alone. The French Interior Ministry put prefecture websites into preventive maintenance, Nice Côte d'Azur airport and the town of Antibes closed online services, and the Netherlands, Finland and Germany took public sites offline too. France's CERT-FR issued alert CERTFR-2026-ALE-014 on 21 October and updated it the next day to say it was aware of working proof-of-concept code.
By 24 October the main Government and Mairie sites were loading again when we checked, although we found no public statement confirming full restoration. Treat that as encouraging, not as the end of the story.
What PHP2Shell actually is
The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619 and have been nicknamed "PHP2Shell". Both are rated 9.2 out of 10 on the CVSS 4.0 scale, and both allow remote code execution without logging in. In practice that means an attacker who can send web requests to a vulnerable server may be able to run their own code on it, read what it holds and use it as a foothold.
Three details matter for a business owner:
- The bug is in PHP itself, not in a plugin or a theme. Updating WordPress, a plugin or a theme does nothing if the PHP runtime underneath is still old. Every version back to PHP 5.4 is reported as affected.
- Fixes exist, but only for supported branches. PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October. PHP 8.1 and older no longer receive official updates, so sites on those versions depend on a vendor backport or need to move to a current branch.
- It is being exploited. Security firm Patchstack reported active exploitation incidents from hosting partners on disclosure day, and Amazon's honeypot network logged an attempt four days before the public announcement. This is not theoretical.
The flaws were found with the help of AI-assisted security research, which is one reason the disclosure landed with so little warning. PHP has since flagged a further, lower-severity issue that did not yet have a fix at the time of writing, so expect more updates in the coming weeks.
Why this reaches far beyond the Government
Hosted platforms such as Shopify, Squarespace and Wix patch their own infrastructure, and their customers have nothing to install. Almost everything else is different. A WordPress brochure site for a Monaco law firm, a WooCommerce shop for a boutique in the Carré d'Or, a PrestaShop store, a real estate agency's listings portal, a hotel's booking engine, an intranet, a forgotten microsite from a 2022 event, a staging copy left online: all of these run PHP somewhere, and each one is a separate installation that must be checked.
The uncomfortable part is that many owners do not know which PHP version their site runs, or who is responsible for updating it. On shared hosting the provider usually manages PHP. On a VPS, a dedicated server or a container, it is on you or your developer. On managed WordPress hosting it depends on the contract. If you cannot answer that question in one sentence, that is the first thing to fix.
Five things to do this week
- Find out your PHP version. In WordPress, go to Tools, then Site Health, then the Info tab and open the Server section. Elsewhere, ask your host or developer in writing. Anything below 8.2.35, 8.3.36, 8.4.27 or 8.5.12 is exposed.
- Update, then restart. Move to the patched release for your branch and restart PHP-FPM or the web server so the new version is actually in use. Back up first, then test the site afterwards.
- If you cannot update today, reduce the exposure. CERT-FR lists two interim measures: disable the upload-progress feature in
php.ini(session.upload_progress.enabled = Off), which only mitigates one of the two flaws, and block or closely monitor multipart requests at the firewall. Or do what Monaco did and put the site into maintenance mode until it is patched. - Retire PHP 8.1 and older. If your host offers no backport, upgrading to a supported branch is the only reliable path. For an old WordPress or PrestaShop site that may mean a compatibility check first.
- Assume you may already have a visitor. Patching does not evict someone who got in before the patch. Review access logs, look for unfamiliar files or admin users, and rotate the passwords, API keys and tokens that the server held.
A good website maintenance arrangement should have handled points one and two for you on 21 or 22 October without being asked. If yours did not, ask why.
What Monaco's decision teaches small businesses
Taking your own site down on purpose feels like failure. It is not. The Government weighed the cost of a few days of unavailability against the cost of a compromise of systems that hold residents' data, and chose the maintenance page. A Monaco business with client files, payment data or confidential correspondence behind a PHP application should be ready to make the same call, quickly, and know who is allowed to make it.
That requires three things to exist before the emergency: an inventory of every site and application you operate, a maintenance page and a one-paragraph message for clients explaining how to reach you by phone or email in the meantime, and a named person, internal or external, with the authority and the access to pull the plug and to bring things back.
Note the data-protection angle too. Under Monaco's Law No. 1.565, a personal-data breach may trigger a notification to the APDP, and the authority has recently reminded controllers that late notifications are increasing. If your logs suggest an intrusion, speak to your advisor on APDP data protection the same day rather than waiting for certainty.
The longer lesson
PHP2Shell will be patched everywhere eventually, and then the next one will come. The businesses that handle these weeks calmly are the ones that treat the website as infrastructure rather than as a project that finished the day it launched: a supported PHP branch, automatic security updates where possible, a host that communicates, a modern codebase built by a team that still answers the phone. If your site was built years ago and nobody has touched the server since, this is a reasonable moment to have a conversation about WordPress hardening or a fresh web development foundation.
If you are not sure what your site runs on, or whether anyone has patched it since Wednesday, get in touch and we will check it with you.
