PHP2Shell and October's Security Wave: What Kenyan Businesses Must Actually Do

On Tuesday 21 October 2026 the PHP project shipped emergency patches for two critical flaws in the PHP engine itself. Within hours, government websites in the Netherlands, Finland, France, Germany and Belgium were switched off, Wikimedia pulled supporting systems, and ICANN took three of its own sites down.

If you run a Kenyan business website, it is almost certainly built on PHP. So here is what happened, what it means for your site, and exactly what to do about it.

What the PHP Flaws Are

Two vulnerabilities in PHP itself, nicknamed PHP2Shell, both rated critical at 9.2 by the PHP project on the current version 4 severity scale. On the older version 3 scale still used by the US National Vulnerability Database, the first of the two scores 9.8.

In plain terms: in the wrong conditions, somebody who has never logged in to your site could get the server to run their code. That is as serious as web vulnerabilities get.

Affected: every PHP release before 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The vulnerable code path goes back to PHP 5.4, released in 2012. Cloudflare's assessment is that every web server running PHP 5.4 or later is in scope, and the UK's National Cyber Security Centre put it bluntly: organisations using any version of PHP are affected. If you are still on PHP 7, do not read the official list of affected versions as good news. It lists only the branches still supported; versions between 5.4 and 7.3 get no fix at all.

Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 October 2026 at 17:00 EAT. PHP 8.1 and older receive no normal release, though the security team published minimal source backports for 7.4, 8.0 and 8.1, and distributions such as AlmaLinux, Ubuntu and cPanel shipped their own patched builds.

How exposed you are depends on how your host runs PHP, which is worth knowing when you ask them about it. Where PHP runs as an Apache module, security firm Huntress confirmed unauthenticated code execution with default settings, before any of your website's own code runs. Where it runs as PHP-FPM or under LiteSpeed, exploitation is conditional on configuration. The PHP project's position is the one to act on: no configuration change makes a site safe, and only the update does.

Why the patch arrived in a hurry

The release was originally scheduled for 22 October. It was brought forward by a day because the vulnerability identifiers leaked publicly on the 20th, carrying a wrong severity score and a wrong release date. In the hours that followed, one of the research teams accidentally published a video of its working exploit, and a container vendor shipped images containing the fix more than six hours before the official release, handing attackers a way to see what had changed.

None of that is anyone's scandal, but it explains the compressed timeline, and it is the reason the gap between "fix exists" and "internet-wide scanning" was measured in hours rather than days.

Everything Else That Broke in the Same Fortnight

PHP was not alone, and this is the part most coverage misses. Between 13 and 23 October, nearly every layer of the ordinary web stack published a serious fix.

One number worth holding on to: on 21 October alone, PHP, GitLab and Node.js together published fixes for 24 separate vulnerabilities, nine of them rated high or critical. That is the count we could verify from the three projects’ own release notes for that date.

Schools, colleges and universities: this one is yours

Kenyan institutions run e-learning on Moodle, and Moodle is PHP. On 21 October, Open LMS took every hosted customer site offline to patch, interrupting classes mid-day at institutions that depend on it. Moodle's own public sites were also pulled while the project urged self-hosters to update.

There is a practical trap here that catches institutions every time. Older Moodle versions do not run on the newer PHP versions that contain the fix, so "just update PHP" can break the platform. If you are on an older Moodle, the sequence is: ask your provider which PHP version the fix requires, confirm whether your Moodle release supports it, and if it does not, restrict access to the site (staff network or sign-in only) while you plan the upgrade. Leaving an unpatched, publicly reachable e-learning system running because an upgrade is inconvenient is the worst of the available choices.

Where the Evidence Stands Today

Evidence on this is still arriving. Here is where each part of it stands as of today, so you can see what is settled and what is not.

Why So Many Sites Went Offline

The large outages were organisations switching their own systems off while they patched, as a precaution, rather than attackers taking those sites down.

Reuters and NBC reported that Dutch government services, the Port of Rotterdam, Finnish government web services, French prefecture sites, German federal sites and Belgian foreign ministry sites were all deliberately taken offline. Several of those organisations said explicitly that they had seen no sign of a breach.

The Padlock Problem: a Certificate Authority Picked Terrible Keys

The second big story of the month is stranger than the first, and it needs one piece of background.

The padlock in your browser works because a company called a certificate authority vouches for your website. It signs a certificate saying "this really is yourbusiness.co.ke". Browsers trust a small list of these companies, and that trust is what stops somebody putting up a fake version of your bank's website.

In October it emerged that eMudhra, an Indian certificate authority, had generated eight of its signing keys catastrophically badly. Instead of unguessable numbers hundreds of digits long, the keys were whole numbers below 256. One of them was the number four. A researcher recovered all eight on a laptop in under a second.

What actually happened, and why it was contained

The weak keys were created at a key ceremony on 30 April 2025, when a testing deviation hit a software flaw and produced a second, weaker set of keys that were then picked by mistake because the labels looked alike. They sat there for about eighteen months.

A researcher reported it on 17 October 2026. The response was unusually fast:

• 17 October, within about two hours: Chrome blocked the six affected web certificates. Mozilla independently recovered the keys itself and had Firefox blocking them the same evening.
• 18 October: eMudhra revoked all eight, declaring the keys compromised.
• 20 October: Firefox, Microsoft and the underlying security libraries shipped updates.
• 22 October: eMudhra announced it is leaving the global TLS certificate business altogether.
• 27 October: Chrome removes the affected root certificate entirely.

Crucially, no forged certificate has ever been found. Google reported that no certificate issued under those keys had been publicly logged before it blocked them, which is the mechanism that would have caught an attack. There is no evidence anybody got there first.

Three details worth being precise about

• Whose keys were weak. The eight weak keys belonged to the certificate authority, not to individual websites. Your own website’s private key was never involved.
• How it compares. In the 2011 DigiNotar case, forged certificates were actually used against real people and the company collapsed. Here there is no known misuse, and eMudhra is exiting one product line.
• Who had to patch. Mostly not browsers. Chrome, Firefox and Edge protected users through revocation lists within hours, with no update needed. The patching work falls on other software that makes secure connections: servers, backup tools, programming language runtimes and containers.

Does this affect Kenyan websites?

Almost certainly not, and we can be specific about why. The certificates being distrusted belong overwhelmingly to one customer group: of roughly 30,800 affected certificates still in date, nearly all belong to InCommon, which serves universities in the United States. Kenyan sites overwhelmingly use Let's Encrypt, Cloudflare, cPanel's automatic certificates or Sectigo, none of which are involved.

There is one Kenyan connection worth stating precisely, because it is easy to read the wrong way. eMudhra has been licensed by the Communications Authority of Kenya as an Electronic Certification Service Provider since July 2025. That licence covers digital signature and e-signature services, which are a different product line running on separate infrastructure, and eMudhra says those services are not affected. If your organisation relies on eMudhra for digital signatures, ask them in writing rather than assuming either way.

If you run servers, backup jobs or build pipelines that make outbound secure connections, apply this week's operating system and runtime updates. That is where the real work of this incident lands.

The Other Half of the Story: the Platforms Holding Your Keys

While PHP took the headlines, something quieter was happening to the platforms that store other companies' secrets. At least five were broken into in the same few weeks.

Why this matters, in plain terms. Every modern website and app holds keys: the password to its database, the secret that lets it charge a card, the token that lets it send email, the key that lets it call an AI service. Those keys are kept as settings on whatever platform runs the app. Steal that list of settings and you do not need to hack the website at all. You already have everything the website uses.

Whether this touches you at all

Most Kenyan business websites sit on ordinary shared hosting and are untouched by any of this. But if you have a custom application, a mobile app backend, a booking or payments system, or anything a developer built and deployed for you, ask one question: where are its keys stored, and has that platform had an incident this month? If nobody can answer, that is itself the finding.

Rotating a key, properly

This is the part almost everyone gets wrong. Changing a key inside your hosting panel does not cancel the old one. The old copy keeps working until the company that issued it cancels it.

Work in order of what can hurt you: money first (payments, cloud, AI services), then database passwords, then email and messaging, then anything that signs people in, then the platform's own tokens last. If you can already see spending you cannot explain, reverse the order and cancel the old key immediately, accepting a few minutes of downtime.

Two habits this month has rewarded: delete keys you have stopped using, because a forgotten key is still a working key, and give each application its own key so one leak does not open everything you own.

Why This Is Suddenly Happening

October was not bad luck, and understanding the cause tells you what to plan for. The explanation has two parts, and the second is easy to overstate.

Part one: the numbers really have changed

Counts compiled by security researcher Jerry Gamblin from the National Vulnerability Database, excluding rejected entries. The 2026 figure runs to 30 September.

Read those three numbers again. Nine months of 2026 produced half again as many published vulnerabilities as the whole of 2025. Forecasters expected about 66,000 for the full year and were overtaken by September. That is the real backdrop to October, and it is not going to reverse.

Part two: AI's role, stated honestly

You will be told that armies of AI agents are now finding flaws faster than anyone can fix them, and that this is why the chart has gone vertical. Part of that is true and part of it is sales talk, so here is the line between them.

What is documented: the PHP flaws themselves were found with AI assistance. Three organisations are credited in the official records, and each says it used AI models in the work. One researcher described finding the first flaw with help from a language model and no special tooling. A security firm said a single researcher did in a week what would previously have taken a world-class team months. Separately, Mozilla has credited AI-assisted review with finding hundreds of bugs in Firefox.

What is not established: that AI is why the overall count exploded. The researcher who compiles those annual figures attributes the growth largely to something far more boring: a handful of organisations that now publish vulnerability records in bulk, and a big expansion in how and what gets catalogued. When VulnCheck examined vulnerabilities attributed to AI-assisted discovery in the first half of 2026, it found 1,061 of them, of which 14, or 1.3%, were confirmed as actually exploited by anyone. Its assessment was that AI's capabilities have been overhyped relative to the available evidence.

There is also a human footnote worth keeping. The PHP flaws trace back to a human security audit in 2024 that flagged the underlying area; a developer fixing one of those older reports noticed the first sign of this problem. And the PHP Foundation is explicit that AI helps its team sort and validate reports, but a person makes every call and writes every patch.

What the attack numbers actually showed

Cloudflare's chief executive published a progression that has been quoted everywhere: thousands of attempts to exploit the PHP flaw across their network in the ten hours before public announcement, tens of thousands within forty-five minutes after it, hundreds of thousands within two hours, and millions by the following day.

Two things to hold onto about that. First, those are attempts, not successes: automated scanning of the whole internet, most of it hitting servers that were already patched or never vulnerable. Second, it is one company's own telemetry, published by a company that sells protection against exactly this, so it is a useful indicator rather than an independent measurement. The direction is the point, and the direction is not in dispute: within hours of a fix becoming public, every server on the internet is being tested for it.

Eight Details Worth Getting Right

This story moved quickly and the detail matters, because several of these points change what you should actually do. Here is the record on each, with the source named in every case.

One framing is worth holding on to, because it changes how you should feel about the month. October was a disclosure wave, not an attack wave. A great deal of software got fixed in a short window, largely because researchers and vendors were coordinating. That is the system working loudly, not the system failing. The danger is not that the flaws were announced. It is the window between the announcement and your own update.

What This Means in Kenya

Kenya's exposure to a PHP flaw is close to total, and the numbers are not in dispute.

W3Techs technology surveys for the .ke domain and for Kenya-hosted sites, read 23 October 2026. These describe the sites W3Techs can measure, not every Kenyan website.

So when a flaw appears in PHP itself, it is not a niche developer story here. It is nearly every business website in the country, nearly every school portal, and nearly every government site.

The official Kenyan response, accurately described

On 21 October the State Department for ICT and the Digital Economy, with the ICT Authority, issued a critical advisory to all ministries, departments and agencies. It requires them to treat it as urgent, inventory every PHP system starting with internet-facing ones, engage their hosting providers and developers, review logs, and consider restricting access or taking systems offline where they cannot be secured. It sets no deadline, and says further guidance will follow.

That advisory was aimed at government, and it was a reasonable one. But here is what we found when we went looking for public guidance aimed at businesses, on 23 October:

For context on scale rather than on this incident: KE-CIRT's own quarterly report for July to September 2026 recorded more than 2.69 billion cyber threat events detected in Kenya, up 14.45% on the previous quarter, with web application attacks alone at 27.4 million, up 57.62%. It names inadequate system patching among the causes, and lists academia among the sectors most affected by web attacks.

Who in Kenya should worry most, in order

1. Anyone on PHP 7 or older. Worldwide, about a quarter of PHP sites still run version 7 and nearly 8% run version 5. Versions between 5.4 and 7.3 get no fix at all, ever. If that is you, the fix is not a patch, it is a move to a supported version, and it should be scheduled this month.
2. Schools, colleges and universities on Moodle. Moodle's registry records 744 registered Moodle sites in Kenya. Moodle is PHP, and older Moodle releases cannot run the PHP versions that carry the fix.
3. Anyone running a store on Magento or a site on Drupal, both of which had their own critical fixes in the same fortnight. Drupal is unusually common on Kenya-hosted sites, at about 15% of those with a known content system.
4. WordPress sites using the Bricksforge plugin, because that flaw is confirmed as actually exploited, unlike the PHP ones.
5. Everyone else: ask your host the question, confirm your backups, and move on with your week.

A pattern worth noticing

No Kenyan website has been reported hacked or taken offline because of the PHP flaw. But Kenyan sites have been getting compromised steadily through much more boring routes. The threat intelligence firm CYFIRMA counted more than 120 defacements of Kenyan domains between May 2025 and March 2026, mostly .co.ke addresses, and attributed them to opportunistic attacks on outdated content systems, outdated plugins and misconfigured shared hosting. Government sites were defaced in November 2025, and the State House website was defaced again in July 2026.

In other words: the thing most likely to take down a Kenyan business website this year is not a 9.2-rated flaw in PHP. It is a plugin nobody updated for eighteen months. The October panic is a good reason to fix that, and a bad reason to think the danger only arrives with a news cycle.

If the worst happens, the clock is legal as well as commercial

This part gets ignored until it is urgent. If personal data is accessed in a breach and there is a real risk of harm to the people it belongs to, Kenya's Data Protection Act 2019 gives you 72 hours. Section 43(1)(a) requires a data controller to notify the Data Commissioner "without delay, within seventy-two hours of becoming aware of such breach", and to tell the affected people in writing within a reasonably practical period. If you miss the 72 hours, your notification must explain why it was late. If you process data for someone else, you have 48 hours to tell them.

Penalties under section 63 run to KES 5 million, or 1% of annual turnover for an undertaking, whichever is lower. Separately, the Computer Misuse and Cybercrimes Act 2018 obliges operators of computer systems to report attacks and intrusions to the national coordination committee within 24 hours. Take legal advice on how these apply to your particular business rather than relying on a blog, including ours.

How to Check Your Own Site Today

If You Cannot Patch Immediately

The PHP project published interim measures. They reduce exposure; they do not make a server safe, and they are not a substitute for updating.

• Set session.upload_progress.enabled=0 in php.ini or the FPM pool configuration
• Set memory_limit=-1 as an administrator value and keep post_max_size low
• On PHP 8.5, set fatal_error_backtraces=0
• Put a web application firewall in front of the site, such as Cloudflare, understanding that Cloudflare itself called its rules a stopgap
• Restart all PHP workers after any change, or the old code keeps running

If you are on PHP 8.1 or older, the real fix is to move to a supported branch. PHP 8.2 itself reaches end of security support on 31 December 2026, so anything older has been unsupported for some time.

If Your Site Is Already Down or Hacked

Whether this flaw is the cause or not, the recovery is the same, and the order matters.

1. Take it offline properly. Return a 503 status rather than deleting pages, so search engines treat it as temporary.
2. Preserve the evidence. Keep server and access logs from at least two days before the incident. Do not wipe and reinstall before anyone has looked.
3. Patch PHP and everything else before restoring, or you restore straight back into the same hole.
4. Restore from a backup taken before the compromise, not the most recent one.
5. Rotate every credential on that server: database passwords, admin accounts, API keys, hosting and email passwords. The flaw can leak memory, so assume secrets are gone.
6. Clean, then verify: remove unknown admin users and unexpected PHP files, then request a review in Google Search Console if your site was flagged.

Preventing the Next One

There will be a next one. The businesses that come through these events calmly have five things in place before they are needed:

• A supported PHP version, updated by a host who patches quickly and says so
• Daily off-site backups with a restore somebody has actually tested
• Updates applied on a schedule, tested before they go live
• Two-factor authentication on the site, the hosting, the domain and the DNS
• Someone watching, so you learn about trouble from monitoring rather than from a customer

The single thing that separated well-run sites from badly-run ones this month was not budget or technology. It was how many hours passed between a fix existing and somebody applying it. In this incident the internet started scanning for unpatched servers within hours. Nobody can shorten that window for you after the fact, which is why it is bought in advance.

If you would rather do it yourself, that is a legitimate choice and we have written it down for you: the security and speed audit checklist takes about an hour, and the WordPress malware cleanup guide covers the recovery sequence in full. Our free website checkup is the fastest way to get a second opinion on where you stand today.

Where every fact above comes from

We published nothing in this article that we could not trace to a named source, and we left out several widely repeated figures because we could not. All of the following were read on 23 October 2026.

• The PHP flaws: the PHP project's announcements, its security advisories, the PHP Foundation's account of the leak and the corrected severity score, and PHP's supported versions page.
• Official guidance: CISA, the UK National Cyber Security Centre and CERT-EU.
• Exploitation evidence, on both sides: watchTowr, Huntress, Rapid7 and Cloudflare.
• The certificate failure: Mozilla, Google, Cisco Talos and eMudhra's own statement.
• The platform breaches: Railway's preliminary report and the reporting of BleepingComputer.
• Other October advisories: GitLab, Node.js, nginx, Drupal and Moodle.
• Vulnerability counts and the AI question: Jerry Gamblin's annual reviews and VulnCheck's State of Exploitation.
• Kenya: W3Techs surveys of .ke sites, KE-CIRT's quarterly reports, the reported government advisory, CYFIRMA's Kenya threat landscape report and the Data Protection Act 2019.

We have left three things out: a count of hacked websites, a Kenyan figure for sites on end-of-life PHP, and a causal link between AI and the rise in vulnerability counts. No credible source publishes the first two, and the third is disputed by the people who compile the data.

Frequently Asked Questions

What happened with PHP in October 2026?

On 21 October the PHP project released emergency patches for two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell and rated 9.2. In the wrong conditions they could let somebody who has never logged in run code on the server. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Were lots of websites actually hacked?

Nobody has published a count of compromised websites, and the expert record is genuinely split. Amazon's security chief described the flaw as broadly exploited and watchTowr saw exploitation on its sensors from 21 October, while CISA said that day it had observed none and Huntress saw none across its customers. Neither flaw has been added to the US catalogue of vulnerabilities known to be exploited. The large government outages were organisations switching their own systems off while they patched, not attackers taking them down.

How severe are the PHP flaws?

Both are rated 9.2 out of 10 by the PHP project on the current version 4 severity scale, which places them in the critical band. On the older version 3 scale used by the US National Vulnerability Database, CVE-2026-109618 scores 9.8. Either way they are critical, and the action is the same: update.

Does the eMudhra certificate problem affect my website?

Almost certainly not. The certificate authority eMudhra generated eight of its own signing keys as whole numbers below 256, one of them the number four, so they could be recovered instantly. Those were the authority's keys, not individual websites' keys, and no forged certificate has ever been found. Of the roughly 30,800 affected certificates still in date, nearly all belong to InCommon, which serves universities in the United States. Kenyan sites overwhelmingly use Let's Encrypt, Cloudflare, cPanel AutoSSL or Sectigo, none of which are involved. Click the padlock in your browser and read the issuer name to be certain.

How long do I have to report a hacked website in Kenya?

If personal data was accessed and there is a real risk of harm to the people it belongs to, section 43(1)(a) of the Data Protection Act 2019 requires you to notify the Data Commissioner without delay and within 72 hours of becoming aware of the breach, and to tell the affected people in writing within a reasonably practical period. A late notification must explain the delay, and a processor has 48 hours to tell the controller. Penalties under section 63 reach KES 5 million or 1% of annual turnover, whichever is lower. The Computer Misuse and Cybercrimes Act 2018 also obliges system operators to report attacks to the national coordination committee within 24 hours. Take legal advice for your own situation.

My Kenyan hosting company has not said anything. What should I do?

Ask them directly, because as of 23 October we could not find a single public statement from any major Kenyan host confirming it had applied these patches, and KE-CIRT's public advisories page carries nothing newer than January 2019. Send one message: have you patched PHP against CVE-2026-109618 and CVE-2026-109619, and on what date? Silence is not evidence the work was skipped, but it does mean nobody is going to tell you unless you ask.

Does updating WordPress fix this?

No. This is a flaw in PHP itself, which runs beneath WordPress. It is fixed by the server's PHP being updated, which on shared hosting means your hosting company. Updating your plugins and theme is still worth doing, but it does not close this hole.

How do I check whether my site is safe?

Find your PHP version in cPanel under Select PHP Version or MultiPHP Manager, and compare it with 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Be careful, because many hosts backport the fix while keeping the old version number. The reliable step is to ask your host directly whether they have patched CVE-2026-109618 and CVE-2026-109619, and on what date.

What was Kenya's official response?

On 21 October the State Department for ICT and the Digital Economy and the ICT Authority told ministries, departments and agencies to inventory PHP systems, patch internet-facing ones first, and restrict access or take systems offline where they could not be secured. This was reported by The Star and Tech Trends KE on 22 October.

My website is down or hacked. What now?

Take it offline with a 503 status, preserve the server logs from before the incident, patch PHP and everything else before restoring, restore from a backup taken before the compromise, rotate every credential on that server, remove unknown admin users and unexpected files, then request a review in Google Search Console if you were flagged. We do this work, so send us the address and the hosting login.