I am very curious to hear why you thought it was overblown.
There was also that other guy who posted "steal my bitcoin" on a vulnerable PHP server with the private keys to prove it was overblown, and got his bitcoin stolen within a day.
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.
This was not a scary vuln at all.
And would you stake your bitcoin on it?
This is a seperate chained exploit itself, seemingly executed by a nation stae. There are thousands of exploits infiltrating web servers around the world daily, and they arent php2shell.
You only care about this because it falls into a weird viral narrative about "AI saftey".
Chained just means they used php2shell to run a local privilege escalation.
If you want more than that you need to chain an LPE. Which are plenty these days sadly.
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 )
Ha, while most of these are probably humans that are just being driven mad by AI, I wonder how long before we get AI driven botnets that try to under play any security vulns to give them more time to take over and collect assets for themselves?
Which is pretty indistinguishable from people just lying about how bad it is? How are you meant to tell the difference? How can it both be true that the server is vulnerable to any script kiddie with an LLM but your exploit is too valuable to share?
And the fact that the server turned out to be not exploitable just proves that the people claiming to be able to exploit it in fact were lying.
Not having made the claim (took down my website too), but because PHP is not connected directly to the network. While you cannot prevent PHP from being overtaken from inside the PHP program, you can prevent PHP being executed on malicious data by configuring the webserver. It's overblown in the sense that it would be even more serious if the same happened in the webserver itself.
> you can prevent PHP being executed on malicious data by configuring the webserver.
You are spreading misinformation then.
The configuration change was never a full protection from this vulnerability because the problem is with how PHP processed the request well before the configuration or your PHP code was executed.
?
> because the problem is with how PHP processed the request well before the configuration or your PHP code was executed.
That's what I wrote? You can't do anything once PHP executed. It could still be worse, because you can still prevent PHP from running, because there is still the webserver before. If it were in the webserver itself, you couldn't do anything, short of stopping the server from running.
> The configuration change was never a full protection from this vulnerability
It is, if the configuration change prevents PHP from running. That's how you could say it is overblown. You are not vulnerable if you don't run PHP.
It's not overblown if the only non-patch fix is "turn off PHP".
And that's assuming you actually meant "turn off PHP" the entire time? Your earlier phrasing suggests you have something that leaves PHP running in mind, but if that's entirely hypothetical then again we're back to misinformation. (And when you argue it's Turing complete, that only means that a patch must be possible. It doesn't mean there's a config fix.)
Edit: stray "not"
> And when you argue it's Turing complete, that only means that a patch must be possible. It doesn't mean there's a config fix
The config could be, run a simulation on the input data to decide whether it would allow for RCE and then decide whether to run PHP or not. I sure hope nobody is actually doing that, but it is sure possible.
> And that's assuming you actually meant "turn off PHP" the entire time?
I did mean "only execute PHP, when you know the input doesn't trigger it", the policy of never invoking PHP at all, does satisfy that.
That is not a config. That's a whole new program.
> My first statement was "Not having made the claim", to indicate that I do not necessarily think that. My second was "took down my website too" to indicate, based on what understanding I did and plan to act on.
But with everything else you still made it sound like you were supporting it.
> I did mean "only execute PHP, when you know the input doesn't trigger it", the policy of never invoking PHP at all, does satisfy that.
It satisfies it, but in a way that doesn't make the exploit overblown.
It's obvious that you can avoid a PHP exploit by turning off PHP. That's not nearly enough to make the worries overblown.
"It could be even worse" is the only conclusion we can draw from it being in php and not the web server. And that conclusion is basically meaningless.
That's the distinction between being able to do something or not if you do not have control over the webserver, as is likely the case for a lot or PHP websites, so I wouldn't say it's meaningless.
The server configuration to mitigate this is to comment out the whole configuration so there's no server.
The whole thing was basically a psyop, whether intential or not idk but Califs research was funded in part by OpenAI so there's that.
It was OpenAI's marketing that hyped up the vulnerability to the point that guys on my hockey team saw it in the news and were asking about it. There doesn't need to be mainstream articles about it, these kinds of vulnerabilities happen every year. Just patch and move on.
Random bloggers jumped on it and said dumb blogger things. That is all.
This is one of the worst vulns ever and the security response from the people who actually secure things for a living was entirely warranted regardless of whether some blogger thought it was the AI apocalypse or not.
19 hours: https://stealmybitcoin.com/
Part of the confusion is that the initial PR for the release made it sound like there was a ready-to-go exploit that was just push button, get shell on any PHP server in the world. That turned out not to be the case, as evidenced by the fact that the number was 19 hours and not 19 minutes.
But the fact that it was 19 hours and not "never" also does provide a data point that everything that was vulnerable really was vulnerable, it just may not have been quite as vulnerable as it was initially presented. Still plenty vulnerable, of course.
My point here being that the initial 24 hours were very confusing and I think it's worth remembering that and giving people grace for it. Even now, I've heard rumors of an exploit that does work on all boxes without making changes for a specific target but I'm not actually sure whether that exists or not. (Any further info welcome.)
Doesn't mean that there isn't another exploit chain that can be used though. Challenge also had 4 workers total, so pining one worker wasn't that hard.
I don't see what was confusing about the initial 24 hours. GP was correct, the description of the bug made it clear it was a very high risk.
We need more of this.
Mainly saw the severity in the economic impact of having to quickly patch so much, but taking offline being the right choice given the risk, along with of course all the decades old, never patches, blogs being botnet targets someday in the future, akin to Wordpress being commonly used for Ransomware hosting for similar reasons. And of course hopefully learning something from the timeline and leak for future disclosures. Feel things need to generally change from the status quo, barely has changed since the 2015 Google/MSFT squabble...
> When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
I find statements like yours to not be about objective truth, but rather a narcissistic view of world where if it was hard for you, it must not be possible. It is more of a comparison of yourself vs the world.
See also https://news.ycombinator.com/item?id=50224916 https://news.ycombinator.com/item?id=50225703
Maybe compare with https://github.com/php/php-src/blob/master/php.ini-developme..., too.
Then similar for your web server (Apache, nginx, whatever).
EDIT: About your "would've seemed adequate before this" - I dug up a copy of a PHP v5.2 php.ini file (2-ish decades ago). That file begins thus:
;;;;;;;;;;;
; WARNING ;
;;;;;;;;;;;
; This is the default settings file for new PHP installations.
; By default, PHP installs itself with a configuration suitable for
; development purposes, and *NOT* for production purposes.
; For several security-oriented considerations that should be taken
; before going online with your site, please consult php.ini-recommended
; and http://php.net/manual/en/security.php.I'm actually somewhat surprised at the clumsiness here.
I'm a complete amateur that had DeepSeek build a PHP2Shell exploit, and once the stealmybitcoin site went up and set an upload limit, i had DeepSeek try to shrink/amplify it.
DeepSeek couldn't find anything but a 2x reduction, but reading the report of how it was done - https://github.com/KillaBoi/StealMyBitcoin-PoC - I was somewhat surprised it didn't find it, and equally horrified at PHP allowing such a memory bomb of creating nested objects by parsing `f[0][x][x]...` from random requests.
Point being; these aren't amateurs but i kind of expect most well funded pros to have found this method to avoid sending massive filenames and session progress data.
Sorry, I still resent the moronic 2024 “Prompt Engineering” guides that were obviously bullshit and non-falsifiable random claims.
cost me $10 in the end to run it fo about 10 hours straight, since I hit it in daytime hours
And the vendor's firewall software runs an unpatched version.
Just for context, that is the type of evil we're talking about here.
A German comedian made an episode about it [1]
All my NYC relatives seem to have choice (unfavorable) words to say about every single one of their politicians, and have ever since Koch's 3rd term.
It's hard to serve 11M people, so most people who get into that position do so by promising to serve 11M people and then serving themselves.
Note that electing clowns to public office is not unique to NYC - we've had a reality TV star and an actor as POTUS (the latter also serving as governor of California), Toronto has elected a criminal as mayor, Minnesota got a pro-wrestler as governor, South Korea had multiple presidents resign in disgrace, and South America seems to have politicians ping-pong between prison and presidency.
I think the biggest change is we don't really hold them accountable anymore, at least in western democracies. Maybe we never really did.
Anyway from their webpage: > We work directly with heads of state, ministries, national cyber authorities, and the senior officials responsible for executing national strategy.
So I presume he has and provides contacts. Just the usual one hand washes the other. Nothing nefarious I'm sure.
Believe it or not in cybersecurity there are many considerations in how “bad” a vulnerability is.
Ease of exploitation, feasibility do play a part which I’m sure surprises you.
https://news.ycombinator.com/item?id=50189820
You actually participated in it and called cyber security researchers addicted to likes. Ironic.
also, psuedo cybersecurity researchers are definitely addicted to likes.
edited: looks like half of that post even agrees with them so i mean...?
- Rust didn't exist at the time
- Go didn't exist at the time
- nodejs didn't exist at the time
- Java and Python likely used too much resources for a once-in-a-while used GUI
Irrational hatred aside, that's literally what PHP was designed for.
Perl?
Perl 4 specifically of course though.
Not in 2005. Perl 5 all the way, baby!
Perl 5 was released in 1994. Palo Alto Networks was founded in 2005, so Perl 5 was certainly available when they built their first products and would have been a superior choice to either PHP or Perl 4.
Sure, you can do web apps in Perl with Catalyst or other frameworks, but the PHP developers are easier to find.
And then, after you develop entire GUIs in a language, it is a herculean effort to port that to another.
And lastly, JavaScript has its own issues too.
It is a huge effort even migrating from one PHP framework to another.
Coming back to your point, there is no single “page” to be migrated one at a time.
Is there a reason one URL at a time wouldn't work?
You can always take a look at the UI of a PAN device and use your browser in developer mode to see how it works and understand the concept of a web application.
I do not have a PAN device.
> it is not "one URL"
I never implied it was.
> it is an entire application, it does not have distinct "pages"
> the concept of a web application
Those are usually written in javascript and the client part could stay the same. If anything that kind of design makes it easier to replace the backend one URL at a time becasue the responses from the backend are simpler.
If they have something where the UI state is kept on the server and is relayed to the browser, that would be difficult to do anything with. But that's an especially terrible design that causes other problems, so if you're accusing them of having a design that bad please be explicit.
Perl 5 was the language of choice for CGI in that era, but PHP borrowed some of perl syntax and quickly displaced Perl in web usage.
Some perl programmers migrated to Embperl, but it didn't gain much momentum.
Yes, in 2005 you choose PHP, but in 20 years of operation, you don't revisit reconsider your architectural considerations? A fantastic avenue for hardening any product would be to replace a ~2MSLOC component (the PHP interpreter) with a 10K SLOC daemon that does only what you need.
When you're a startup, expediency and funding prevent this, but by the time you're selling "solutions" and baking designs into ASICs you could have prevented this attack by putting a fraction of the effort into software.
And that is even with the assumption that other languages don't have issues - they do.
PHP being big and creaky was very well known. This has nothing to do with hindsight.
And it still is big and creaky. You can cite this comment the next time something like this happens to prove it's not hindsight bias.
> And that is even with the assumption that other languages don't have issues
Incorrect. Please do not strawman.
Now, do I think that it may be more likely in 2027 than it was in 2007 or 2017? Absolutely. Depends on how well-documented and specified your existing system is. A rust rewrite or whatever is highly possible now for many codebases, probably.
> When you're a startup, expediency and funding prevent this, but by the time you're selling "solutions" and baking designs into ASICs you
.... are still run by the same startup people who think "working like a startup" was a good idea in the first place.
Right now I work with a bunch of people who came up working for startups. They are responsible for the products that make the company the most money. They are still on PHP 7.4.
I just do not understand. CC is not the sole harness in the world, why the attackers insist to use it.
FPGA stocks? DV is about to become hot again..
Wat
Linux seems to have a huge attack surface that doesn't necessarily need to be there for every user/server.
E.g. this came out today: CVE-2026-98432: Linux TCP Use-After-Free Risk and Patch Validation [1].
I just disabled mptcp on my systems since I don't use it. Why was it enabled by default?
Can I disable this XFRM thing too?
Torvalds needs to borrow Rust code from Asterinas (and maybe Redox) ASAP.
IIRC it was CVE-2026-31431 earlier this year that made me go audit what modules were loaded and go on a whole hardening kick. As far as I understood, the vulnerable module (algif_aead) wasn't even commonly used by anything.
So why is it loaded by default? It's just an extra code path to potentially exploit my system with. It's even marked deprecated (and insecure!), yet a fresh NixOS (and Arch, I believe) install has it loaded out of the box.
I mean, I get it, broad compatibility and all that jazz... but still.
On other distros they throw in the kitchen sink because it is easier than making an endless amount of them customized to every system.
If you are still running an old PHP version you are grossly incompetent and should take your server offline.
(I wasn't around for this, I just found it)
Edit: “Or the internet in general” - and yes internet was never safe but this is just next level. You seem to do everything right and it doesn’t matter. Is o365 really safe for example? I’m rapidly seeing my faith in SaaS platforms degrade - they can’t be immune to all Of this