Chained PHP2Shell exploit roots 25 servers, including US Government servers
dreamgroup.com298 points by 882542F3884314B 17 hours ago
298 points by 882542F3884314B 17 hours ago
> the attacker chained in a second exploit: a Linux kernel vulnerability in the XFRM ESP-in-TCP subsystem
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?
I'm on Gentoo and when I compile my kernel, by default, almost nothing is enabled.
On other distros they throw in the kitchen sink because it is easier than making an endless amount of them customized to every system.
On Android many things available on Desktop Linux are disabled by selinux. For example, af_alg algorithm (encryption kernel module writes out of bounds) is not accessible by user using ADB.
The bug doesn't mention MPTCP, is MPTCP required for the bug to be exploitable?
No, but MPTCP makes it more likely to be exploited, supposedly.
SMB in the kernel and binding io_uring to DMABUF doesn't look pretty safe either.
Torvalds needs to borrow Rust code from Asterinas (and maybe Redox) ASAP.
> Linux seems to have a huge attack surface that doesn't necessarily need to be there for every user/server.
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.
Everything is enabled by default in Linux, it's just their way. Privilege escalation exploits for Linux are found every year. If you can RCE a Linux box, assume you can also get root.
> A1 — Memory Exhaustion (~383MB):
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.
this featured is disabled in any security conscious deployed (which doesn't seem to be the case for some large firewall vendor)
Reading this I'm almost certain the firewall vendor is Palo Alto Networks. They included a PAN-OS setting verbatim and the SELinux config matches my experience.
> Since this discovery, the Dream research team has been sharing updates and collaborating on an investigation with Palo Alto Networks, the vendor of the firewall in question. More information is available on the Palo Alto Networks website. Additional details are now included in the post itself.
Further indication is that PHP 7.4.33 and PHP 8.30.0 are mentioned which are an exact match for PAN-OS 11.1/11.2 and 12.1/12.2 respectively
Why does a world-class firewall stack need PHP? I'm sure PAN-OS has some neat DPI features, but I would love to see firewalls that are implemented in FPGA, where the tasking was compiled down to gates to be performed deterministically, much like the low port count network switches we have today.
What else would you use to power the configuration gui frontend? Allow me to eliminate some of the obvious and inevitable answers:
- 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.
> Irrational hatred aside, that's literally what PHP was designed for.
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.
This is great to say with the benefit of hindsight but nobody is changing the underlying language of their well established product for literally no reason.
And that is even with the assumption that other languages don't have issues - they do.
> literally no reason
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.
At which point during that 20 years do you decide to rewrite a ton of your production code just to change languages?
When you are making a lot of money and have a security analysis of your stack.
I wonder if that's why Palo and PanOS have had so many vulnerabilities this year and last
I get that logically you would think that a very wealthy company would improve their technology once they had the resources to do that. But companies do not run by logic. They run by humans, making human decisions, motivated by almost every conceivable thing except logic.
> 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.
Lua? Tcl? both AFAIK have less vulnerabilities than PHP likely thanks to smaller code size.
> What else would you use to power the configuration gui frontend?
Perl?
For some reason I’m not allowed to respond to the child comment so I’m putting this here:
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.
When discussing programming languages, you need to take into consideration how easy it is to find developers with experience on a certain language.
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.
We were talking about early 2000s.
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.
We're talking about an html GUI right? That's not herculean to port between languages.
The difficult part isn't rendering the UI, it's the work that's done between the UI and the back end components/services that's difficult. PHP is used for more than just web pages.