By Sege Peter, ENG

Every few years a vulnerability lands that is not in a plugin, a theme or a forgotten admin panel, but in the engine underneath them all. This October it is PHP itself. Two flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed "php2shell", allow an attacker with no password and no account to attempt to run their own code on a web server. For Kenya, where W3Techs data cited by local tech outlets shows PHP behind roughly 82 per cent of .ke websites whose language can be detected, this is not a foreign story. It is our county portals, school websites, SACCO dashboards, online shops and newsrooms.

What actually broke

Both bugs sit in the PHP interpreter, below WordPress, Laravel, Joomla or any custom code. The PHP project rates each 9.2 on the CVSS 4.0 scale, which is critical.

The first, CVE-2026-109618, is a memory-corruption bug in how PHP cleans up after running out of memory. If an allocation fails while a request is only half set up, PHP's cleanup code treats the incomplete data as valid. Rapid7 notes that specially crafted multipart requests, the same format used for file uploads, can trigger this even while appearing to respect a server's configured limits. Apache with mod_php is the highest-risk setup, because the cleanup runs even when the request fails at the very start, before any application code is involved.

The second, CVE-2026-109619, is a use-after-free across requests. A PHP worker process serves many visitors one after another. If a fatal error or timeout interrupts the cleanup between them, internal state can be left pointing at memory that has already been freed, and the next request on that worker can read or abuse it. PHP has confirmed paths through the session upload-progress feature and, on PHP 8.5, through fatal-error backtraces.

In plain terms: a stranger sends carefully shaped traffic to your website, and in the wrong conditions the server ends up running the stranger's instructions. That is what "remote code execution" means, and it is why the name ends in "shell".

The timeline so far

Amazon Threat Intelligence says its honeypots recorded an exploitation attempt on 17 October, four days before anything was public, and recommends that investigations start from that date. The PHP project gave advance notice on 20 October and shipped fixes on 21 October at 14:00 UTC: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Researchers at Calif, Wiz and OpenAI are among those credited, and Calif has said AI models were used in the research.

Public proof-of-concept code appeared within a day. Rapid7 found that each early exploit worked only for a specific mix of operating system, PHP build and web server. That changed on 24 October, when security researcher Adel Karimi reported confirmed code execution on three honeypots running PHP 8.4.26 under Apache mod_php, findings Expel researcher Marcus Hutchins described as the best confirmation of in-the-wild exploitation he had seen. Karimi cautioned that a single-worker setup is not a measure of reliability elsewhere. On 26 October, Trail of Bits said the exploit works against unpatched PHP 8.2 through 8.5, and the US Cybersecurity and Infrastructure Security Agency (CISA) added both CVEs to its Known Exploited Vulnerabilities catalogue.

Palo Alto Networks' Unit 42 counts more than 22.6 million internet-exposed instances that are potentially vulnerable.

Kenya's response

Kenya moved early. On 21 October, the Ministry of Information, Communications and the Digital Economy, through the State Department for ICT and the ICT Authority, directed ministries, departments and agencies to secure every PHP website, web application and server, including those run by contractors. Agencies were told to prioritise internet-facing systems, apply the official fixes, review logs for suspicious requests and unexpected files, and restrict access or take a system offline if it cannot be secured immediately. The advisory says web application firewalls are a supplement, not a substitute for patching.

That is the right instruction. My concern is the long tail outside government: thousands of small businesses on shared hosting, NGOs whose website was built once by a friend in 2019, and county and school sites still running PHP 7.x because "it works". Those are exactly the systems most likely to be forgotten this week.

What to do today

1. Find every PHP install you own. Not just the main website. Check staging copies, old subdomains, admin tools, phpMyAdmin, monitoring dashboards and any vendor appliance with a web interface. CISA's first recommendation is an inventory, including PHP bundled inside other software.

2. Patch to a fixed release. The safe versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12 or later. Linux distributions and long-term-support vendors received patches in advance, so a distribution package may carry the fix under a different version number; check its changelog for the two CVE IDs. PHP 8.1 and older get no official release. PHP has published minimal source backports for 7.4 to 8.1, and anything older than that is end-of-life with no fix. If you are still there, this is the week to upgrade.

3. On cPanel and CloudLinux hosting, check all three PHP families. Hosting guides note that EasyApache's ea-php packages, CloudLinux's alt-php (used by PHP Selector) and the system PHP are patched separately; updating one does not update the others. If you are on shared hosting, ask your provider in writing which builds are patched and when the workers were restarted.

4. Restart PHP. This is the step people skip. Installing a package does not fix processes already running. PHP-FPM pools, Apache and LiteSpeed's lsphp processes keep the vulnerable code in memory until they are restarted. If you suspect the server was probed, Google Cloud's guidance is to capture worker memory first, because a restart erases that evidence.

5. If you truly cannot patch yet, use the stopgaps properly. PHP's interim guidance is to set memory_limit=-1 and session.upload_progress.enabled=0 (and fatal_error_backtraces=0 on PHP 8.5) at server level, in php.ini or the FPM pool, not through ini_set() or .user.ini, which apply too late. Then restart every worker. Because the memory cap is removed, Rapid7 advises tightening post_max_size and blocking multipart uploads at the front end on sites that do not need them. Container memory limits alone are not a mitigation.

6. Look for signs of compromise. CISA's advice is to watch for PHP worker processes starting shells or downloading tools. Check for new or modified .php files in upload folders, unfamiliar admin accounts, and outbound connections you cannot explain. Start your review from 17 October.

Two traps to avoid

First, a regression: PHP has confirmed that 8.4.27 and 8.5.12 can crash processes in some applications that use the SimpleXML extension. PHP traced it to an unrelated garbage-collector fix in those releases, not to the security patches, and a fix has been merged but not yet released. If your site crashes after updating, roll forward when the fix ships rather than back to a vulnerable build.

Second, a third bug. On 23 October PHP disclosed CVE-2026-115560, another session upload-progress issue that it calls an unlikely route to code execution, because it needs an unusual combination of configuration and application code. There is no patch yet. The interim setting session.upload_progress.enabled=0 covers it as well, which is one more reason to apply it.

The bigger lesson

Most Kenyan organisations still treat a website as a one-off project: build it, launch it, forget it. php2shell shows why that model no longer holds. The gap between disclosure and working exploit was about a day, and the first attacks came before disclosure. Every organisation with a public website needs a named person responsible for patching, a list of what it runs, and a hosting contract that says how fast security updates are applied.

If you run a PHP site in Kenya, the honest summary is short: update today, restart everything, and check your logs back to 17 October.

Sege Peter is a Kenyan software engineer who builds and maintains web platforms.

Photos: Victor Grigas / Wikimedia Commons (CC BY-SA 3.0); PHP logo by Colin Viebrock (public domain).