The PHP Vulnerability and Metabunk/Sitrec

[Mick West]

Article:

21 Oct 2026
Security advisory: Critical remote code execution vulnerabilities, update now
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Source: https://www.php.net/index.php

This has been mitigated for the Metabunk forum. But Sitrec is still waiting for some updates to be published and so is going to be offline for a while.

 

[Mick West]

This is going to be quite a big deal.

Article:

Executive Summary
Wiz Research uncovered multiple critical vulnerabilities in core PHP, a popular general-purpose scripting language that powers 70% of all websites in the world. Successful exploitation could allow attackers to take control of affected servers, steal sensitive data, and deface the websites running on them.

PHP is a backbone of the web: it's the programming language powering WordPress, Joomla, Drupal, Wikipedia's MediaWiki, and many others.

These vulnerabilities include memory disclosure and unauthenticated remote code execution in PHP itself, independent of the application running on top of it, putting every affected website in immediate risk.

Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4. Attackers can exploit them remotely, in some cases fairly easily. Immediate patching is strongly advised.

On October 21, 2026, PHP released the patch fixing multiple memory-safety vulnerabilities in the core engine.

These findings rank among the most severe vulnerabilities discovered in PHP, and arguably in software history. The underlying flaws had been present for decades, but demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit.

Source: https://www.wiz.io/blog/php2shell-php-rce

 

[Kyle Ferriter]

Them not putting out official patches or binary/container builds for anything prior to 8.2 is going to be a problem for years. Sure the release schedule says they only officially support back to 8.2 and this will motivate orgs to upgrade faster, but multiple pre-auth RCEs that affects every install for the last 10+ years seems severe enough to warrant breaking the official policy on this and they shouldn't rely on 3rd party distributors to implement the backports and older-version builds.

 

[jdog]

The flipside of vibe coding is vibe hacking.

 

[FatPhil]

Does PHP have the equivalent of Coverity and other static and dynamic code analysis tools? If it doesn't, perhaps the finger-pointing towards C at being "not memory safe" was unfounded. The last time I used PHP, was in 2006, when I was working for a finnish company hawking ringtones to drunk people who could either not read or type...
It was garbage then, real dumb-arse-stupid insecurities literally everywhere, I'd be amazed if it's improved much since. You design in security, not retrofit it.

 

[Kyle Ferriter]

Does PHP have the equivalent of Coverity and other static and dynamic code analysis tools? If it doesn't, perhaps the finger-pointing towards C at being "not memory safe" was unfounded.

It does have analyzers but the PHP runtime is written in C and both of these CVEs are memory management bugs in that C code. It can be hard to identify these bugs because the scenarios they arise in can be complex and the language itself allows you to do unsafe things.

Write-up:
https://www.wiz.io/blog/php2shell-php-rce

Summary table from that article:

+-----------+------------------+--------------------+--------------------+
| Tracking  | Bug              | What an attacker   | What we            |
| ID        |                  | can achieve        | demonstrated       |
+-----------+------------------+--------------------+--------------------+
| CVE-2026- | Upload-progress  | Corrupt process    | Pre-authentication |
| 109618    | unserializer     | memory and         | RCE on WordPress,  |
|           | use-after-free   | execute code       | Drupal and Joomla  |
|           |                  |                    |                    |
|           | Remote           | Unauthenticated    | Application-       |
|           | process-memory   | disclosure of PHP  | agnostic remote    |
|           | disclosure       | worker memory      | memory disclosure  |
+-----------+------------------+--------------------+--------------------+
| CVE-2026- | Fatal-error      | Corrupt process    | Pre-authentication |
| 109619    | backtrace        | memory and         | RCE on Drupal      |
|           | use-after-free   | execute code       |                    |
|           |                  |                    |                    |
|           | OPcache type     | Corrupt shared PHP | Pre-authentication |
|           | confusion        | state and          | RCE on WordPress   |
|           |                  | execute code       |                    |
+-----------+------------------+--------------------+--------------------+

(note: the "what we demonstrated" column does not mean the vulnerability is limited to those applications)

There is memory-unsafe C code all over the place, not yet discovered, but in active use in production systems, and AI tools are going to probably increase the frequency with which those are discovered.

Quote from the wiz.io article:

Turning these flaws into working exploits required chaining multiple bugs and accounting for how PHP allocates and reuses memory across requests. Memory bugs are notoriously complex; differences in PHP versions, configurations and application behavior can break assumptions the exploit depends on. An attack that works against one deployment may need substantial adjustments to work against another, each requiring further analysis, testing and debugging. Pre-AI, this manual work would be difficult to implement and even harder to scale.
With AI this is no longer a barrier. LLMs can help adapt an exploit to different PHP versions, configurations and memory layouts. With testing and debugging tools, models can analyze failures and iterate on adjustments, reducing the specialist effort required for each target. This significantly lowers the barrier to scaling attacks across different deployments.

 

[Mauro]

Are only websites at risk, or also people browsing them could be harmed?

 

[Kyle Ferriter]

Looks like Ubuntu has released backported fixes to php 5/7.0/7.2/7.4/8.1, and Red Hat has to 7.4

https://ubuntu.com/security/CVE-2026-109618#status
https://ubuntu.com/security/CVE-2026-109619#status
https://access.redhat.com/security/cve/cve-2026-109618#cve-affected-packages
https://access.redhat.com/security/cve/cve-2026-109619#cve-affected-packages

 

[jarlrmai]

Article:

21 Oct 2026
Security advisory: Critical remote code execution vulnerabilities, update now
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.

Source: https://www.php.net/index.php

This has been mitigated for the Metabunk forum. But Sitrec is still waiting for some updates to be published and so is going to be offline for a while.

Sitrec seems to be up for me..