Essentially, the PHP team is deflecting and abdicating their responsibilities in all this mess they created. "Chainguard broke embargo", "support us with money", "we are just volunteers", "we had knowledge years ago but no POC because we wanted to ship features and not security fixes". All just deflections.
This fiasco shows me that I would never use PHP for any project I'm part of. The PHP team royally messed up, and they are deflecting the blame left, right, up, and down.
Yes, we live in a new world now and need to handle disclosures differently by learning from this experience. The first major RCE disclosure that came with 3rd party leaks of this era was bound to cause these issues no matter who it affected. Let's hope the next one is better.
The major mistake I see in this incident on the disclosure side that kicked this all off was Calif posting their video early because they took vibe coders on X at their word. Maybe the early notice by PHP of an upcoming release was a mistake in hindsight given how people reacted.
[] Is this standard in the security researcher world? Let's beat embargo by a few hours and cause extra panic by putting more people at risk?
No serious project should use PHP.
We use it ourselves in our deployments, and yesterday I released it free under MIT license, for anyone who is unwilling or unable to patch their PHP (which is probably millions of servers right now):
If a system is accessible by someone else, it is inherently insecure and needs to be hardened.
>5.3.7 upgrade warning: [22-Aug-2011] Due to unfortunate issues with 5.3.7 (see bug#55439) users should postpone upgrading until 5.3.8 is released (expected in a few days).
No seriously, he's literally as careless as he claims to be (when he says that repeatedly, you should believe him!), and his lack of giving a shit about things like tests and encryption and security that are extremely important has caused actual serious security problems, like breaking crypt() by checking in sloppy buggy code that would have caused a unit test to fail, but without bothering to run the unit tests (because so many of them failed anyway, so who cares??), and then MAKING A RELEASE of PHP 5.3.7 with, OF ALL THINGS, a broken untested crypt()!
Does anyone think that's just his sense of humor, a self deprecating joke, breaking then releasing crypt() without testing, that's funny in some context? What context would that be? Do they just laugh and shrug it off with "lol let Rasmus be Rasmus! ¯\_(ツ)_/¯ "?
https://www.reddit.com/r/programming/comments/jsudd/you_see_...
>r314434 (rasmus): Make static analyzers happy
>r315218 (stas): Unbreak crypt() (fix bug #55439) # If you want to remove static analyser messages, be my guest, but please run unit tests after
https://web.archive.org/web/20140818115440/http://svn.php.ne...
https://web.archive.org/web/20111014213651/https://plus.goog...
>Rasmus Lerdorf
>+Lorenz H.-S. We do. See http://gcov.php.net
>You can see the code coverage, test case failures, Valgrind reports and more for each branch.
>The crypt change did trigger a test to fail, we just went a bit too fast with the release and didn't notice the failure. This is mostly because we have too many test failures which is primarily caused by us adding tests for bug reports before actually fixing the bug. I still like the practice of adding test cases for bugs and then working towards making the tests pass, however for some of these non-critical bugs that are taking a while to change we should probably switch them to XFAIL (expected fail) so they don't clutter up the test failure output and thus making it harder to spot new failures like this crypt one.
Unfortunately, if you read the announcement as referring to 14:00 UTC, that's several hours after Chainguard published their images. I don't know if it's plausible that people saw the Chainguard builds, understood the issue from those and built exploits, but a precise timeline would help understand better.
Sure about that?
Not my understanding of how the LLMs currently work. There’s a cutoff date and no new info after that date is included in training.
Info to the contrary welcome.
However, I’ve done some original research regarding an area that the internet has wrong and that doesn’t seem to have back propagated yet.
You are almost certainly correct in terms of how the public models work. I guess it's possible that the labs have some tools connected for more recent stuff like this, but it seems unlikely.
It could also just have been a run-of-the-mill exploit in WordPress.
And an odd little cluster of potential attempts it caught just after 9am GMT. Again I can't see any reason why I would be getting multipart form posts to those URLs, it's definitely an exploit, but it's possible there's another older exploit with that pattern. They aren't WP-type URLs though.
Also this post from Amazon is embarrassing. They knew about it from the 17th yet failed to meet the embargo timeline and patch Amazon Linux (their patch is due to be released today the 22nd of Oct).
Something that would lead to an uncontrolled memory corruption, potentially leading to a crash, or something that indicates a real, code-executing exploit? Those two kinds events are of very different significance. I can't read from Amazon's announcement which one they think they saw.
The PHP foundation needs to give a better answer for why they were asleep at the wheel for 2+ months while insiders were sharing/selling the info.
https://github.com/amazonlinux/amazon-linux-2023/issues/1148
I don't think this blog post is sending the message AWS intended...
"Subsequently, from 2026-10-21 0200 UTC to 2026-10-21 0800 UTC, Amazon Threat Intelligence identified additional exploitation attempts of PHP2Shell targeting MadPot from additional anonymized infrastructure." (i.e almost 12 hours before the release of the patch)
"Invest in detections that don’t rely on a signature for a specific CVE. The first exploitation will often come before those signatures exist."
"We analyze over 200 billion events per minute and integrate threat intelligence from our MadPot honeypot network to identify and block known exploitation attempts in real time. Our honeypot system provides us with early detection of exploitation attempts, enabling rapid response and threat analysis."
Same as none of their AMIs for bottlerocket have emSign revocations.
Absolutely shit company who puts their customers at risk.
Last I checked, Amazon has also not patched their Lightsail blueprints for WordPress, or even communicated about the vulnerability with those customers at all, which is arguably way worse, because
(a) by design, all-in-one blueprints aren't really intended to use system PHP or have system PHP updated in a meaningful way; and
(b) hosting static sites such as WordPress is 90% of the selling point of Lightsail as a product
Meanwhile, WAFs are being continuously updated with detection signatures.
As for WAF rules, those can usually be flipped on and off with a single switch.
The trouble is if the WAF change e.g. messes up a redirect or turns a success response into an error response or vice versa, which confuses some other system into giving multiple users the same session cookie and gives them access to one another's accounts or writes corrupt entries to the database or whatever it is. You can revert the rule but that doesn't revert the state changes that have already happened.
There is inherently a trade off between keeping the system online, keeping the system patched and testing the patch before applying it.
Sometimes. In a world in which customers are increasingly adopting immutable infrastructure patterns and (contrary to best practice) using Launch Templates with symbolic references to `latest` versions of AMIs, this isn't always easy.
> There is inherently a trade off between keeping the system online, keeping the system patched and testing the patch before applying it.
On this we agree 100%.
Any vendor that delivers updated packages without thorough regression testing that ends up causing an incident for their customers as a result will get a thrashing from the community. Remember the CrowdStrike BSOD incident in 2024?
Maybe Ubuntu and others are cutting corners to deliver more quickly. It's their risk to take, but it's still a risk.
If you need to test it you should pin packages.
Unfortunately people rarely follow best practices.
Customers frequently do risky things like using launch templates that refer to the latest AMI. AMI changes, Auto Scaling launches a new/replacement instance in the fleet without adequate testing, *boom*.
To the person at amazon that thought this was a good press release to put out, I know this is what you were hoping for, so here it is, "wow, so cool". Not sure why, but AI really has everyone running around with desperate loser aura.
Maybe next time, do better, actually patch some things so your customers are covered?
