Two critical flaws in PHP, the language most websites run on, let an attacker take over a web server without logging in. PHP released the fix on 21 October 2026 and attacks have been seen. Here is how to check your website is patched.
| Key fact | CVE-2026-109618 and CVE-2026-109619 |
|---|---|
| What | Two critical flaws in PHP itself, the programming language most websites run on. An attacker can run their own code on the server. |
| Affected | Every PHP release since 5.4 (2012) that has not been updated, however the server runs PHP (mod_php, PHP-FPM, LiteSpeed and others), in its default setup. |
| Fixed in | PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 October 2026. Some hosts add the fix to an older version number. |
| Severity | Critical. Both rated 9.2 (CVSS v4.0). |
| Needs a login? | No. The attack hits PHP before your website's own code runs. |
| Exploited? | Attempts seen (watchTowr, Cloudflare). No confirmed break-in reported as of 22 October. |
| Do now | Check your website's PHP has been updated. |
Updated 22 October 2026, after PHP's release. Facts checked against PHP's security advisory, Ubuntu, CloudLinux, watchTowr and Sansec. Sources are listed at the end.
What are CVE-2026-109618 and CVE-2026-109619?
PHP is the programming language behind most of the web. WordPress, Silverstripe, Drupal, Magento and Joomla are all written in it, so if your website has a content management system, it almost certainly runs on PHP.
On 21 October 2026 PHP fixed two critical flaws in PHP itself. PHP describes them as remote code execution "via OOM corruption" (CVE-2026-109618) and "via stale global state" (CVE-2026-109619). Both are rated 9.2 out of 10.
Remote code execution means someone on the internet can make your web server run their own instructions. That is the most serious kind of flaw a website can have, because it gives the attacker the same control over the server that your website has.
Sansec explains the cause: when PHP runs out of memory in the middle of handling a request, it can go on using memory it has already freed. A specially crafted form submission, of the kind used for file uploads, is enough to trigger it, and the faulty code dates back to PHP 5.4, released in 2012.
Why this one is different
Most website security problems sit in a plugin, a theme or the content management system. Those can often be patched or switched off on their own.
These two flaws sit underneath all of that, in PHP itself. Sansec puts it plainly: the attack paths "run inside PHP, before your store code". Nothing in your website's own code can stop it. The fix has to be made to the server.
The flaws need no login and affect more than a decade of PHP releases. PHP says "there are no complete mitigations, updating is the only safe choice."
Is it being exploited?
Attacks have started. watchTowr says it is "observing active exploitation attempts of both CVE-2026-109618 and CVE-2026-109619", and Cloudflare saw early attempts on 21 October, before the fix was even released. watchTowr says sites running PHP inside Apache (mod_php) carry "the highest demonstrated risk".
As of 22 October, none of the sources we checked had reported a confirmed break-in. Sansec expects mass exploitation now that the fix and write-ups are public.
What should you do now?
- Find out which PHP version your website runs. Your host or developer can tell you.
- Check it is a fixed version: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a build your host confirms includes the fix. Ubuntu and CloudLinux, for example, add the fix without changing the version number to match PHP's.
- If it is not fixed, have it updated now. Then have any temporary upload block removed.
- If your site runs PHP 8.1 or older, ask your host whether its build has been fixed. PHP no longer updates these versions, and many builds of them will stay vulnerable. Plan the upgrade either way.
Why updating is not the whole fix
If an attacker got in before the patch, updating PHP does not remove what they left behind. After patching, it is worth checking the site for files that should not be there, admin accounts nobody recognises, and changes to the home page.
An old PHP version is also a standing risk. Every future PHP flaw will hit it too, with no fix from PHP at all.
What this looks like with BLACKBX
On 21 October, ahead of the release, BLACKBX applied the interim settings and a temporary upload block across the servers it manages, and checked each one.
On 22 October we installed the fixed PHP builds, checked every PHP version on every server against the fixed list, removed the upload block on every patched server, and recorded the update, dated, in each client's logbook. Where a server cannot get a fixed build, because its operating system is past its support date, the interim protections stay in place and we have given the owner a plan to move it.
On the Monitor plan, findings like this go to the client's own developer with the version numbers and our advice, so they can act on them. On Maintenance and Full service, BLACKBX does the work. All plans are monthly, with no minimum term.
Timeline
Dates are in UTC, except BLACKBX's own actions, which are in Australian time.
| Date | Event |
|---|---|
| 20 October 2026 | Details leak (Sansec); an attack tool, PHP2Shell, is later made public |
| 20 October 2026 | PHP gives advance notice of two critical flaws |
| 21 October 2026 | ASD's ACSC issues a critical alert |
| 21 October 2026 | Silverstripe announces upcoming PHP patches for Silverstripe Cloud |
| 21 October 2026 | Cloudflare sees early exploitation attempts (Sansec) |
| 21 October 2026 | BLACKBX applies interim settings across the servers it manages |
| 21 October 2026, 14:00 UTC | PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (1:00 am AEDT, 22 October) |
| 21 October 2026 | Ubuntu releases fixed builds (USN-8948-1) |
| 21 October 2026 | watchTowr reports exploitation attempts against both flaws |
| 22 October 2026 | Silverstripe Cloud ships patched PHP; customers must redeploy each environment |
| 22 October 2026 | BLACKBX installs the fixed builds and removes the upload block wherever a fixed build is available |
Sources
- Security advisory: Critical remote code execution vulnerabilities, update now, PHP, 21 October 2026
- Critical vulnerabilities in PHP, ASD's ACSC, 21 October 2026
- USN-8948-1: PHP vulnerabilities, Ubuntu, 21 October 2026
- PHP CVE-2026-109618 and CVE-2026-109619, CloudLinux
- PHP remote code execution (PHP2Shell), watchTowr, 21 October 2026
- Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619, Sansec
- PHP security announcement and upcoming patches, Silverstripe, 21 October 2026
- Critical Remote Code Execution Vulnerabilities in PHP (CVE-2026-109618 & CVE-2026-109619), Beazley Security Labs
Common questions
Is my website affected by CVE-2026-109618 or CVE-2026-109619?
If your website runs on PHP and has not been updated since PHP's fix came out (1:00 am AEDT, 22 October 2026), assume yes. The flaw dates back to PHP 5.4, released in 2012, and affects every common way of running PHP on a web server, including LiteSpeed, which many shared hosts use. WordPress, Silverstripe, Drupal, Magento and Joomla all run on PHP, so most content-managed websites are in scope. Your host or developer can confirm which PHP version your site uses and whether it has been patched.
Which PHP versions fix it?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released at 14:00 UTC on 21 October 2026 (1:00 am AEDT on 22 October). Anything older on those branches is vulnerable, unless your host has added the fix to its own build.
My host's PHP version is lower than the fixed one. Am I exposed?
Not necessarily. Some hosts and Linux distributions add the fix to the version they already ship, without changing its number. Ubuntu 24.04's fixed build is 8.3.6-0ubuntu0.24.04.13, and CloudLinux, used by many cPanel hosts, says its fixed ea-php84 package is version 8.4.26, not 8.4.27. Ask your host whether its build includes the fixes for CVE-2026-109618 and CVE-2026-109619, rather than judging by the number alone.
Will PHP 8.1 or older be fixed?
PHP itself no longer releases updates for 8.1 or older. Because of the severity, its security team published source code fixes for 7.4, 8.0 and 8.1 for anyone building PHP themselves, and some vendors have released fixed builds, including Ubuntu for PHP 8.1 on Ubuntu 22.04 and CloudLinux for its older PHP versions. Many other builds of 8.1 and older will never be fixed. If your site runs an old PHP version, ask your host whether its build is fixed, and plan the upgrade either way.
Is anyone exploiting these flaws?
Attacks have been seen. Security firm watchTowr reports exploitation attempts against both flaws, and Cloudflare saw early attempts on 21 October, before the fix was released. As of 22 October, none of the sources we checked had reported a confirmed break-in. With the details and an attack tool public, assume any unpatched PHP server will be targeted.
Do the interim settings still matter?
Updating is the fix. PHP says there are no complete mitigations and updating is the only safe choice. If an upload block was added before the patch, have it removed once the patched version is installed, because it stops file uploads and some forms from working. The two session settings some hosts applied (turning off session upload progress and turning on strict session mode) are harmless to keep. If your server cannot be updated yet, keep all the interim settings in place: PHP says they reduce exposure but do not make a server safe.
Is this your site?
Not sure if your website has been patched?
Tell us your website address and we will tell you whether these PHP flaws apply to it. If they do, we will patch it and record exactly what we did.
Or call +61 2 9043 1246. Monthly plans, no minimum term.