Two Critical PHP Flaws Went Public This Week. Here's How We Handled Them, and What You Should Check

On 21 October, the PHP project released fixes for two critical security flaws. The same day, Singapore's Cyber Security Agency (CSA) issued alert AL-2026-151. As updated on 22 October, it cites reports of "widespread exploitation attempts" and the development of multiple proof-of-concept exploits.

PHP is the language behind WordPress, WooCommerce and a large share of small-business websites everywhere. If your site runs on it, and there is a good chance it does, this one matters.

Key Takeaway: These flaws let an attacker run their own code on your web server without a password or a login. The only real fix is to update PHP. If you don't know which version of PHP your website runs, or who is responsible for updating it, find out this week.

Written by Derek Chua, founder of Magnified Technologies. Magnified builds and hosts websites for Singapore businesses and patches the servers they run on.

What happened

The flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and CSA's alert groups them under the name PHP2Shell. Both score 9.2 out of 10 on the CVSS severity scale.

In plain terms, both bugs are about PHP mishandling its own memory between web requests. One is triggered when PHP runs out of memory partway through a request. The other leaves leftover data from one request lying around for the next. A carefully crafted request can exploit either to run commands on the server.

Three things set this apart from a routine PHP update:

• No login is needed. The attacker only has to send requests to your website. Every public page is a way in.
• Every version was affected. CSA's alert covers all versions of PHP. The fixes are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• Older versions get no official release. The PHP project's advisory is clear that PHP 8.1 and older no longer receive updates. Some Linux distributions and paid long-term-support vendors are backporting the fix, so ask your host whether yours has. The PHP team has also published source patches for 7.4, 8.0 and 8.1, but using them means compiling PHP yourself, which few small-business hosts will do. If nobody is patching your version, upgrading is the realistic way out.

PHP's own wording is that "there are no complete mitigations, updating is the only safe choice." The temporary measures it lists reduce exposure to specific attack paths, but the advisory says plainly that they "do not make an installation safe."

How we handled it

The PHP project announced the day before that a critical release was coming, scheduled for 10pm Singapore time on 21 October. That warning was enough for us to treat it as an overnight job rather than a next-week job.

We waited for the release, and once the patched packages were available we rolled them out to every server we manage. By 7:30am on 22 October, before our clients had opened for the day, every website we host was being served by a fixed version.

Then we checked our work, because "we ran the update" and "the server is safe" are not the same thing.

We confirmed the version on every server, not just the update log. One of our servers runs PHP from Ubuntu's own packages, which still reports itself as PHP 8.3.6, a version number from April 2024 that looks thirty releases out of date. It is in fact patched. Ubuntu fixes security flaws inside the version it ships, without changing the number, so we read the package's changelog to confirm the fix for both CVEs was in it. A version check alone would have flagged a safe server as vulnerable, and the reverse mistake is just as easy to make.

We looked for PHP we weren't actively using. A server can have more than one version of PHP installed. A leftover older version that no website points at is not reachable from the internet, but it is the kind of thing that gets switched back on months later during a rollback, by someone who has forgotten why it was there. We listed every installed version on every server and confirmed which ones were actually serving websites. On one server we found an older version still installed with nothing routed to it. Nothing on the web can reach it, and we are retiring it rather than leaving it for someone to rediscover.

We tested and scanned every site afterwards. We tested each site after the update to make sure nothing had broken. Then we scanned for signs that anyone had got in between the flaws becoming public and the patch landing: new admin accounts, files changed since 21 October, and PHP files sitting in upload folders where they have no business being.

None of this was dramatic. It was a list of steps, done in the right order, before the next business day started. That is what most security work looks like when it goes well.

Why this one deserves a business owner's attention

Most security alerts never need to reach a business owner, and we would rather not cry wolf. This one does.

Attackers move faster than most maintenance schedules. Once a fix is published, attackers compare the old and new code to work out exactly what the bug was. Within a day of the release, CSA's alert was citing reports of widespread exploitation attempts. A website that gets updated "at the next monthly maintenance" is exposed for weeks.

A compromised website is rarely just a defaced website. An attacker who can run code on your server can usually read your database, which means customer names, emails, enquiry form submissions and, on an online shop, order histories. Under Singapore's PDPA, the business that collected the data stays accountable for it, even when a developer or host ran the server.

Many sites also have no one watching them. The website was built three years ago, the developer has moved on, and the hosting is on auto-renew. Nobody is wrong to be in that position. It is extremely common. But it means a critical patch like this one has no one to apply it.

What you should check this week

You don't need to be technical to get answers to these questions. Ask whoever built or hosts your website.

1. Does my website run on PHP? If it is WordPress, WooCommerce, Joomla, Drupal, Magento or a custom content system a web agency built for you, the answer is almost certainly yes.
2. Which version, and has it been updated since 21 October? The answer you want is 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, or confirmation that your operating system vendor's patched package is installed.
3. Is it on PHP 8.1 or older? If so, ask whether your operating system vendor has backported the fix. If not, plan an upgrade now.
4. Is there anything else on the same server? CSA's alert asks businesses to check for PHP used by third-party applications, even where the main site doesn't use it. In our experience the usual culprits are an old staging copy of the site or a forgotten microsite on the same hosting account.
5. Who is responsible for this next time? If the honest answer is "no one", that is the most important thing to fix.

If you're on shared hosting, your host handles the PHP update itself, but it is still worth asking them to confirm it is done. If you're on a server your developer set up, the update is almost certainly on them, or on you.

Working With Magnified

If you'd like a second pair of eyes on your website after this, we offer a free 30-minute consultation. We'll check which PHP version your site is running and whether it is exposed to these flaws, and tell you plainly what needs doing. If it needs fixing, we can do the update, or simply tell your current developer exactly what to change.

Frequently Asked Questions

Is my WordPress site affected by PHP2Shell? WordPress runs on PHP, so if the PHP version on your server has not been updated since 21 October, your site is exposed. Updating WordPress itself or its plugins does not fix this. PHP sits underneath WordPress and has to be updated on the server.

My site is on Wix, Squarespace or Shopify. Do I need to do anything? No action is needed for the website itself. Those platforms manage their own servers. Check instead whether you have any other site or tool on separate hosting, such as an older WordPress blog or a landing page, that might run PHP.

Can a firewall or security plugin protect me instead of updating? No. A security plugin such as Wordfence runs inside WordPress, and PHP's own advisory describes a demonstrated attack that fires before any website code runs on servers using Apache's mod_php, and the flaws sit in PHP itself on every setup, so a plugin running inside WordPress never gets a say. The PHP project lists some server settings that block specific attack paths, but it says they "do not make an installation safe." Treat them as a stopgap until the update is done.

How do I know if my site was already hacked? Signs include unfamiliar admin users, files that changed without anyone editing them, unexpected redirects to other sites, and warnings from Google Search Console. A clean result from a security scan after patching is reassuring, but the absence of obvious signs is not proof. If your site sat unpatched for days, a proper check is worthwhile.

What does "update to the latest PHP version" involve, and will it break my site? Within the same version line, such as 8.3.33 to 8.3.36, an update rarely breaks anything. It is a security fix, not new features. Moving from an old line like 7.4 to 8.3 is a bigger job that needs testing, because old plugins and themes may not support the newer version. That is why sites on old PHP versions should start planning now rather than waiting for the next alert.

---

You may also find these useful: What Claude Mythos Means for Cybersecurity, and What Business Leaders Should Pay Attention To, and WordPress Just Released Official AI Plugins. Here's What SME Site Owners Actually Need to Know.