upvote
YES!!!!

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!

reply
> from attacks powered by every single mainstream agentic AI

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.

reply
> Is it so bad? Have you measured the number of attacks?

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.

reply
Thanks (this is a django site) -

  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.
reply
> Have a look at your log file

Surely it doesn't take a very sophisticated attacker to clean up after themselves at least a little bit?

reply
Depends how your logging works. If you ingest logs to a remote server it's quite hard for an attacker to clean those up. Also I'd guess that most of the PHP exploits tried today weren't sophisticated but rather brute force and then either cryptomining or botnetting or something like this.
reply
I think it doesn't, but I have to say, I have never seen an automated attack on a PHP application that has bothered to hide its traces.

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.

reply
> I have never seen an automated attack on a PHP application that has bothered to hide its traces.

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.

reply
Quantity is a form of quality.

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?

reply
Agreed. It made my ancient old man face tear pores by smiling when I saw people organizing in the comments to throw sandbags against the wall while waiting to be rescued.
reply
It’s scary that people haven’t been able to move uphill though.
reply
I mean, this isn't a things-made-in-PHP-are-bad problem.

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.

reply
HN was my source of truth for mitigating this
reply
It was fun being here today. Validated a lot of the live frustrations and quirks and discovery.
reply
It is bizarre to me that servers are considered something to be “lost” in this day and age. They should as borderline ephemeral as us.
reply
By "lost" I mean, it might have been broken, commandeered, exfiltrated.

This is PHP world; it may be a share nothing architecture, but it's full of long-running VMs and very long-running apps.

reply
I think calling private data "lost" if it is accessed is not a misnomer, even if you have backups.

You lost its privacy

reply
Is it just me, or is it the truly brave that decide to deploy and protect PHP instances? Especially if WordPress or Drupal are involve?

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

reply
I don't really want to be in the WordPress world anymore (I still maintain a couple alas).

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)

reply
Other runtimes certainly have their vulnerabilities. It is just that it seems like PHP values backwards compatibility less than Node, Python, Java, or C#. It seems like there is better tooling for running mixed versions of Node or Python than what I've experiences with PHP.

And with the security fixes only landing on the relatively recent PHP versions, it means vulnerabilities force you into the PHP upgrade churn.

reply
> It seems like there is better tooling for running mixed versions of Node or Python than what I've experiences with PHP.

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.

reply
In nearly every org I've been in or contracted to, the public landing page of the company gets a special place outside of any ops of general technical team, and is instead the work of a marketing group or a "creative" outsourcer who will default to Wordpress on PHP.
reply
This rings extremely true. The good part about it is, unless there's some kind of exceptional factor (e.g. the app.companyname . com cookie using a cookie scoped unwisely to companyname . com), they can go right ahead and do that and while they might get the corpsite homepage pwned and redirected to penis-pill scam sites or something, any truly dangerous actor who gets a foothold there can't do jack shit in terms of actually compromising your valuable data, getting source code, stealing app sessions, etc because that server is not just outside the VPC, it's in a completely different cloud account somewhere far away.
reply
Seems like most main company sites at places I've worked. If you are lucky, that WP instance is a fully managed service where they proactively deal with keeping it on the latest PHP, WordPress, and plug-in versions.
reply
We run on SiteGround, and they had the patch up about an hour or so after it dropped and auto upgraded us.

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

reply
I’ve been to a few places like this and managed to get rid of the Wordpress infestation.
reply
This is how it began and should stay, when IT teams started to get involved in this they ran heavy overhead and aren't clued in on creative requirements. Stick to keeping emails and erp servers up.
reply
Care to share it? Still trying to convince my provider to go this route...
reply
I won't, now, because I will catch shit for suggesting it, it seems.

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.

reply
I'd like to express my dissatisfaction that the "big guys" are basically getting free security over getting earlier disclosure.

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

reply
You should have seen the IRC channels.
reply
[flagged]
reply
Please don't cross into personal attack.

https://news.ycombinator.com/newsguidelines.html

reply
There's no personal attack here.

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

reply
"You're working on a false sense of security and encouraging others to do the same" was needlessly personal.

You can make your substantive points without that, both in San Francisco and elsewhere.

reply
In no sane culture is an engineering assessment made in the second person a personal attack. You'd call "you are holding the screwdriver wrong" a personal attack too.

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

reply
Location isn't the issue. HN users all over the world have no trouble making their substantive points thoughtfully, and SF has its fair share of commenters breaking the rules.

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)

reply
deleted
reply
Well, OK then:

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.

reply
Please don't respond to a bad comment by breaking the site guidelines yourself. That only makes things worse.

https://news.ycombinator.com/newsguidelines.html

reply
Sorry dang but I had a wider point to make there and I'm not really going to apologise this time. The rudeness is only part of what needed to be responded to.

Also I have survived on too much coffee and probably too many chocolate biscuits. So actually, sorry, on reflection :-) What a day.

reply
It happens! Good luck with the rest of it.

I appreciate how your excessive-biscuit status has yet to be determined :)

reply
deleted
reply
[dead]
reply
deleted
reply
You would have been fine without HN, just use AI
reply
I have a Muse Glimmer session helping me keep track of what I am doing, but I don't think any cloud AI would have been as helpful to warn me about something I didn't know and orient me towards possible fixes as other actual people.
reply
Nice try, Diddario...
reply