HN

Need help?
<- Back
There isn't an easy exploit for this PHP vulnerability

There isn't an easy exploit for this PHP vulnerability

zkldi

Comments (138)

  • nemothekid
    For me, what was strange is there were no write-ups on how the vulnerability actually worked. It really does feel like a lot of people went "Claude found a bug, and Claude says it's dangerous" but no one actually verified how exploitable it actually is? Not to say its worth ignoring, but compared to Heartbleed (where exploits had to be written by hand) there are a lot fewer active PoCs.
  • hn773746483
    Social media and "cybersecurity experts" had a big role in this. Stuff like "EU SAYS THIS IS A URGENT VULNERABILITY" and even the Prime Minister of Japan doing a nighttime PSA. They cite "the experts" posts on social media about the initial advisory, while the very same so-called experts share google search AI output mitigation strategies. None of these organizations or bodies had any details other than what was on the advisories and social media. (e.g "CVSS 10, that's bad!!")To me, it seems more more akin to broadpwn, technically severe, wide scope (millions of iphones), yet will never be a one-size-fits-all-PWN-button.Even in the age of AI, I don't think this is going to be weaponized down the line like how Eternalblue was... but I'm not the social media cybersec guy with 15000 followers, so don't take my words at face value ;)
  • kgeist
    I ran 2 PoCs from GitHub today: one indeed expected Local File Inclusion (LFI) to already be present (so it's just LFI with extra steps), and the other one didn't work at all out of the box without some modifications (although I used the same Docker images and all). The second PoC did trigger a real stale write bug in the end, but it didn't demonstrate actual RCE; it just triggered a stale write. And then I wondered, is this the first time ever that the PHP runtime has had a memory corruption bug? I doubt it (I remember a few years ago we had random crashes in production under high load due to an opcache bug). And if it's not the first memory corruption bug in the PHP runtime, why is it being proclaimed the worst vulnerability in years?
  • nickysielicki
    Docker images from Wordpress, joomla, and drupal were all exploitable.https://www.wiz.io/blog/php2shell-php-rce
  • rectang
    According to "Today's PHP Security Release, and How We're Strengthening PHP Security" discussed at https://news.ycombinator.com/item?id=50182987* Regarding one CVE, "Remote code execution was also confirmed on PHP-FPM through application-level code paths."* Regarding the other CVE, "A use-after-free and worker crash were confirmed, and the reporter demonstrated remote code execution against a real-world application running on Apache with mod_php."Since those exploits exist, I expect that LLMs will duplicate them soon.
  • SoftTalker
    > We all deep down know that PHP is insecureDo we? This was certainly true years ago. But I haven't really thought that modern PHP was any worse than any other scripting language.
  • 0x1F8B
    If they're so confident this isn't exploitable this person should stand up a very basic nginx running php-fpm server running in an exploitable version of PHP and invite people to exploit it.
  • amstan
    On the other hand, my local qwen model (3.8-flash-next) was trying to convince me that the eMudhra CA thing is no big deal since you need to be "positioned correctly" (eg: any wifi network) to be able to MITM, and most of the IOT devices would have patched stuff by now.
  • layer8
    > So why was everyone so scared?> Because:[…]> 3. The exploit video had an anime girl in itLol, somehow I had missed this. Since I had to dig a bit for it, here it is for everyone’s enjoyment: https://www.youtube.com/watch?v=pfWZrdzvooc (via https://calif.io/php2shell/#php-5-4-0-rce)
  • dguido
    Hi, I am the CEO of Trail of Bits (https://www.trailofbits.com). We've had two of our staff independently write working exploits for this flaw. The first one took about 4 hours, start to finish. The second was a similar amount of time spread over the course of a day. We've tested our exploits to work on an unmodified MediaWiki.tl;dr writing exploits still requires expertise, even when you're being aided by an LLM
  • stickfigure
    > It isn't a Log4J moment.The difference is that PHP has a long history of vulnerabilities while platforms like Java don't. And as bad as Log4Shell was, it wasn't a problem with the core runtime. It wasn't even a problem with the most popular logging framework at the time.I wouldn't downplay this.
  • pinevale
    I've seen many posts like this. None of them stood the test of time. Ease is irrelevant because you only need expertise once and then everyone can reuse the result.It's also not easy to pop an iPhone, but reliable, weaponized exploits are available in trade and governments use them in a plug-and-play way.
  • furyofantares
    The only other post on this blog is "Anything connected to the internet is going to get hacked to pieces." I'm not claiming any contradiction but it is funny.
  • easterncalculus
    Related LiveOverflow video about fake exploits going around https://www.youtube.com/watch?v=7CiZmq2llDgThat said, OP is basically full of shit. This is absolutely exploitable and people are going to just assume the platform and ABI and spray it against the internet, particularly hoping for mod_php.
  • Retr0id
    I predict that this take will age poorly.
  • dhruvagoyal
    "Script kiddies (and script adults, who have also switched their brains off)" not something i expected to hear ever but it's so real
  • Insimwytim
    It's also weird that it seem to has overshadowed certificates incident, which, to me, appears to be of at least the same magnitude of impact.
  • pier25
    Maybe the author does have a point. There are millions of PHP websites and do we know of any that was pwned?
  • abootstrapper
    Reminds me of how Y2K was a "nothing burger," because of the effort that was put into making that so.
  • letmevoteplease
    Wiz: "These vulnerabilities include memory disclosure and unauthenticated remote code execution in PHP itself, independent of the application running on top of it"[1]Calif: "the available exploitation paths depend on the PHP version and SAPI but are always exploitable under default configurations" ... "This results in RCE against arbitrary PHP scripts on Apache mod_php and PHP >= 5.4.0."[2]PHP Foundation: "full remote code execution was demonstrated with default settings."[3]Unless all of these organizations are lying, the exploit can work against a default PHP installation running a Hello World script.[1] https://www.wiz.io/blog/php2shell-php-rce[2] https://calif.io/php2shell/[3] https://thephp.foundation/blog/2026/10/21/todays-php-securit...
  • anon
    undefined
  • reflexe
    Sorry but this post makes zero sense.Many apps (eg chrome) frequently fix bugs that are actively exploited in the wild yet have no public weaponized chain (sometimes for months).The fact that there is no fully public weaponized chain does not mean it does not exist or that this bug is not as scary. It only means that it is not as trivial to exploit as log4shell/shellshock/etc.According to cloudflare [1], it is being exploited in the wild.[1] https://x.com/eastdakota/status/2113079352682570051
  • yamanahlawat
    >> There's something important to be said here about how many people have Claude/GPT make design decisions for them, and how AI is the primary decision maker in the world right now.I suppose majority of the them now...
  • anon
    undefined
  • squidlib
  • commandersaki
    My take:I have had this take but for things like exploiting with a DRAM interposer ala Battering RAM. They say it's a low cost attack, but the amount of obstacles you need to overcome (including having root on the system and physical access) is intractable to virtually everyone, and a nation state wouldn't go to that kind of gymnastics when it is more than likely there is a quicker and easier way in.But this? I doubt any high value targets will be exploited in the wild since news travelled fast and from what I can see pretty much most took preventative action. Looks like pretty much everyone heeded the warning and suggestions. It'll mostly be a nothing burger like Heartbleed. There'll be of course low hanging fruit of unpatched servers out there, but anything of importance would have already had active maintenance and patching.Now that Calif has released the details, I'm sure there'll be a contingent that can actively and easily exploit this, either now or very soon, with or without the guidance of LLMs.But yeah if someone said Battering RAM, I would say fuggedabout it, but if someone said PHP vulnerability with a CVE of 9.2, I would say patch it ASAP or bring the servers down until you can.
  • anon
    undefined
  • abofh
    When they confuse the CA issue and the PHP issue in the opening paragraph, I have a hard time trusting their analysis
  • richardbarosky
    What kind of pisses me off was that there were kind of two sides of the continuum.You've got the detailed technical writeup on one end in the patches themselves, and on the other end you've essentially got the AI and security companies both together (php2shell) and independently with their highly polished microsites and blog posts with attractive infographics and stylized pitch deck looking images.Every publication on the other side of the detailed technical writeup in the patches themselves wanted to make it into a huge fucking marketing stunt first and foremost, providing absolutely zero added practical benefit or value.https://www.php2shell.com/https://patchtheplanet.org/https://www.wiz.io/blog/php2shell-php-rcehttps://calif.io/php2shell/
  • jadar
    I am so annoyed… I am trying to verify the claims of this article with my friend Claude but daddy Dario won’t let me because “cyber”. I pointed it at this article and a PoC [1] I found on DuckDuckGo. We live in a stupid world. I can’t run it right now so I am trying to figure out if it’s serious.[1] https://github.com/eness/php2shell-CVE-2026-109618-CVE-2026-...
  • anon
    undefined
  • Tadpole9181
    > So why was everyone so scared?I think this section misses the mark.The biggest problem is that for a good 12 hours nobody knew what was going on. All we knew was there is a critical vulnerability affecting all of us that allows RCE somehow and we have to have vulnerable servers open for potentially even longer.Everyone who knew was being hush hush, only chiming in to say "nah, those workarounds don't work, you're fucked".So when people started spreading rumors of PoC or when the Cloud flare CTO posted that they were actively seeing exploit traffic - what are we supposed to do?We aren't sitting there trying to PoC with Claude - we're subscribing to a bunch of news feeds and twitter accounts while we try to prepare for the patch and close down what we can. We're calling executives saying "hey, how much money do we lose by being offline for 6 hours?"So even if this isn't as easily exploitable as first believed, no one could have known that, because those with the ability to calm us down were seemingly choosing to stoke the fires.This is (IMO) a failure of the potentially outdated disclosure system that's supposed to protect us. And at the very least a trial run of how the world may react next time, if it really is that bad.
  • tamimio
    >script kiddieGet on time, pa, they are called LLM kiddie now
  • 0xbadcafebee
    RCE is incredibly dangerous not because it lets you execute arbitrary code, but because it lets you execute some code. Code you're not supposed to execute. As soon as someone can do that, all they have to do is probe until they find something to chain.Almost every system on the internet has some local code you can chain to gain root, or a way to put some in place. It gets worse when it affects legacy systems, because they're the bastard stepchild of security. RCE on a box that hasn't been patched since Obama's first term is what little blackhats' dreams are made of. And developers are way too lazy to intentionally design their apps into different privilege domains to protect against chaining. Unless your app runs chroot() (is my neckbeard showing?) or in a container with nothing but a Go binary, somebody can LFI it.A crack in the door is plenty of space to get a crowbar in (especially with interpreted languages).
  • ajross
    It's a digression, but FTA:> When I think about "we're very fucked" CVE10s on the Internet, I think of the following vulnerabilities:Which is IMHO a really good list. It's also, I think, important to note that every single one of the four items is not at all a memory safety bug. They're all logic, at various levels of an interpretation stack.I think a lot of folks with their heads down in the security world might have expected the opposite. As is often the case in engineering, the smartest people end up obsessing over solving the less important parts of the problem.
  • elmer2
    [flagged]
  • cookiengineer
    [removed]
  • nprateem
    Clickbait bullshit from Internet nobodies.https://www.ft.com/content/245778d9-597b-492d-b5b6-a2967c77e...
  • noduerme
    OP seems to be implying that there's no way the UAF bug could be used to run arbitrary code with higher privileges than PHP itself, on a vanilla installation. I couldn't divine that from reading the CVE. Is that true...? Is that why you'd need PHP to exec an existing file or something? Or is that assumption just based on the fact that the PoCs so far rely on nerfing PHP? If the latter, it's a bit ironic to complain about everyone's judgment skewing toward Claude's while using Claude-generated code not doing it as circumstantial evidence that such a thing can't be done.I'm no expert on UAF exploits. I guess one thing I'm wondering is whether the pointer to "freed" memory in this case is still pointing to memory reserved by the system for a PHP process, or if it's some address that's truly free and could be picked up by another process.