By 
Two critical vulnerabilities in the PHP engine, collectively named PHP2Shell, can let an attacker run commands on a web server without logging in, and the fix has to be installed on the server itself, not in a website's plugins or themes. The PHP project released patched versions on 21 October 2026, a day earlier than planned, after details leaked online. Kenya is more exposed than most markets: W3Techs data puts PHP on 82.4% of .ke websites whose programming language can be detected.
The flaws are tracked as CVE-2026-109618 and CVE-2026-109619. The PHP security team rated each 9.2 out of 10 on the CVSS v4.0 scale, according to the project's advisory as summarised by security firms including Datadog Security Labs and Tenable.
What the two vulnerabilities do
Both bugs sit in the core runtime that executes PHP code, which means a site can be vulnerable even when its own code is clean. That distinction matters for Kenyan site owners, because many assume that updating WordPress, a theme or a plugin is enough. It is not. WordPress has said no WordPress update is required for this issue, and that site owners should check the PHP version shown under Site Health in the dashboard, according to the WordPress announcement.
According to the PHP advisory as relayed by Help Net Security and SOCRadar, the two flaws work as follows:
CVE-2026-109618 is described as remote code execution through out-of-memory corruption. When a request pushes PHP past its memory limit, the engine can be interrupted while internal request data is only partly set up. The cleanup routine that follows then treats that incomplete data as valid.
CVE-2026-109619 is described as remote code execution through stale global state. After a fatal error, some persistent variables can keep pointing to request memory that has already been freed. A later request handled by the same worker process can then read from or write to that memory.
An attacker can craft HTTP requests that deliberately trigger memory exhaustion or fatal errors to corrupt memory and steer execution. Datadog reported reproducing the out-of-memory corruption on PHP 8.5.11 with an unauthenticated HTTP POST request. Wiz, one of the discoverers, says the two CVEs group four memory-safety issues and that other variants exist that the identifiers do not cover.
Some researchers describe the bugs differently. Sansec and JFrog characterise both as use-after-free flaws and report that CVE-2026-109618 can also leak memory, in the style of Heartbleed, through a session cookie in the upload-progress handler. Sansec says leaked memory could include passwords, session tokens, API keys and TLS private keys belonging to other requests. Wiz made a similar claim about process memory leakage.
On scope, Wiz says every PHP version from 5.4, released in 2012, onward is affected by at least one of the flaws. It reported confirmed unauthenticated code execution against WordPress, Drupal and Joomla test installs. Sansec said researchers confirmed the same against Magento 2.4.9 and ten other PHP applications. The PHP advisory identifies Apache with mod_php as the most exposed setup, with a demonstrated exploit that fires before any application code loads. That means a WordPress security plugin cannot block it. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also listed as at risk.
How the disclosure unravelled
Wiz says it found the first flaw on 19 August 2026 and reported both to PHP on 24 August, working with tools that included its own Wiz Atlas platform and models from Google and OpenAI. Separately, OpenAI says researchers at the security firm Calif found one of the flaws using its GPT-5.6 Sol model under its Patch the Planet programme. The PHP Foundation credited Calif, OpenAI and Wiz, among others. The Calif researcher named in the Foundation's account is Ryan A.
Coordinated disclosure had been planned for 22 October. According to SecurityWeek and Tenable, the CVE identifiers appeared on Hacker News and social media on 20 October, and the identifiers that circulated carried an incorrect CVSS score of 10.0, as the PHP Foundation put it. The PHP security team published an advance notice the same day. Towards AI reported that Calif also mistakenly posted a video of its working proof of concept. Chainguard published patched container images about six hours before the official release, which the PHP Foundation said let attackers study the fix in binary form while other users waited.
The Foundation moved the release forward by a day. Fixes landed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The Foundation said its team inspected proof-of-concept code that appeared after the leak and found no functional exploit at the time of release.
The Foundation also acknowledged that early signs of the underlying memory problem surfaced through work tied to a 2024 Quarkslab audit organised through OSTIF, but that difficult compatibility decisions and limited specialist capacity delayed a full fix. The Foundation described the delay as a structural failure.
Governments pull sites offline
The response outside Kenya was unusually blunt. The US National Security Agency and the FBI's cyber division advised organisations that cannot update immediately to take affected systems offline until they can. The UK's National Cyber Security Centre issued a similar warning. Japan's prime minister, Sanae Takaichi, posted on X asking anyone running a public website to check for PHP and prepare to patch, and said temporarily taking a site down was one effective way to cut the risk.
Finland's government and the Dutch House of Representatives disconnected websites, per Cybersecurity Dive. In Japan, pixiv, DMM, niconico and the shop builder BASE moved into emergency maintenance. Wikipedia's entry on the incident notes that Wikimedia's Phabricator was disabled as a precaution.
Cloudflare said it deployed web application firewall protections nine hours before public disclosure and later reported attack traffic aimed at its customers, including payloads altered to evade its filters. Amazon Threat Intelligence said its MadPot honeypot network recorded an exploitation attempt on 17 October, four days before disclosure, according to Help Net Security. SOCRadar noted that as of 21 October, PHP had not reported in-the-wild exploitation and the US Cybersecurity and Infrastructure Security Agency (CISA) had not added either flaw to its catalogue of known exploited vulnerabilities. watchTowr reported attack attempts but said none had succeeded. Attempted exploitation and confirmed compromise are different things, and no confirmed breach had been made public at the time of writing.
The Kenyan picture
Kenya's Ministry of Information, Communications and the Digital Economy, through the State Department for ICT and the ICT Authority, issued a critical advisory dated 21 October 2026. It directs ministries, departments and agencies to find every website, application and server running PHP, including systems managed by third-party providers, and to apply fixes in priority order, starting with internet-facing systems.
Where a system cannot be secured immediately, agencies are told to restrict external access or take it offline. The advisory also calls for log reviews to look for suspicious requests, unexpected files and unusual processes, for evidence to be preserved where an incident is suspected, and for agencies to report through government cybersecurity channels. Agencies that cannot patch promptly must record residual risks, compensating controls and a remediation timeline.
The advisory covers the public sector. By 8 PM Nairobi time on 21 October, neither the Communications Authority nor the National KE-CIRT/CC had published an advisory on its website. That leaves private businesses, schools, SACCOs and small online shops to work out their own exposure. The same outlet's analysis of W3Techs figures found WordPress on 84.5% of .ke sites that use a content management system, which places a large share of Kenyan sites squarely in the affected stack.
For most of those sites the practical decision belongs to the hosting provider. On shared hosting, the host controls the PHP version, and site owners generally cannot patch it themselves. Fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or later, or a patched package from a Linux distribution such as Ubuntu, Debian or RHEL. Owners who see an older number in their dashboard have a direct question for their host: whether a patched package is installed, and if not, when.
The legacy problem
The harder cases are older installations. The PHP project no longer releases updates for PHP 8.1 and earlier. Its security team published source-code fixes for 7.4, 8.0 and 8.1, with nothing for anything older, and some distributions and paid support vendors offer their own backports. W3Techs figures show 27% of identifiable PHP sites still run PHP 7 and 7.7% run PHP 5.
Moving those sites to a supported release can break old themes and plugins, which takes longer than a single night of work. For Kenyan organisations running ageing custom systems, often built by contractors who have since moved on, the practical choices narrow to a vendor backport, a web application firewall in front of the site, or taking the site offline. The PHP project itself says interim settings reduce exposure but are not a complete fix, and security vendors including Qualys note that updating is the only full remedy. PHP 8.2 itself reaches end of life on 31 December 2026, according to Brandefense, so sites patched to 8.2.35 now will face another migration within weeks.
What administrators are being told to do
Guidance across PHP, Cloudflare, the NSA and Kenya's ICT Authority converges on a short list:
Upgrade PHP to a fixed release for the branch in use, or install a vendor-backported package, and confirm the running service actually uses it. They stressed that updating themes, plugins or application code does not correct a flaw in the runtime.
Apply PHP's interim settings only as a stopgap. Qualys published a mitigation that disables the PHP session upload-progress feature across web-facing runtimes.
Review web, endpoint and network logs for unexpected requests, files and processes, and preserve evidence if a compromise is suspected.
Where a server was exposed to the internet without firewall protection before patching, and given researchers' reports that process memory can leak, treat database credentials, API keys and session secrets on that server as potentially exposed and rotate them. This is a precaution drawn from the Sansec and Wiz findings, not an instruction in the PHP advisory.
Cloudflare and the ICT Authority both note that a web application firewall helps buy time but does not replace the patch.
The episode also arrives at a point when AI tooling is shortening the distance between a bug existing and a bug being exploited. Wiz said a single researcher with frontier models completed in a week work that would previously have taken a specialist team months, though that is the firm's own assessment, and Calif cautioned that no model finds all bugs from simple prompts. For hosts and administrators in Kenya, the practical effect is a smaller window between a patch appearing and attackers working out what it fixes.
Comments