I absolutely loved being here today.
So many brilliant minds screaming and hating together, trying to survive the tide.
There aren’t many places like this left on the commercial internet, especially in this brave new AI-driven world.
I felt a great disturbance in the Force. But in a good way.
Together, we are strong. May the Force be with us all!
Is it so bad? Have you measured the number of attacks?
> So without the HN discussion I wouldn't have found enough people pointing at possible mitigations and I would have lost a server to this
I run a tiny server. I like this server a lot. I only patched an hour after the Debian package was ready and didn't think about it again. Do you mean to imply there's a real chance my little server has been compromised?
[Edit:] My server is quite public too. It hosts four SLDs and many subdomains and receives both human and bot traffic. Only one or two subdomains use PHP, but a reasonable attacker surely tries all of them.
It is not a torrent, no. Dozens up to hundreds, rather than hundreds to thousands.
But they would very likely have succeeded, right? It's a fairly turnkey vulnerability.
> I run a tiny server. I like this server a lot. I only patched an hour after the Debian package was ready and didn't think about it again. Do you mean to imply there's a real chance my little server has been compromised?
Can't say one way or another. Have a look at your log file for POST requests in quick succession for things like
/_next
/_next/server
/app
/actions
/api
/dashboard
> [Edit:] My server is quite public too. It hosts four SLDs and many subdomains and receives both human and bot traffic. Only one or two subdomains use PHP, but a reasonable attacker surely tries all of them.All my "obviously PHP app" domains got visited. None of my bespoke app domains (which are not obviously PHP). Though over time, the bespoke domains do get a whole bunch of boring probes for WP vulnerabilities etc., like all websites get.
35.247.197.7 - - [21/Oct/2026:16:41:11 +0000] "POST /_next/server HTTP/2.0" 404 153 "-" "Mozilla/5.0 (compatible; YouBot/1.0; +https://you.com/bot)" "-" [REDACTED] 0.002 "0.001"
From a Google Cloud IP it seems.Surely it doesn't take a very sophisticated attacker to clean up after themselves at least a little bit?
If your attacker is someone known to you, some kind of persistent threat, then maybe they would? But most of this stuff is typically kind of worm-like; attack one box, use it to attack another, move on.
With this particular server I am in two minds about whether it is likely I have any persistent type hackers, but I must say what it looks like is automated attacks. AI script kiddies, almost. These same boxes attract all the typical PHP app probes (WP2shell etc.)
And FWIW what it actually mostly looked like was hits from some sort of cloud-based AI search API; they suddenly stopped at the same time as if someone else had pulled a plug. So maybe someone running an agentic search API decided not to be part of the probes.
I'd agree with that sentiment, most of those scripts are the laziest they can be.
But I can't help but wonder if there's survivor bias going on there.
There's a vast number of operators who won't even look at their site when its performance craters due to a scrum of crypto miners all competing for resources. Why waste time on sophisticated attacks trying to fly under the radar of competent admins who will detect you by your egress traffic anyway?
It's a bit more a "certain C programming techniques are bad" problem.
This is more like log4j, heartbleed etc.
Won't be the last of these.
This is PHP world; it may be a share nothing architecture, but it's full of long-running VMs and very long-running apps.
You lost its privacy
I finished moving the remainder of my stuff off of PHP and WordPress last year and haven't missed it at all. Backwards compatibility was typically pretty bad.
It seemed like maintaining existing working PHP code was always a cycle of: upgrade to newer PHP, that version has breaking changes, fix that code or update to a new WordPress (plus all of the plugins that would inevitably need updating too).
But this isn't about PHP code, really — this is about C code (with less-than-ideal exception handler patterns). This problem is more Heartbleed than WP vulnerability.
I quite like modern PHP, I don't really think it's necessarily any less secure (exception handler weirdness notwithstanding), and more to the point, I don't think not using it is any kind of automatic improvement in web app security. It's not like server-side JavaScript is intrinsically better.
I am certainly doing some thinking today; I switched off a couple of web servers so I didn't have to think about them while I was working on other stuff, and actually I think they might not get switched back on. But it's not so much that they are running PHP as that they were kind of neglected and it's always worth reconsidering what you need to keep around.
I think I have reached a point where low value stuff is not worth subsidising just for fun.
(I have also reached the point where in future I won't be using distro packages for PHP)
And with the security fixes only landing on the relatively recent PHP versions, it means vulnerabilities force you into the PHP upgrade churn.
Yeah — the solution on a single machine is either containers or very careful use of different FPM environments, which has tripped me up more than once.
I think most of my inconsequential stuff is simply going to get moved to commercial hosting; my biggest problem right now is an entrenched application that has custom compilation of a PHP build before 8.1.
My shit on Wolfi, managed by ChainGuard, a “security company”, didn’t have a patch live hours later.
The funny thing is, people running Wordpress have dealt with 0 day bullshit so often that it’s basically a Tuesday for them, not even a big deal. So hilariously Wordpress folks have plenty of options here simply because it’s been a nasty attack vector for so long and these people are so used to dealing with horrific vulns like this that patching it is actually pretty trivial
But since one of the main ways this vulnerability can be triggered (by causing out of memory) involves multipart POSTs, I have found it useful to stop multipart POSTs ever reaching the vulnerable application, which you can do in an Nginx proxy.
It is only buying me time, but unfortunately time is what I need, since my application must keep running, but cannot be run on any supported release.
Just saying "hey blocking multipart uploads can mitigate most of attacks early would save people so much trouble. Of course not every CVE will have workaround but many do and whole secrecy about releasing it is only to benefit of few big tech companies and nobody else
Unless your position that any statement whatsoever made in the second person that isn't a compliment is then an attack?
San Francisco is a magical place where "you are doing X wrong" without slathering on six paragraphs of fake kindness constitutes some kind of personal attack
You can make your substantive points without that, both in San Francisco and elsewhere.
He is, in fact, not mitigating the attack, and he is, in fact, by calling his non-workaround a mitigation, encouraging people to do ineffective things instead of patching. These facts remain true in the real world regardless of what you call a personal attack.
And yes, San Francisco has become top of the world for indirect fake kindness that transforms plain factual statements about the world into social offenses.
"The sun is bright. Don't look at it " -- RUDE!
"You might want to consider that the sun might be considered bright to some people and that you might be more comfortable looking at this other cool thing instead. But no pressure" -- gruff, barely tolerable
You have a long history of throwing sharp elbows around on this site. You did it just yesterday on an unrelated topic: https://news.ycombinator.com/item?id=50167498.
We've asked you many times to stop. If you would please review the rules at and fix this, we'd appreciate it.
https://news.ycombinator.com/item?id=45089286 (Sept 2025)
https://news.ycombinator.com/item?id=44729387 (July 2025)
https://news.ycombinator.com/item?id=24254142 (Aug 2020)
https://news.ycombinator.com/item?id=22029640 (Jan 2020)
https://news.ycombinator.com/item?id=21104133 (Sept 2019)
https://news.ycombinator.com/item?id=17976632 (Sept 2018)
https://news.ycombinator.com/item?id=17976625 (Sept 2018)
https://news.ycombinator.com/item?id=17791892 (Aug 2018)
https://news.ycombinator.com/item?id=17492560 (July 2018)
1) you're being rude, just stop it and get a grip
2) actually, this particular mitigation is very clearly stopping all the unusual patterns of POST request attempts I can see (it's not usually a busy server)
3) I know it is not the only mitigation that is necessary
4) … so it isn't the only mitigation I have applied
5) I am not working under a false sense of security, and I know it is temporary
6) I am not an idiot, and I am working on patching this machine, but this particular server has a unique and complicated configuration and needs a bespoke build
7) I have been prioritising much more serious risks for other people, all day, for no pay
8) again, to reiterate, you're rude.
Also I have survived on too much coffee and probably too many chocolate biscuits. So actually, sorry, on reflection :-) What a day.
I appreciate how your excessive-biscuit status has yet to be determined :)