Kenya Moved Fast On The PHP Flaw

On 21 October, two governments sent out urgent warnings about the same piece of software. In London, the National Cyber Security Centre (NCSC) published an alert for UK organisations. In Nairobi, the State Department for ICT and the Digital Economy, working with the ICT Authority, sent a critical advisory to every ministry, department and agency.

The software is PHP. The Kenyan advisory describes it as “a widely used server-side programming language that supports websites, web applications and digital service platforms.” Most people have never heard of it, but their websites run on it anyway.

PHP is the language that sits on a web server and builds the pages people see. It pulls stories from a database, runs the login page and processes the payment form. WordPress runs on it. So do many news sites, online shops, government portals and university systems. It is also built into other products, from hosting dashboards to business software, often without the buyer knowing.

What Went Wrong

The PHP team has fixed two linked flaws, CVE-2026-109618 and CVE-2026-109619, now widely known as PHP2Shell. Kenya’s advisory notes that each is rated 9.2 out of 10 for severity and has “the potential to expose affected systems to remote code execution.” Both flaws come down to how PHP tidies up after each visitor. If an attacker pushes PHP to run out of memory at the wrong moment, it can be left holding half-prepared data that it then treats as valid. Leftover data from one visitor can also linger and get picked up by the next.

Together, these slips can corrupt the server’s memory. Under certain conditions, a skilled attacker can use that corruption to run their own commands on the server. They need no password and can do it from anywhere. The Kenyan advisory spells out what is at stake. “Given the widespread use of PHP in web-based systems, these vulnerabilities may pose a significant risk to the confidentiality, integrity and availability of Government information systems and online public services,” it says.

Two Governments, One Message

The UK and Kenyan advisories say much the same thing. Find every system running PHP, starting with those open to the internet. Update as soon as the fix is out. Kenya tells institutions to “prepare to apply the relevant security updates immediately upon their official release.”

Both also raise the option of switching systems off. The NCSC tells organisations that can’t patch quickly to “consider taking the system offline.” Kenya’s advisory goes further and thinks about the citizen on the other end. Where a system can’t be secured promptly, it says, institutions should consider restricting access or taking it offline, but “such decisions should be coordinated with the relevant service owners to manage operational and public-service implications.”

This is a practical point. A government portal going dark affects people trying to pay for a permit or renew a licence.

The advisory also tells institutions to check their logs for “unusual requests, unauthorised access, unexpected file modifications, suspicious processes and other indicators of compromise.” And it warns against leaning on stopgaps. “Temporary protective measures should not be treated as a substitute for applying the official security updates.”

The Outsourcing Admission

Two points in the Kenyan advisory stand out.

The first is about outside suppliers. Institutions are told to “engage relevant hosting providers, software developers and service providers to establish exposure, confirm remediation arrangements and obtain assurance that affected components have been secured.” Many government systems are built and run by outside firms, and the institution that owns a website may not be the one able to fix it.

The second is about accountability. “Institutions unable to implement the required measures immediately shall document the outstanding risks, the compensating controls in place and the planned remediation timelines,” the advisory says.

That turns “we’ll get to it” into a written record someone can be held to. The ICT Authority will coordinate support and, in the advisory’s words, monitor “implementation of the recommended measures.” ICT directors must keep records of what they have done and escalate any high-risk problems they can’t resolve.

Not A First In 2026

This is not a one-off. In May, PHP fixed a critical flaw in its SOAP feature that also allowed remote takeover. In July, more fixes followed across every current version. The NCSC alert links to its own guidance on preparing for a “vulnerability patch wave.” Urgent fixes are coming more often, and organisations need to be ready to act within days.

Attackers did not wait for the fix. Details of the flaws leaked on 20 October, a day before PHP released its patch. Cloudflare reported early attack attempts on the morning of 21 October, and Amazon says it saw an attempt as far back as 17 October. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Kenya’s advisory says more guidance will follow “as additional information becomes available.”

Kenya’s response, a same-day, critical-level advisory with clear steps and someone accountable for follow-up, is what a working warning system looks like. But it was addressed to ministries, departments and agencies. “All Government institutions are required to treat this advisory as urgent,” it says. The rest of the web is a different story.

A great deal of Africa’s web runs on PHP outside government: SME online shops, NGO sites, private schools, saccos, local media and churches. Many were built by a freelance developer who has since moved on. They sit on cheap shared hosting. No one inside the organisation knows what software the site runs, let alone that a government advisory went out this week.

The UK alert was written for any organisation. Kenya’s alert was written for government. While both approaches are valid, the second leaves a question open. Who tells the shop owner in Nyeri or the school bursar in Kisumu that their website may need attention? Part of the answer may lie with hosting companies and web developers, who manage thousands of these sites for their clients. US-based InMotion Hosting, for instance, says it applied PHP’s recommended temporary fix across every server it manages. If they patch, their clients are covered without having to understand any of this.

What You Can Do Now

For CIOs, the first step is knowing what you have. Which of your systems run PHP? Which of your vendors’ products bundle it? Who is responsible for the website your marketing team commissioned three years ago? If the answer is “not sure,” then that is the gap to close this week. The Kenyan advisory’s approach is worth borrowing, whether you work in government or not. Ask your suppliers directly whether they are exposed. Get their answer in writing. If you can’t fix something straight away, write down the risk, what you’re doing in the meantime and when you’ll finish.

Then look past your own walls. Your partners, suppliers and the smaller organisations in your network may be running the same software with no one watching it. A short message to them costs little. Kenya has shown it can move quickly to protect government systems. The next step is making sure the warning reaches everyone else running the same software.