PHP team has always been like this. Instead of creating better software they have always tried to add features with no consideration of backward compatibility.

No serious project should use PHP.

I don’t know why everyone is so hung up on this patch being the only way to fix the situation. The way that Internet services are attacked is by crafting malicious payloads. Having a proxy in front of your application server is a very smart idea, especially if it can do one job: decode input, and re-encode it in a safe way. In a couple hours, I put together a proxy using Claude, which completely eliminates this php2shell attack and many other others, that might possibly be discovered in the near future. Among other things it just decodes and re-encodes multipart-form-data payloads with its own random sane delimiters rather than attacker-chosen ones.

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):

https://github.com/Qbix/proxy

MediaWiki is the last thing that prevents me never dealing (directly) with it again. And it's hard to imagine a drop-in, migrateable replacement for larger wikis. T_T

Who remembers how careless, reckless, and blithe Rasmus Lerdorf was with the PHP 5.3.7 release he didn't bother to test, because running tests was too much of a hassle, because there were already so many test failures that wading through them all to see if there were any new ones was just too much to ask of him, the leader of the widely used project, in charge of cutting releases?

>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()!

http://i.imgur.com/cAvSr.jpg

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.

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.

Yeah — I have log entries I believe show LLM-bot-driven exploit attempts — POSTs to a variety of non-application URLs, blocked on the front end proxy by rules I added that prevent multipart form POSTs -- from an hour before the patch was released.

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.

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.

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.

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.

I've been having trouble exploiting it from first principles even in lab conditions.

Well, according to OpenAI:s blog post, they led everything, other than the fix and release. I guess leader takes the responsibility?

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.

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.

Crowdsec spotted more than 300 IPs listed in 24h and the first one were spotted prior the patch release. source : https://www.reddit.com/r/CrowdSec/comments/1xci24u/php2shell...

> 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

-1: if the fix breaks customers in other ways, they're screwed as well. Damned if you do, damned if you don't...