The PHP project shipped emergency security updates on October 21, 2026 for two critical flaws that can let an attacker run their own code on a web server, and WordPress, the software behind many business, school and church websites in Nigeria, is built on PHP. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and the PHP Foundation’s release note told site owners plainly that “if you run PHP, it is imperative that you update now.”
Both bugs, tracked as CVE-2026-109618 and CVE-2026-109619, are rated 9.2 on the CVSS scale. The release came a day earlier than the planned October 22 date because details leaked, and the Foundation said proof-of-concept code started circulating afterwards. Its security team hadn’t seen a working exploit when the fixes went out, though it also said a leaked demo video and early patched builds gave attackers a head start on studying the problem.
| Flaws | CVE-2026-109618 and CVE-2026-109619 |
|---|---|
| Severity | Critical, CVSS 9.2 |
| Released | 21 October 2026 |
| Fixed versions | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| Setups at risk | PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed |
| PHP 8.1 and older | No official release, source backports only |
| PHP 8.2 end of life | 31 December 2026 |
AI models helped researchers dig these bugs out of PHP’s core
OpenAI said its models helped researchers working under its Patch the Planet initiative find the flaws, describing PHP in an official post on X as a language “used to run an estimated 70% of websites”. The company said it spent the past two months leading a coalition of PHP maintainers and researchers so the fixes could land together, and it has published a longer account of how the disclosure was coordinated.
The first bug is triggered when a request hits PHP’s memory limit at the wrong moment, leaving half-built internal data behind that PHP later treats as valid. On Apache with mod_php, the Foundation said, a request from someone who isn’t logged in can trigger it before any of the website’s own code runs, and full remote code execution was demonstrated with default settings. The second bug lets a fatal error leave internal state pointing at memory from a previous visitor’s request, which a later request on the same worker can then reuse. The official advisory for CVE-2026-109618 and the advisory for CVE-2026-109619 carry the technical detail for developers.
Your hosting company holds the fix, so find out which PHP you’re on
On most shared hosting plans you don’t install PHP yourself. The provider runs it on its servers and you pick a version from the control panel, which means your site is only protected once your host has installed the October 21 builds. If you have a WordPress admin login, go to Tools > Site Health, open the Info tab and expand Server. The PHP version is listed there.
If the number reads 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer in the same branch, the fix is in place. Anything lower in those branches means your host hasn’t updated yet, so open a support ticket and ask directly whether the PHP security releases of October 21, 2026 have been installed on your server and when they will be. Keep the CVE numbers in the message, because they give the support desk something precise to check.
Sites still on PHP 8.1 or older have a bigger job this weekend
PHP no longer releases updates for 8.1 and older, so there’s no official 8.1 or 7.4 version with the fix. According to php.net, the security team published minimal source backports for PHP 7.4, 8.0 and 8.1 for people who compile PHP themselves, and some Linux distributions and long-term support vendors offer patched builds. For a typical WordPress site on shared hosting, the realistic route is switching to a supported version in your control panel after taking a full backup and checking that your theme and plugins work on it.
Don’t stop at 8.2 if you’re making that move, because PHP 8.2 reaches end of life on 31 December 2026 and you’d be back in the same position in ten weeks. It’s the same logic as moving off Windows 11 24H2 before its updates run out, where waiting only leaves you exposed for longer.
Running your own server? Update, restart, and use the stopgaps only if you must
If you manage a VPS or cloud server, install the patched PHP packages for your distribution and restart PHP-FPM or Apache so the workers load the new build. For servers that can’t be updated straight away, php.net lists temporary settings that reduce exposure, while warning that they don’t make an installation safe.
- Set session.upload_progress.enabled=0 in php.ini or the FPM pool, then restart the workers. PHP says not to rely on ini_set() or .user.ini for this.
- On PHP 8.5, set fatal_error_backtraces=0 and restart the workers.
- Set memory_limit to -1, preferably through php_admin_value, and keep post_max_size low (8M without uploads, 32M with them).
PHP also published a smaller advisory on October 23 about session upload progress, tied to CVE-2026-115560, which only affects an unusual configuration and recommends the same upload progress setting until the next bugfix release. If you already switched that setting off for the October 21 bugs, leave it off.
For most Nigerian site owners, none of the server settings above will be yours to change, and that’s fine. The number on your Site Health screen is what decides whether you’re covered, and a two-line ticket to your host is the fastest way to move it if it’s still behind.
