Security advisory: PHP: News Archive - 2026
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.
If using PHP, either patch or take your web server offline until patched.
Already being exploited in the wild as of a few days ago - so could be too late but it may be worthwhile examining server logs for evidence of exploitation.
Yeah Raptor computer forum is off.
Thanks for the heads up. I just checked the PHP version on my server and discovered that I was 3 versions behind, so I needed to upgrade.
I suspect that both of these security holes could have been prevented if PHP was written in a memory-safe language.
As a general idea, that is certainly plausible but really you would have to know more about the internals of PHP’s data structures to be sure.
Even in a memory-safe language, if a program is multi-threaded (as would likely be the case here), it is possible for a thread to see objects or data members in an inconsistent state and be tricked into misbehaving. The question then is whether the error can be exploited e.g. as a RCE. So the exploit is likely to be less severe in a memory-safe language. But you will note that one of the vulnerabilities seemingly relates to an out-of-memory situation, which a memory-safe language may actually deal with less well than a traditional language.
There’s also the bigger picture question of … OK, so the web server has been compromised by an RCE exploit and arbitrary code is executing in the web server’s environment. How bad does it get?
Maybe the web server only has read-only access to most of its config and other files, so they cannot be corrupted and the exploit can’t be made persistent, and the web server has no access at all to files relating to other types of server running on the same computer by virtue of the operating system’s underlying security model. Maybe the web server is containerised so that it has limited access to anything at all outside its container (unless this exploit is blended with any one of the many container-escape vulnerabilities).
Or it could be at the other end of the spectrum e.g. worst case is that the web server is running as root on the actual computer and RCE means entire computer is toast.
I am already seeing probe attempts in my web server logs.
One of them is using a User-Agent of php2shell-109618, which might be a whitehat / security researcher. Another though was just a vanilla (presumably fake) User-Agent.
Maybe. Hard to know.
It’s curious to note that while PHP is memory safe, it is written in C which is not memory safe. For the record:
It is not just php vulnerabilities, there are huge huge new vulnerabilities everywhere…
I think new deeepseek 4.1-flash is the culprit as it ship mythos level to make this thermonuclear-explosion-of-vulnerabilities.
I am learning AI via Apex. The Intranet is our best Shelter for AI defender.
Librem 5, Librem 14 is the only one to enable real Intranet via HKS.
It-is-the-beginning-of-the-end-of-the-internet.
I am ready for the intranet, i enabled 60TB on Raptor Computer.
I have my doubts. It is equally possible that a blackhat human asked an AI to exploit the world at large, but the AI inserted its own glitchy concept of morality and defaulted to telling the other side of the connection what it is doing without informing the blackhat human. Might be dangerous to assume.
The space aliens and CIA/NSA always had access to these hacks. These are just being disclosed by AI now. We used internet before the hacks leaked, when it was equally as dangerous, why would people stop now?
Discussion on Hacker News:
Steal my Bitcoin
0.65 hours without a successful hackThere is a bitcoin key hidden on this server worth about $502. It is accessible to the PHP user account through the print-flag binary. This PHP version was selected from before the PHP2SHELL CVEs were released. First person to get the wallet wins. If you don’t need the money, consider donating it to those who do: givewell.org. All traffic is logged. This is a known vulnerable machine, so we cannot guarantee privacy. Other attackers may access or monitor activity and data beyond our control. Do not submit anything you want to keep private. Challenge wallet Explorer ↗ bc1qlnu5…t3cxqy 0.00625104 BTC ≈ $502.35 USD stealmybitcoin.com · Terms of participation
True that it was just speculation on my part. Either way, there is no danger to me from this exploit specifically because there is no PHP in use at all.
OK. Update. Currently saying:
My bitcoin was stolen after: 19.28 hours.
To be honest, I wouldn’t “panic over” loss of Bitcoin because I wouldn’t be leaving any Bitcoin sitting on a web server. However if the operator of that web site thinks that this kind of exploit doesn’t work then best of luck to him/her.
Even
All traffic is logged.
needs to be treated with caution. A bad compromise may be able to alter logs so as to remove evidence of the compromise. You really need to be mirroring or sending logs off-host (or logging traffic in the network itself).
Discussion: Steal My Bitcoin CTF PoC | Hacker News
This is a good point. Alternatively, if this is a VM, and the logs are copied to another VM(s) in real time, it might be reliable, too.
For $500 he can look in the logs and find all manner of new exploits, or new deviations of the existing ones, he can then sell for thousands. Clever business model lol
(quote from the first discussion)
There are or have been some escapes though. I wouldn’t put total trust in a VM to protect logs, particularly if deliberately inviting the internet to compromise you. 
If this is really his/her business model then the logs are critical “intellectual property”.
I also wonder about encrypted traffic. If I can cause RCE then my payload can implement secure communications in such a way that traffic logging by itself is insufficient to determine what was sent and received.
And another critical RCE for PHP: CVE-2026-115560
No details officially recorded in the CVE but descriptions available on the web e.g. https://vulners.com/cve/CVE-2026-115560 or e.g. GitHub - ivst/CVE-2026-115560: CVE-2026-115560: PHP session upload progress mitigation · GitHub
As there’s no patch yet, best to mitigate if the (reportedly unusual) conditions are met for this exploit to work at all.
And another for PHP: https://www.cve.org/CVERecord?id=CVE-2026-119977
amosbatto’s point about a thread seeing inconsistent state applies even more once containers come in. I run a small PHP-based storefront for a craft co-op here in New Mexico, and the advice to isolate the web server is what worries me: we’re on a single VPS with the database as a neighbor, so an RCE could reach more than a container would allow. I’m weighing whether to split services or just harden file permissions first. Separately, I saw Hackers exploit *sshole OpenSSH flaw on musl Linux systems, which makes me wonder if we’re patching the wrong layer entirely. Anyone run a similar one-box setup?
I think it was actually my point, but to be clear … I was not referring to a specific vulnerability, much less a specific vulnerability in PHP. I was referring to a generic potential vulnerability for any multi-threaded program running in a memory safe language environment. That is, “memory safe” does avoid some really common exploits but it does not avoid all of them.
I don’t run PHP. (Honestly, I am concerned about its history and its present regarding security problems. I realise that’s not much help to you.)
With that disclaimer, I think the advice to isolate may be referring to using a container inside a single VPS - or even multiple containers inside a single VPS.
But my first piece of advice would be to maintain a high level of awareness regarding exploits as they are discovered and patch patch patch.
And containers don’t change that advice given the number of container-escape vulnerabilities in recent times.
Note, CVE-2026-119977 is a WordPress bug, not a PHP bug (though WordPress is written in PHP). It is a “Time Of Check, Time Of Use” bug in the WordPress upgrade process. It is fixed in WordPress 7.1.4.
Upgrade your WordPress site if you are below 7.1.4, as this is being actively exploited.
Sorry, my bad. Either way … @amosbatto !