If your website, online store, or customer portal runs on WordPress, Magento, Drupal, or custom PHP code, there's one question this week that matters more than any technical detail: who in your company, or at your provider, saw the advisory and updated the site that same day?
If the honest answer is "I guess the hosting company," you don't have a technical problem. You have a risk with no owner. And that can be fixed.
PHP is the language that powers a huge number of websites, online stores, and portals. On October 21, 2026, the PHP project released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35, which fix two critical flaws (CVE-2026-109618 and CVE-2026-109619), rated 9.2 on the CVSS v4.0 scale. In plain terms: they let someone, with no username or password, run their own instructions on the server where your site lives. The PHP project puts it bluntly: there are no complete mitigations, and updating is the only safe choice.
Details leaked on October 20, and PHP moved the release up: it went out around 8:30 a.m. Colombia time on October 21, ahead of schedule, according to CERT-EU. Both flaws are already known as "PHP2Shell," the name Cloudflare and Sansec use.
The reaction was fast. Cloudflare reported early attack attempts and turned on firewall rules as temporary protection, which doesn't replace the update. In the Netherlands, the government temporarily took several official sites offline as a precaution, including Overheid.nl, MijnOverheid, and DigiD. And, according to Sansec, researchers at Calif showed that someone with no username or password can run code on Magento, WordPress, and Drupal.
We're not telling you this to scare you. We're telling you because a government decided it was worth knowing exactly what it had exposed and acting the same day. That's the question worth asking in any business.
This is the most common mix-up. Your site has two layers: the platform you see (WordPress, Magento, Drupal) and the engine underneath that runs it, which is PHP. The flaw is in the engine. So updating the platform or its plugins, while good practice, doesn't close this gap.
Drupal's security team made it clear in its advisory: updating PHP is the only complete mitigation, and hosting security is the site owner's responsibility. In other words, yours, even if you delegate it.
If you don't know which of the two applies to you, that's already your first finding.
"The IT person" isn't enough. You need a name, on your team or at your provider, who hears about an advisory like this the day it comes out and knows whether it affects you: that your site runs on PHP, and which version.
A "we're good" over the phone doesn't cut it. Ask for written confirmation with the exact PHP version installed (for example, 8.3.36 or later on the 8.3 branch), the date, and proof that PHP was restarted so the new version is actually running. If someone only applied a temporary measure, they should tell you in those words.
If your site is on PHP 8.1 or older, those versions no longer receive updates from the PHP project. Given the severity, the PHP security team provided minimal source-code backports for PHP 7.4, 8.0, and 8.1, meant for people who build PHP from source or don't have an LTS (long-term support) vendor; some distributions and LTS vendors also provide their own backported fixes. That's a lifeline, not a plan. The real plan is to migrate to a supported branch (currently 8.2, 8.3, 8.4, and 8.5), and that needs a budget and careful testing. If you're on 7.3 or older, there isn't even that minimal patch.
And if you're on 8.2, there is a patch this time (8.2.35), but that branch loses support on December 31, 2026. Now is a good time to put the migration on the calendar.
You don't need to panic or become a server expert. You need to give the risk an owner: know where your site is hosted, which version it runs, who watches it, and who tells you. It's the same logic as who answers for what goes into production, even when the code is written by AI.
A site that's down or compromised isn't a server problem: it's orders that don't come in, customers who can't get into their portal, and an uncomfortable conversation about your brand's reputation.
It's the nickname for two critical PHP flaws (CVE-2026-109618 and CVE-2026-109619) fixed on October 21, 2026, in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. They allow code to run on the server without authentication.
No. The flaw is in PHP, the engine those platforms run on. What protects you is updating PHP to a fixed version and restarting it.
It depends. With managed hosting the provider usually does it, but not all of them responded the same way on advisory day. On your own server or VPS, nobody does it unless you ask. Ask for written confirmation with the installed version.
Those versions no longer get updates from the PHP project. Given the severity, PHP provided minimal backports for 7.4, 8.0, and 8.1, and some distributions and LTS vendors offer their own: they can get you through, but the real plan is to migrate to a supported branch (currently 8.2 through 8.5). PHP 8.2 loses support on December 31, 2026.
At Somos Gente Digital we listen, build, and stay with you until the business grows. In maintenance, that means watching the advisories, updating, and telling you what got done, with version and date. We won't promise that nothing will ever fail; we will promise that people close to you are watching, with a clear method to respond when something happens.
If you're not sure who answers for your site, see how we handle software maintenance or reach out on our contact page.
In a storm, palm trees and bamboo bend without snapping. Rigid things break. Today the storm is AI, and the owner's question isn't which tool to buy, but whether you can change course without breaking your operation.
Most developers already code with AI. That's not the worrying part. The worrying part is code reaching your operation without anyone reviewing it or answering for it. Three questions to ask today.
