Rendered at 15:36:13 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
andyvanosdale 9 minutes ago [-]
If this was being probed and/or exploited on October 17th, this throws shade on the PHP team for throwing shade on Chainguard in their public announcement.
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.
hyperpape 3 hours ago [-]
There's also a tweet by Matthew Prince that says Cloudflare saw thousands of attempts pre-announcement, https://x.com/eastdakota/status/2113079352682570051, then tens of thousands post announcement, and now millions.
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.
sullivanmatt 2 hours ago [-]
https://x.com/dok2001/status/2112811965735202970 was posted at 7:43 AM UTC on October 21, 2026, and Chainguard (according to the PHP Foundation blog post) shipped at 7:41 UTC. One of the big reasons Chainguard broke the embargo was because Cloudflare had been seeing attacks, IIRC.
00deadbeef 3 hours ago [-]
The Cloudflare one refers to the time period after the leak where people had already made PoCs. Amazon’s detection is days earlier which is quite concerning.
2 hours ago [-]
cubefox 3 hours ago [-]
So either there was another (but non-public) leak or someone else discovered the exploit almost at the same time as it was about to be published. I guess the latter is much less likely because it would be a major coincidence.
wahern 1 hours ago [-]
With everybody using LLMs there are no coincidences. Popular LLM platforms are like Oracles that help you identify what other people have been working on. "Find a bug in PHP" might have been useless s few months ago, but once somebody used it to develop a full exploit the LLM will start to regurgitate that information.
fn-mote 57 minutes ago [-]
> once somebody used it to develop a full exploit the LLM will start to regurgitate that information
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.
jonhohle 9 minutes ago [-]
Frontier models absolutely have access to current information. I just asked Claude about my fantasy football line up. It knew current injury reports, line ups and stats. Google search AI had even more information than that.
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.
disgruntledphd2 52 minutes ago [-]
> 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.
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.
post-it 2 hours ago [-]
The attacker may have known about the exploit for a long time and were saving it, but upon finding out that it was about to be disclosed, they decided it was now or never.
cubefox 48 minutes ago [-]
How could he have known on Oct 17 that it was about to be disclosed? The dates only leaked on Oct 20.
stickfigure 39 minutes ago [-]
You're asking: How could a hacker - with an exploit that potentially allows him/her to break into half the computers on the internet - know some secret information that is stored on a computer on the internet?
It could also just have been a run-of-the-mill exploit in WordPress.
VladVladikoff 3 hours ago [-]
I’ve seen probing for it in server logs but not actual exploiting of it. I think the botnets added it to their vulnerability scanners but I have yet to see any examples of an actual working exploit. There are hundreds of vibe coded attempts on github but none of them work to the best of my knowledge. Would love someone to prove me wrong here.
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).
onionisafruit 2 hours ago [-]
I don’t know when various parts of Amazon learned about it, but I don’t think this post means they knew about it on Oct 17. I think they looked at past logs from their honeypots and found a probe for php2shell happened on Oct 17.
boplicity 2 hours ago [-]
What makes you think they knew about it from the 17th? "...dating to Oct. 17, 2026" means that's when it happened. It doesn't mean they identified it on the 17th.
menomatter 3 hours ago [-]
Do they differentiate between attempts and successful infiltration? I’m trying to understand whether this exploit is easy to use or not. There was an article here from yesterday that argued the exploit was not easy to use and needed LFI
tylergetsay 1 hours ago [-]
I've been having trouble exploiting it from first principles even in lab conditions.
Tomdarkness 3 hours ago [-]
So Amazon knew about this exploit and that it was actively being used several days before the release of any patches. Despite this they still took 18 hours AFTER the release of the patches to provide updated version of their Amazon Linux packages?
I don't think this blog post is sending the message AWS intended...
boplicity 2 hours ago [-]
What makes you think they knew about it on the 17th? Scanning old logs is not the same as understanding them as they're generated.
Tomdarkness 2 hours ago [-]
If this is only a retrospective find then they should make it more clear, from the blog it reads to me as promoting their MadPot tool for detection pre CVE disclosure:
"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."
OtherShrezzing 1 hours ago [-]
My reading here is that they've gone through their logs retrospectively, because you can see these attempts to exploit pretty clearly in an observability platform, and the 17th is only five days ago, so you can assume they've got a lot of fully detailed logs over that period.
makmanalp 2 hours ago [-]
Take a peek at my detailed full-ish timeline of every actor around the embargo and leak, just added amazon's reporting in there as well:
Same as none of their AMIs for bottlerocket have emSign revocations.
Absolutely shit company who puts their customers at risk.
chimeracoder 11 minutes ago [-]
> Why haven’t they fixed Amazon Linux then? Same as none of their AMIs for bottlerocket have emSign revocations.
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
asah 2 hours ago [-]
-1: if the fix breaks customers in other ways, they're screwed as well. Damned if you do, damned if you don't...
Tomdarkness 2 hours ago [-]
It's a upstream targeted fix that was made available significantly faster in packages/images maintained by volunteers, it's not some untested downstream patch. Customers at this point would have likely taken their applications offline over this issue so it would have been difficult to make the situation any worse.
otterley 57 minutes ago [-]
Given the sheer number of PHP applications out there, it's impossible to conclude with certainty that this targeted fix will have no regressive impact without significant testing. How much testing needs to be done is debatable, but I'm pretty sure the answer isn't zero.
AnthonyMouse 30 minutes ago [-]
Someone with a single gigabit internet connection can scan the entire IPv4 address space in less than a day. When you have public RCE vulnerabilities like this, your options are "apply the patch", "take the system offline until you can apply the patch" or "get pwned".
Meanwhile, WAFs are being continuously updated with detection signatures.
AnthonyMouse 16 minutes ago [-]
Mitigations and patches are in the same category, so now you're applying mitigations without testing. What if your new WAF detection signature has false positives etc.?
otterley 12 minutes ago [-]
The difference is that a mitigation is customer-applied, not vendor-supplied. Like it or not, blame shifts when a vendor supplies a fix that's insufficiently tested. The CrowdStrike BSOD incident from 2024 comes to mind.
As for WAF rules, those can usually be flipped on and off with a single switch.
bcvvvy 2 hours ago [-]
Nearly every other vendor has pushed fixes for it, including where they pull their upstream stuff from. There's no excuse.
otterley 1 hours ago [-]
I don't think you're being understanding or empathetic here.
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.
bcvvvy 45 minutes ago [-]
Every vendor is winging it there. Even RHEL. Ubuntu ships shit half the time as well even on LTS.
If you need to test it you should pin packages.
2 hours ago [-]
otterley 1 hours ago [-]
[dead]
4 hours ago [-]
ActionHank 2 hours ago [-]
All these tech companies are school children comparing how much better their bike is than the others, but they've all got the exact same bike, and that bike is a massive vulnerability that they did nothing to fix, but they're all bragging about how they saw it first or identified it first.
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?
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.
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.
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).
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."
https://news.ycombinator.com/item?id=50190603
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.
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.
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?