The October 2026 PHP vulnerability: what it means for your website, and what we did

What happened

On 21 October 2026 the PHP project released security updates for two critical flaws in PHP itself, the language that runs a large share of the world's websites. Within hours the EU's cybersecurity team, CERT-EU, published Security Advisory 2026-018 telling organisations to patch immediately rather than wait for a maintenance window. Some institutions in Europe, universities among them, took their websites offline until they had the fix in place, because running an unpatched site for even a few days was judged riskier than being unreachable. This is not a WordPress problem or a Laravel problem, and it is not about a plugin someone forgot to update. The flaw sits underneath all of them, in the engine that executes the code, which is why every PHP website is affected whatever it was built with. In Uganda that covers most company websites, a large number of school and NGO portals, and many of the custom systems that ministries and agencies run day to day.

Why this one is serious

Most security flaws need something to go wrong first: a weak password, a user clicking a link, an attacker who already has an account. This one needs none of that. An attacker who can reach the website from the internet can send one specially crafted request and end up running their own commands on the server. From there they can read or change the data the system holds, plant malware that infects visitors, use the server to attack others, or simply take the site down. The instructions for doing this became public almost as soon as the fix was released, so attacks are a question of when, not whether. Automated scanners sweep the internet for vulnerable servers within days of a disclosure like this, and they do not care whether the site belongs to a multinational or a primary school.

• No password or account is needed to exploit it.
• One request is enough to take control of the server.
• Anything on the server is then at risk: data, files, other sites on the same machine.
• Public instructions exist, so automated attacks are expected.
• Every PHP site is affected, whatever framework or CMS it uses.

Which PHP versions are safe

The fix was released for every PHP line that is still supported. If your site runs any of the versions below, or anything newer in the same line, it has the fix. If it runs an older release in one of those lines, it needs updating now. The harder case is PHP 8.1 and older: those versions have reached the end of their life and will not be fixed, by this release or any future one. A site on PHP 8.1, 8.0 or 7.x needs an upgrade to a supported line, which can mean testing and adjusting the application, not just pressing an update button. That is work worth doing this week rather than this quarter. Your hosting control panel or your developer can tell you which version a site runs in under a minute.

• PHP 8.5: fixed in 8.5.12
• PHP 8.4: fixed in 8.4.27
• PHP 8.3: fixed in 8.3.36
• PHP 8.2: fixed in 8.2.35
• PHP 8.1 and older: end of life, will never be fixed, upgrade required

What we did for the systems we run

On 22 October 2026, the day after the release, we updated PHP to a fixed version on every server we manage directly. We also switched off the older PHP versions that were still installed on those servers, because a version that will never be fixed is a door left open even if no current site uses it. After the update we checked each site on those servers to confirm it was working normally, since a security fix that quietly breaks a client's system is a second incident, not a solution. The same servers are watched by SENTINEL, the threat detection we run on our own infrastructure. We then wrote a plain-language advisory for our clients explaining the flaw, what we had done and what, if anything, they needed to check. For clients we host, the answer was nothing: the fix was already in.

If someone else hosts your website

Some of our clients run systems on servers we do not control, and so may you. In that case the fix depends on the hosting company, and the useful thing to do is ask them direct questions in writing rather than assume. Our own practice for client systems on third-party hosts is to raise it with the host, follow it until a fixed version is installed, and keep the client told where things stand. If a system cannot be updated quickly, the safest course is to take it off the public internet until it can be, even though that is inconvenient. A day offline is cheaper than a compromised server, a defaced site or a data breach you have to report.

• Which PHP version is the site running right now?
• When was it updated, and to which version?
• Are older PHP versions still installed on the server?
• Was the site checked after the update to confirm it still works?
• If it cannot be updated this week, can it be taken offline until it is?

What a flaw like this tells you about who runs your system

Flaws like this one will keep coming. What separates a bad week from a quiet one is who notices first. If your provider told you about this flaw with the fix already applied, they are operating your system. If you heard about it from the news, or from this page, it is worth asking who is watching your servers, how quickly they patch, and whether anyone would have called you at all. That question matters more than any single vulnerability, and it is the same question we suggest every buyer ask before awarding a software contract. If you would like a second opinion on a PHP system you run, whether or not we built it, contact us on ivilleinc@gmail.com or +256 773 185 503.