Cmd+k (Mac) or
Ctrl+k (Win/Linux)
to Search

Critical PHP flaws: five questions to ask your web team today

On the night of 2026-10-21, Prime Minister Sanae Takaichi posted on X urging site operators to apply a PHP fix as soon as possible. If that’s difficult, she said, temporarily taking a website offline is one effective way to reduce the risk. A prime minister weighing in on a programming language patch is unusual, and it tells you how serious this one is.

PHP is the programming language underneath WordPress and many other website builders and content management systems. On 2026-10-21 the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 on the CVSS v4.0 scale. An attacker doesn’t need to log in to exploit them: a crafted web request is enough to run their own code on the server. IPA and the National Cybersecurity Office have issued warnings too, and some banks and other services have suspended parts of their sites as a precaution.

You don’t need to follow the technical details. What you need is to make sure someone who does is on it, today. If your business has a website, an online shop, a recruiting site or any web-based tool, send the questions below to whoever runs it: your IT team, your web production company, or your hosting provider.

Who is affected

The flaws are in PHP itself, not in any one product, so every site that uses PHP to answer web requests is in scope. That includes sites built on WordPress, Drupal, Joomla, Magento and EC-CUBE, and custom applications written with frameworks such as Laravel. Researchers at Wiz demonstrated a takeover, with no login, against the current WordPress, Drupal and Joomla container images. They also showed that even without a full takeover, the flaws can leak passwords, tokens and API keys held in the server’s memory.

The details leaked on 2026-10-20, a day before the fix was out. Patchstack says hosting partners have already reported attacks, and Cloudflare has reported early attack attempts. Assume attackers are scanning for vulnerable sites now.

Five questions to send your web team

1. Which of our websites and systems run PHP? Don’t stop at the main corporate site. The ones people forget are the old campaign site, the recruiting site, a members’ area, an intranet tool, or the online shop a vendor built years ago. IPA also points out that PHP can be built into products and network equipment, so check the maker’s notices for those too.

2. Has PHP been updated, and to which version? The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or a patched package from your Linux distribution or vendor. “We updated WordPress” is a different answer. WordPress and its plugins run on top of PHP, and it’s PHP that needs updating here. If your site is on a shared rental server, check your host’s announcements and the control panel where you choose the PHP version.

3. Is anything still on PHP 8.1 or older? The PHP project no longer issues fixes for those versions. Ask your vendor or distribution whether they provide a patched package. If nobody does, that site needs an upgrade plan, and it probably needs to come offline until then.

4. If it can’t be patched today, can we take it offline? That’s the Prime Minister’s suggestion, and the PHP project is clear that updating is the only complete fix. Configuration changes and a web application firewall reduce the exposure but don’t remove it. (Cloudflare’s emergency firewall rules only help if your server accepts traffic exclusively through Cloudflare.) A maintenance page for a day costs far less than a compromised server.

5. Were we exposed before we patched? A site that ran unpatched after 2026-10-20 should be checked for signs of compromise. Change the passwords and keys stored on that server as well: database passwords, API keys, mail account credentials. Patching closes the hole, but it doesn’t remove anyone who already got in.

Then follow up. “We’re looking into it” is a start, not an answer. Ask for the version number and the date the update went on.

Does eSolia use PHP?

Since the news broke, we’ve had several emails asking this. We don’t. The eSolia website, this blog and the applications we build are written in TypeScript and run on Cloudflare Workers, and we keep a close eye on the software components we depend on. If you aren’t sure what your own sites run on, or your vendor isn’t answering, get in touch and we’ll help you find out.

For the technical details, see the PHP project’s security advisory and IPA’s alert (Japanese).

Securityby: Rick CogleyReading Time: 3 min

Kindly do us a favor? Share this post by email or on social media!