Hacker News Reader

Comment by redox99 | Hacker News Reader

The exploit is already out. Yeah this looks like it's going to go on history as the worst vulnerability ever. And now with LLMs you'll likely see tens of thousands of agents hacking any php website out there within hours.

View on HN

Yup, I'm seeing several legit people on X claiming to have seen or found the exploit. Some say that: turning session.upload_progress.enabled off and setting file_uploads = Off will mitigate. But others are claiming that those steps are not enough and "Upload progress can serialize before basic RINT clears BG(serialize)". So, I'm taking no chances and taking my services offline.

https://x.com/MagicalTux/status/2112725774025572431 https://x.com/rina4_tot/status/2112723421641531772

I think this exploit + agentic AI (which allows for rapid secret exfiltration/utilization) may be a potent enough combo to trigger a sort of Kessler Syndrome for network security.

Mark Karpelès? Wow that's a name I haven't thought about since 2014.

To be honest that clueless individual and its pathetically lame security practices made him lose 800 000 Bitcoin belonging to its customers with Mt Gox, which was written in... PHP.

And he went to prison for a few years for it. So he knows something about PHP exploits.

But at least he has $66B in BTC. /s

If the problem is in the parser then `file_uploads = Off` doesn't help, PHP still parses the multipart body. That seems to be why they're talking about blocking multipart/form-data on routes that don't take uploads and rate-limiting those that do.

> sort of Kessler Syndrome for network security.

why it would be a thing, beyond "serious problem"?

> Yeah this looks like it's going to go on history as the worst vulnerability ever.

lol no.

I feel old. Heartbleed was 2014.

I don't think a PoC was publicly available for Heartbleed before patches? I may be misremembering.

Log4Shell was worse than Heartbleed and it doesn't seem totally outrageous to say that this might be worse than Log4Shell.

Log4Shell was on a library called Log4J, used by many (but also not that many: Logback is equally as used and wasn't affected by the same vuln). This is straight up php the language.

Log4J was nearly ubiquitous; not quite the full reach of Java, but deployed to a significant proportion of public-facing Java platforms and services.

It depends? I recall being on incident response and checking for that specifically (I worked in a big java shop at the time and was responsible for stuff like this). It was alot of screaming online, but things like Spring Framework used to pull Log4J v1 (ie: not affected) and spring-boot (the modern, way more used one) used Logback (also not affected). You'd get it from like a Kafka/Elastic dependency or similar, but only if you didn't have an SLF4J handler.. like spring would ship Logback for example. Which makes me thing, in general other java shops were mostly not affected as well, given spring is basically the go-to on the java world.

Extremely legacy software wasn't affected either (log4j v1 or apache commons-logging!). Lots of automated scanners flagging the idle jar as well (when the app used Logback for example as the SLF4J implementer, but the scanner saw a transitive for the log4j jar and would scream at you - that's when I stopped caring about github vuln scans btw, it was a shitshow).

Like dont get me wrong, it was a bad vuln, but to me it seems like it was more hype machine and internet screaming than actual vulnerable applications. I do recall Minecraft was vulnerable though, that one was indeed a big target given publicly exposed servers and such.

As a percentage of websites, though, Java is far from ubiquitous. It's probably not even double digit percentages. PHP, meanwhile, is some 70% of websites. So in terms of exploit targets, this is 10x that of Log4J, maybe.

The vulnerability also required you to log arbitrary user provided strings and maybe some other precondition that I can't remember. Nothing at my workplace at the time was affected despite using log4j since user provided data was either parsed (e.g. a uuid) or private/not something we would log.

Log4Shell was comparatively easy to patch, you could literally do it with a simple shell script+rebooting the application server.

I think the exploit itself of Heartbleed was worse, but the impact size of this will be greater.

Measuring “worst” is hard.

> Yeah this looks like it's going to go on history as the worst vulnerability ever.

Thanks, PHP.

> Yeah this looks like it's going to go on history as the worst vulnerability ever

Yeah no.

This is bad but doesn't even crack the top ten.

Which ones would you say are worse, and why?

I'm not them, but I'd say Conficker and those other windows file share worms were worse. They went after peoples personal computers rather than web servers so affected people less aware of how to deal with it. It's a little early to tell what this php one will all affect though.

The Microsoft SMB remote-root holes had much wider impact... you had things like railway station monitors going offline.

At the end of the day, nobody gives a shit if another WordPress blog gets hacked.

Reply on news.ycombinator.com