Comment by jstanley
6 hours ago
> I'm not sure how "RCE on every PHP server, from anywhere on the internet, no other requirements" could possibly be underblown by anyone
It could be overblown if it's not true. The amount of time it took for anyone to claim the Bitcoin from the supposedly-vulnerable PHP site convinced a lot of people that the vulnerability was not as bad as claimed.
Why would someone send their exploit chain to a random for a mediocre 'bug bounty'. The bounty was later claimed by people who just did It for fun after work for fun with a LLM of their choice quickly.
wasn't it setup in an unexploitable configuration (not actually serving a php page IIRC?) for most of the time, and then got popped within like 2 hours once fixed?
The point is, under normal configurations when you're serving the PHP server correctly with table-stakes best practices the server is not exploitable
This was not a scary vuln at all.
Under normal configurations the server is highly exploitable.
It's a horrible vuln and I don't understand what's with all the flat infosec society coming out of the woodwork.
The challenge server had vibe coded infra that made it hard or impossible to hack, but it was a configuration that can't be used in production and no one uses ( it was deployed as a PHP static content server instead of a dynamic site generator )
1 reply →
Normal configuration of a PHP server is to not run any PHP code and serve a static html file?
4 replies →
Which best practices did you use to prevent exploitability?
And would you stake your bitcoin on it?
I had a similar take, but I was wrong.
1 reply →