PHP maintainers said Monday that they planned to release patches for two vulnerabilities, both with severity ratings of 9.2 out of a possible 10.
[...]
The maintainers published the advisory following the leaking of purported details, which have yet to be confirmed. The report showed a video of an exploit tool dubbed PHP2Shell executing code on webservers running WordPress 7.1.3, MediaWiki 1.46.2, phpBB 3.3.17, Magento 2.4.9, Joomla 6.2.0, Laravel 13.36.0, Laravel 8.83.29, Symphony 8.1.9, Drupal 11.4.10, and WHMCS 9.0.9, all of which use PHP. A video depicting the tool has been reposted here.
[...]
Attempts to locate the unconfirmed report were unsuccessful, but security firm watchTowr said it claimed to affect every PHP version from PHP 5, released in 2004, onward. The security firm went on to say it has confirmed that the vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, are real.
Researchers from separate security firm Sansec said they “expect mass attacks to start within 15 minutes of the release.” A third security firm, Webfence, also urged admins to prepare now. Huntress has also issued an advisory.
Preparation steps include identifying who is responsible for managing PHP inside an organization, taking an inventory of every app built on the language, planning a maintenance window starting at 14:00 UTC with contingency plans for earlier, making a backup of site and database files, and monitoring the PHP.net homepage for any late-breaking announcements, including an earlier release time. Some experts suggest unplugging any non-essential systems until they’re patched.
As someone with only a cursory understanding of IT vulnerabilities and no industry experience whatsoever, how does this compare with other recent exploits? The below quote gave me a moment for...
As someone with only a cursory understanding of IT vulnerabilities and no industry experience whatsoever, how does this compare with other recent exploits? The below quote gave me a moment for pause:
PHP maintainers said Monday that they planned to release patches for two vulnerabilities, both with severity ratings of 9.2 out of a possible 10.
Considering this would affect WordPress and Mediawiki, as well as anything using "[any] PHP version from PHP 5, released in 2004, onward", I'm assuming this will be causing some serious headaches in the days ahead?
This is basically catastrophic, probably at LEVELS EXCEEDING Heartbleed or Shellshock from like a decade ago. From my circles, it seems to be as easy as basically "paste something into the address...
This is basically catastrophic, probably at about the scale of LEVELS EXCEEDING Heartbleed or Shellshock from like a decade ago. From my circles, it seems to be as easy as basically "paste something into the address bar, free server".
Considering that neither of those exploits were subject to LLM agents, that's quite terrifying. Here's hoping that some of the slower moving systems (government, community, etc) are quick to adapt...
Considering that neither of those exploits were subject to LLM agents, that's quite terrifying. Here's hoping that some of the slower moving systems (government, community, etc) are quick to adapt before too much damage is done.
Assuming that this impacts you directly - Good luck.
Just the rumor of a security hole is often enough to find it these days, using LLM’s. They don’t need to wait for the patch to build an exploit. And it sounds like this has already happened, based...
Just the rumor of a security hole is often enough to find it these days, using LLM’s. They don’t need to wait for the patch to build an exploit.
And it sounds like this has already happened, based on what people are saying on Hacker News.
Rumors are swirling, we'll only know for sure once it officially releases. But a PHP core dev was spotted on Mastodon saying in response to those rumors that the only mitigation is...
Rumors are swirling, we'll only know for sure once it officially releases. But a PHP core dev was spotted on Mastodon saying in response to those rumors that the only mitigation is patching/upgrading. The LLM-located bug there can seemingly easily be mitigated by INI tweaks.
EDIT: A PHP Release Manager has been spotted on Reddit echoing similar sentiments.
...Well. Tomorrow will be interesting to see the fallout of this. Currently it's 12:30 am and I'm operating on less than 4 hours of sleep, so brain is a bit fuzzy. I made a website for my cousin's...
...Well.
Tomorrow will be interesting to see the fallout of this.
Currently it's 12:30 am and I'm operating on less than 4 hours of sleep, so brain is a bit fuzzy. I made a website for my cousin's senior day center business using Wordpress, and am trying to figure out if I should try to get in and temporarily shut it down. As far as I remember, the only information it collects should be the contact form for people's names, emails and phone numbers (and last I checked, most of the responses are honestly bots). So not sure how urgent/serious that one is.
If I do shut it down, I'm also not sure how to best go about that because A) brain fuzzy, and B) I've never had to shut down a site. Made more complicated by the fact that I don't know if I can access the actual web host (Bluehost). Last I remember it requires 2FA from my cousin's email or phone. I still have admin access to the WP panel at least, but if I have to do it from Bluehost itself I can't do much right now.
(...And writing that just made me realize that Bluehost itself may also be vulnerable. And I am definitely not clear-headed enough to... Contemplate and search into the potential ramifications of that...?? I can't even come up with words. Of all the days to be horrifically sleep deprived...)
So I humbly ask you, lovely people of Tildes who are both more awake and more experienced: should I shut it down, and if yes, what's the best way to take a Wordpress site offline in this case?
back to googling "does [insert every site I use] use PHP" to see how many of them night be down or on fire tomorrow
If a PHP dev is saying turning off a server would be sensible... I wish I could help you with the how since it looks like you're in a pickle but if you can figure it out you probably should.
Well, my brain has woken enough that your comment let me know to google "can you turn off server from Wordpress admin panel". And after some tweaks to that, because it keels recommending plugins...
Well, my brain has woken enough that your comment let me know to google "can you turn off server from Wordpress admin panel". And after some tweaks to that, because it keels recommending plugins for maintenance mode (which I don't think will help in this case)...
Google's AI says I'd need to use Cpanel. Which is on Bluehost. Which I cannot access at 2:3p am because my cousin is asleep and has the 2FA info. Never a problem until tonight since I could do whatever little help she needed from the Wordpress dashboard.
It also said something about blocking PHP access to .htaccess and/or folders. And... Any other night, I could go down that rabbit hole and figure it out at 2:30 am because I'm basically nocturnal and don't get tired until like 3 or 4. But tonight, my brain is definitely not up to the task and is already flagging again while writing this comment. Definitely not good enough to risk messing with the site that deeply right now without a solid guide on how to mitigate damage right now.
I think I'm resigned to not being able to shut down the site tonight. I'm hoping the fact it's for a small-town day center for people with dementia means it's not exactly disastrous. The site is just for people to get info and contact her, so at most they should just get names, emails, phone numbers and the fact that Bob Personman is the Caretaker of Alice Oldwoman, and is reaching out to ask about tours and would prefer to be contacted by email.
(Honestly more concerned about Bluehost itself being potentially vulnerable. The only financial and serious personal info of any sort that should be tied to this site should be my cousin's billing information on there.)
That said: if anyone can tell me a concrete method to specifically minimize damage from within the Wordpress dashboard, I'll do it. Unfortunately, I do need some specific actions specific to working with Wordpress, because my brain is in a state where I can't fully "translate"... Or maybe "parse"...? general terminology, to figure out what to do. (Can't even think of fitting words...)
At this rate I'll probably only be awake for another hour at best before I crash for good. Only reason I'm even awake right now is probably because I'm waiting for my sleeping mask to dry after desperately washing it a few hours ago.
I've been dealing with this for the last couple hours, here are some useful bits of info: Before I get to anything else: Just shut everything down, there are good reasons to believe this is...
I've been dealing with this for the last couple hours, here are some useful bits of info:
Before I get to anything else: Just shut everything down, there are good reasons to believe this is historic level fucked up. Put up a static file explaining and take the hit.
That said, I looked at the code for the POC that's been circulating and assuming the POC shows the full extent of the problem you can mitigate this without taking sites offline by:
Disabling multipart form handling at the server level. Or if you're behind something like cloudflare, you could do it there instead. This will stop the parser that is believed to be the source of the problem from ever running. It will also disable certain form actions on the site
Or to be extra safe, disabling POST entirely. No one will be able to login or search but the site stays online serving most things.
If you decide to try one of the above, it's key that the actions are disabled before PHP runs, don't try to mitigate this from within PHP.
I chose to take everything offline, in my case I don't have anything running on PHP that's going to lose sales or otherwise be overly expensive. If that wasn't the case, I'd be satisfied that the above mitigations would be a reasonable risk to take but I'd also add defense in depth by limiting what PHP could access and probably putting something between PHP and the database to reject suspicious actions.
Right now it looks like there will be botnets running exploit probes en masse before the patches are out (in 8 hours or so). Probably that's already happening. So take this seriously.
From the article:
[...]
[...]
According to discussion on Hacker News, it is already being exploited.
As someone with only a cursory understanding of IT vulnerabilities and no industry experience whatsoever, how does this compare with other recent exploits? The below quote gave me a moment for pause:
Considering this would affect WordPress and Mediawiki, as well as anything using "[any] PHP version from PHP 5, released in 2004, onward", I'm assuming this will be causing some serious headaches in the days ahead?
This is basically catastrophic, probably at
about the scale ofLEVELS EXCEEDING Heartbleed or Shellshock from like a decade ago. From my circles, it seems to be as easy as basically "paste something into the address bar, free server".Considering that neither of those exploits were subject to LLM agents, that's quite terrifying. Here's hoping that some of the slower moving systems (government, community, etc) are quick to adapt before too much damage is done.
Assuming that this impacts you directly - Good luck.
Just the rumor of a security hole is often enough to find it these days, using LLM’s. They don’t need to wait for the patch to build an exploit.
And it sounds like this has already happened, based on what people are saying on Hacker News.
Rumors are swirling, we'll only know for sure once it officially releases. But a PHP core dev was spotted on Mastodon saying in response to those rumors that the only mitigation is patching/upgrading. The LLM-located bug there can seemingly easily be mitigated by INI tweaks.
EDIT: A PHP Release Manager has been spotted on Reddit echoing similar sentiments.
...Well.
Tomorrow will be interesting to see the fallout of this.
Currently it's 12:30 am and I'm operating on less than 4 hours of sleep, so brain is a bit fuzzy. I made a website for my cousin's senior day center business using Wordpress, and am trying to figure out if I should try to get in and temporarily shut it down. As far as I remember, the only information it collects should be the contact form for people's names, emails and phone numbers (and last I checked, most of the responses are honestly bots). So not sure how urgent/serious that one is.
If I do shut it down, I'm also not sure how to best go about that because A) brain fuzzy, and B) I've never had to shut down a site. Made more complicated by the fact that I don't know if I can access the actual web host (Bluehost). Last I remember it requires 2FA from my cousin's email or phone. I still have admin access to the WP panel at least, but if I have to do it from Bluehost itself I can't do much right now.
(...And writing that just made me realize that Bluehost itself may also be vulnerable. And I am definitely not clear-headed enough to... Contemplate and search into the potential ramifications of that...?? I can't even come up with words. Of all the days to be horrifically sleep deprived...)
So I humbly ask you, lovely people of Tildes who are both more awake and more experienced: should I shut it down, and if yes, what's the best way to take a Wordpress site offline in this case?
back to googling "does [insert every site I use] use PHP" to see how many of them night be down or on fire tomorrow
If a PHP dev is saying turning off a server would be sensible...
I wish I could help you with the how since it looks like you're in a pickle but if you can figure it out you probably should.
Well, my brain has woken enough that your comment let me know to google "can you turn off server from Wordpress admin panel". And after some tweaks to that, because it keels recommending plugins for maintenance mode (which I don't think will help in this case)...
Google's AI says I'd need to use Cpanel. Which is on Bluehost. Which I cannot access at 2:3p am because my cousin is asleep and has the 2FA info. Never a problem until tonight since I could do whatever little help she needed from the Wordpress dashboard.
It also said something about blocking PHP access to .htaccess and/or folders. And... Any other night, I could go down that rabbit hole and figure it out at 2:30 am because I'm basically nocturnal and don't get tired until like 3 or 4. But tonight, my brain is definitely not up to the task and is already flagging again while writing this comment. Definitely not good enough to risk messing with the site that deeply right now without a solid guide on how to mitigate damage right now.
I think I'm resigned to not being able to shut down the site tonight. I'm hoping the fact it's for a small-town day center for people with dementia means it's not exactly disastrous. The site is just for people to get info and contact her, so at most they should just get names, emails, phone numbers and the fact that Bob Personman is the Caretaker of Alice Oldwoman, and is reaching out to ask about tours and would prefer to be contacted by email.
(Honestly more concerned about Bluehost itself being potentially vulnerable. The only financial and serious personal info of any sort that should be tied to this site should be my cousin's billing information on there.)
That said: if anyone can tell me a concrete method to specifically minimize damage from within the Wordpress dashboard, I'll do it. Unfortunately, I do need some specific actions specific to working with Wordpress, because my brain is in a state where I can't fully "translate"... Or maybe "parse"...? general terminology, to figure out what to do. (Can't even think of fitting words...)
At this rate I'll probably only be awake for another hour at best before I crash for good. Only reason I'm even awake right now is probably because I'm waiting for my sleeping mask to dry after desperately washing it a few hours ago.
As far as I can tell my Nextcloud server hadn't been hit yet, but it's been shut off for now. I'm suddenly really glad I did my pre-bed tildes scroll.
I've been dealing with this for the last couple hours, here are some useful bits of info:
Before I get to anything else: Just shut everything down, there are good reasons to believe this is historic level fucked up. Put up a static file explaining and take the hit.
That said, I looked at the code for the POC that's been circulating and assuming the POC shows the full extent of the problem you can mitigate this without taking sites offline by:
If you decide to try one of the above, it's key that the actions are disabled before PHP runs, don't try to mitigate this from within PHP.
I chose to take everything offline, in my case I don't have anything running on PHP that's going to lose sales or otherwise be overly expensive. If that wasn't the case, I'd be satisfied that the above mitigations would be a reasonable risk to take but I'd also add defense in depth by limiting what PHP could access and probably putting something between PHP and the database to reject suspicious actions.
Right now it looks like there will be botnets running exploit probes en masse before the patches are out (in 8 hours or so). Probably that's already happening. So take this seriously.