There isn't an easy exploit for this PHP vulnerability

I feel like half of working in the cybersecurity industry is just cultivating your social media persona. It's bizarre. I left a viral up-and-coming startup over it. It was mixing into everyone's personas at work in weird and uncomfortable ways, as someone who doesn't use traditional social media.

People seem to not understand that cybercriminals are lazy, as well. They're not gonna sink a lot of effort into doing something technically impressive when there are way easier ways to generate a decent ROI. Why would they mess around with remote heap grooming when there are plenty of nday rce in widely-deployed enterprise slop just laying around, makes no sense.

This was big news because it was the news that a sector was looking for - that is, “AI Discovers a Cataclysmic and Widespread Vulnerability” - and confirmation bias does the rest.

It took me five minutes to realise that this was something of an nothingburger. As the author states, you basically have to have PHP running as root, and allow an attacker to upload and then execute malicious code on your server already - and if you’re there already the house is already on fire.

From my understanding, the PHP bug is memory disclosure.

The RCE exploit is application dependent: it requires exploitable PHP code already deployed in the server. However, that exploitable code path is widely deployed by the most popular PHP software: WP, Drupal, Joomla, etc, so in practice most PHP deployments are vulnerable to the RCE attack.

In practical terms:

1. An attacker identifies a publicly accessible website running vulnerable PHP.

2. They send specially crafted HTTP requests to the website.

3. The requests trigger vulnerabilities in PHP's internal memory handling.

4. If exploitation succeeds, the attacker can execute arbitrary code on the server under the privileges of the affected PHP process.

That's clearly not the message, the author writes at the top:

> You should patch your servers anyway. There is a real vulnerability here, but exploiting it is significantly harder than people are making it out to be.

The take-home message is about human herding behavior being reinforced by LLM use:

> 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. You've got this bizarre case of "Decision Schelling Points" where a method of solving a problem is extremely overrepresented, because it's what Claude does out of the box.

I would like to disagree, I read it like - people calm down, no need to panic. As vanilla php with default config is not easily rce exploitable.

Why attacking him personally?

> it's not like there's a lack of groups out there trying.

Indeed. And those who knows how to implement this, might also be the ones with capabilities to deploy it on a large scale (via bot nets or whatever).

What about state actors, suddenly getting a possibility to plant backdoors in millions of websites, etc.

You don't have to be too imaginative to see the "economics" of this.

There are multiple write-ups on how the vulnerability works. The Calif one is the most detailed. Also, no one used Claude. There's a whole world of information out there when you read the original sources instead of social media distortions.

https://calif.io/php2shell/

https://www.wiz.io/blog/php2shell-php-rce

I'm not saying the 'Claude says this is bad so therefore it's bad' is at the heart of this PHP vuln, but I'm also seeing the same phenomenon in workplace settings with 'meatproxy'-behavior of so much AI use that tends to overfit and hyperfocus on narrow issues, that then punts the work to other people in ways that just waste time (whereby pre-AI, humans would simply not have the capacity to investigate minuscule issues so they'd never be reported as such). But these days, it's just hardcore meatproxy and reverse centaur vibes all over the place (people just acting as the face of AI, and creating so much work that the other people can't really keep up with any of it anymore), and I wouldn't be surprised if that's happening to some extent in infosec more broadly too. (not saying the vulns and exploits aren't real - but there's definitely a long tail of them now where only a few are deserving of a lot of attention, patching, mitigations etc).

Agreed. The only main post was somebody on jackly something .com who overdosed on the matrix and communication skills of a squirrel picking random tokens from a dozen trees.

I'm actually curious if a lot of shit got hacked because so far it doesn't seem so. Though it seems like it should have? We always see these catastrophic vulnerabilities showing up but when are the ones where it is actually just widespread publicly dumping databases everywhere and at a point where someone non technical even registers it.

I'm sure there is more to it than generally "ask Claude". I asked Claude this as a joke and it downgraded all the way to Sonnet before it would answer, and I was previously approved for their dual use cyber program.

The latest POC video for the php2shell exploit features a dancing anime girl. How would you create a video like this?

The writeups showed up after 14UTC, after the embargo. All of those clowns sharing non working PoCs didn't actually know the bug, they only contributed to the general hysteria

There is an argument to be made that taking down such a sizable chunk of the Internet automatically qualifies it as a pretty severe vulnerability, even if no actual exploits were involved in causing it.

More seriously, though, I read it as bad because of the potential. All versions of PHP going back a full two decades were affected, all users of PHP are affected regardless of which features they use, and it’s still unclear if there’s an effective mitigation. So the blast radius if anyone does/did have a working exploit would have been enormous.

> why is it being proclaimed the worst vulnerability in years?

Also announced today: OpenAI’s software vulnerability initiative.

All the people with LLM on their hands, looking for fame to post PoCs on GitHub, but without zero understanding whether it actually exploited the described vulnerability. Even that most cited blog post here was pure slop, and the exploit did not actually work.

Name a more iconic trio when it comes to exploits.

Yeah, I also got a POC working against a live serve.

The author of the article made a critical mistake in gaining my trust. He said the POC's don't work and told me to run it.

--Which-- POC's, Charlie? Why aren't you giving a full listof what you tried. This isn't reddit, and you're not doxxing or attacking anyone. Post the links. Give sources or shut up.

Article's very vague about how the RCE actually works. They talk about the memory corruption bugs but not how exactly those become RCE.

>This is absolutely exploitable...

OK, can you share a working one so we can test that our servers are fixed?

Can you share a patch or test program to test the issue?

Aren't most PHP sites out there running mod_php anyway?

Just like every other bug, we should patch, but calm down as there seems to be -currently- no evidence for wide rce exploitation in the wild. If that will change this would be new evidence and shall be taken into risk considerations.

Why are you speculating?

I ain't paid to find exploits in PHP, but I will be fired if our shit gets hacked. So I'm taking down the servers until there's a patch.

I totally agree. We can sit here and posture all day, maybe it might justify our paychecks. Exploit it and show me why it’s fucked. Otherwise it’s just words

As Linus says: talk is cheap; show me the code

Bonus points put cryptocurrency private key on their server as bounty.

Do you have the CVE number? That's not unreasonable per se, but it could be bogus as you say. A CVSS (base) score is a measure of intrinsic severity of the vulnerability in isolation which is somewhat unintuitive.

A high severity CVE can have zero impact on your system because the vulnerable code path is unreachable, and a pair of low severity CVEs in your system components/libraries can compound and create a critical vulnerability in your system.

Core run time vulnerabilities in PHP, the language and runtime itself, are rare. I remember the days when an exploit in the JVM was a daily announcement. To the point where they had to ban java applets from the web.

> The difference is that PHP has a long history of vulnerabilities while platforms like Java don't.

Some software written in PHP has a long history like that.

PHP itself mostly dont. Tbh runtime itself has fairly stellar track record on security considering it written in C.

> It wasn't even a problem with the most popular logging framework at the time.

I can't say if it was most popular overall, but it (Log4Shell) was a nightmare for many F500 companies.

I'd disagree. log4shell was a monster to patch and figure out what is and isn't vulnerable.

upgrading php is much easier.

Log4g was exploitable from the second it was published

Log4J was utterly trivially exploitable across basically all configurations, so in that sense it was worse. But any unauthenticated RCE that's on the default configuration of such a widely deployed piece of software is a good cause for sounding the alarms, even if there isn't a script kiddie exploit that will do all of those versions.

> The difference is that PHP has a long history of vulnerabilities while platforms like Java don't.

What makes you say that? I know several websites that ran on unpatched PHP 5 versions for over a decade, without a care in the world until now, because there were no known serious vulnerabilities in the interpreter itself.

Agreed. Just because no one has shared the exact exploit doesn't make it not exist.

Some of them have Karma numbers around 75 and accounts created in mid September.

The CA thing is bad, but in practice a lot more high effort to exploit. As a prerequisite the attacker has to be present on the same network, which makes any individual attack a lot more high effort. In contrast for something like PHP2Shell (if exploitable) any PHP instance exposed on the internet can be attacked by anyone from anywhere.

With a MITM, you also mainly breach confidentiality, but this doesn't directly give you an exploit chain to pwn the device (though the many auto-updaters people are using nowadays might be one).

For IOT devices, there are also factors that limit the exposure. The certs are only from 2025/2026, so few devices with them installed are likely present in any given home, and depending on the hardware footprint devices may only come with the few select CAs bundled that they require due to size constraints anyways.

Ah yes, IoT devices, known for their rock solid security

sounds like you quantized it a bit too hard

I think PHP is fine as long as you use a maintained framework, at least in my experience. I've used SlimPHP and Yii2 in the past and never had any security issues. I've worked on a few PHP sites that rolled their own frameworks which in retrospect was pretty iffy. One of them got yearly pen tests and there were never any issues found but the other two probably had some latent issues.

I think thats said tongue in cheek.

That's a false dichotomy. PHP is mainly used in creating web pages, and a scripting language is not a requirement there.

If you compare it with production languages, PHP looks pretty weak.

What's up with these weird ass videos with the anime girls though?

Anime girl level cataclysmic security events definitely don't worry me as much as laughing man (笑い男) cataclysmic events; only then it's when I really start to panic.

For anyone wondering, this is the song https://soundcloud.com/marlonhoffstadt/highforever

If has anime girl, it means is serious

the dancing anime girl is UI Shigure

Also, High Forever track kind of bangs

the awful edit featuring an underage anime girl only exposes the childish, immature behavior of the people handling this situation, which makes this even more terrifying!

I'm tempted to agree but at the same time we never (?) had news of confirmed data breaches due to log4shell exploits either, so perhaps people are just good at staying quiet when they get attacked.

> Despite the high volume of exploit attempts following the discovery of the Log4Shell vulnerability, reports of major breaches were relatively few. One of the first significant attacks targeted the Belgian Ministry of Defense. Reported on December 12th, just three days after the vulnerability became widely known, the Ministry did not disclose specific details but confirmed the Log4J vulnerability as the attack vector.

https://arxiv.org/html/2501.17760v1#S4

I'm not sure why there are personal attacks on this blogger, his reputation and when the domain was registered. The question remains: is vanilla PHP with its default configuration easily exploitable? What are the prerequisites, and what configuration deviations are required compared to default config in the anime girl video?

good to know! are these working generically against fpm with the multipart-progress disabled or against mod_php?

RCEs?

The specific controversy here is about the disclosure timeline. Some people allege that the disclosure and patch release of this vulnerability were mishandled; others dispute this. The dispute turns crucially on how available exploits were during the embargo period. Nobody is arguing that the vulnerability doesn't need to be patched at all. (The PHP core team didn't initially treat it with much urgency, but they've acknowledged that this was a mistake.)

Time is the whole point though. Everyone was terrified and shutting their websites down because they believed the exploit would be running wild on the internet in between it hitting git and them being able to update the server.

If it takes a week to come up with a working exploit code, the critical services have time to update.

ease is somewhat relevant initially, since it determines how quickly you have to patch before exploits start popping up. I would be extremely curious to see if anyone has been pwned by this already, especially before the public release of the patches (not that I doubt it, but I heard some people saying they saw attempts in their logs, but not really enough information to tell whether they were understanding their logs correctly. The situation just seems a bit murky and unclear to me).

> Ease is irrelevant because you only need expertise once and then everyone can reuse the result.

Not if your LLM relies on existing code and you collectively create a million repos with hallucinated broken implementations that do not work before a good public exploit exists, which later LLMs rely on. LLMs are self-defeating that way.

I guess the main takeaway is: we (humans? current methodology?) are bad at estimating how urgent a fix is or needs to be.

That actually increased my credence that the post is correct, because it indicates that the author isn't just a blind AI skeptic.

The certificates incident was mitigated by the fact it was revoked within hours so by the time people found out, it was resolved.

Yes there is a long tail of Internet of Shit devices that have a fixed non updated cert store, but these devices are being absolutely ripped to shreds by AI from all angles already.

The certificate incident requires a working MitM of TLS traffic. That isn't easy to pull off and browsers will immediately warn you the second they see someone try that.

The PHP exploit, as presented, runs directly from attacker to server. There's no requirement for an attacker to already be in the network.

And a newly registered domain only 3 days old:

  whois eliastaylor.com
    Domain Name: ELIASTAYLOR.COM
    Registry Domain ID: 3148982369_DOMAIN_COM-VRSN
    Registrar WHOIS Server: whois.porkbun.com
    Registrar URL: http://porkbun.com
    Updated Date: 2026-10-02T19:39:03Z
    Creation Date: 2026-10-02T19:14:35Z
    Registry Expiry Date: 2027-10-02T19:14:35Z
    Registrar: Porkbun LLC
    Registrar IANA ID: 1861

The article should be easy to refute (if it is wrong).

Chainguard broke the embargo being convinced they have the evidence of this being widely exploited already yesterday. Where is it?

> so that they end up with 200 comments on #2 on the HN front page

I'm more curious why the top post in this thread is solely attacking the guy's character and not refuting any of his claims.

> An empty blog by a person that may or may not exist with no contact info.

I'd hate to upset all the 'this guy is Keyser Söze' internet detectives, but you've described 90% of posters here (including yourself).

Yes, but the same is true about LLM output. Guess there's actually no way around this than to go look yourself.

they have contact info. look at the first post [0] on the blog, it has their email, zkldi@proton.me

the user "zkldi" is who submitted it to hn also. seems like a real person to me.

[0] https://eliastaylor.com/software-tinderbox/

Why would the identity of the author relate in any way to the correctness of their claims?

The claims:

* The existing exploits don't work. * Reasoning chains producing an exploit have cheated the test.

If the claims are wrong then rebutting them is easy:

* Ask an LLM to produce a real exploit. * Test it.

At least it wasn't the lighthouse keeper Elias Thorne.

Should be easy enough to verify the central claim that you need to be able to read the password file through some other means to use this exploit.

Ad hominem attacks on HN, at the top of a comment thread, just because LLMs were criticized by a human. Welcome to the new age.

> And who exactly is Elias Taylor

A human being, presumably. But he could be a dog or a diffusion model and I wouldn't care, because arguments stand on their own. There is no special caste of people who alone have permission to propose ideas.

You advocate critical thinking. Excellent. Can you critically evaluate "Elias Taylor"'s argument?

The author isn't disputing that these organizations have developed working exploits, they're saying that the exploit is difficult enough to achieve that, as far as they can tell, nobody has publicly released a working exploit except for vibe coders whose exploits rely on insane misconfigurations on the server.

With previous showstopper security bugs, once you knew the vulnerability existed the exploit was immediately obvious.

At least with the PHP one they caveat this with "under the right conditions" which judging by what we know now, the right conditions are you've already exploited the server with a LFI

People mistake OpenAI and Anthropic for AI companies, but they are in fact primarily in the business of marketing, and business is good.

> but anything of importance would have already had active maintenance and patching

Mostly because people either "did it" or yelled long enough and loud enough that it "got done". There is a saying about horses and water, but some people needed to be dragged, kicking and screaming and have their faces shoved in the well.

When headlines like "there wasn't an easy exploit" come out I have burned a lot of good will, on what people will perceive as "nothing burger". The security space has a knack for making a complete mockery of itself and then wondering why no one seems to give a fuck.

"I'm getting too old for this shit" really does apply to today.

It's like y2k. Yeah, there isn't much of a problem currently. We're patching before it becomes a problem. That's not Bot Who Cried Wolf*, that's responsible security. You don't have to wait for a YouTube tutorial on how to do it before it's something to urgently patch.

*My phone autocorrected to that and I'm keeping it.

Can you explain how you got from "attempts to exploit it" to "exploited in the wild"?

Karma 4.

Yeah, I suggested to take down the app someone between seeing the Gina (core) comment (saying php.ini etc changes won't do anything) and after seeing the Cloudflare CTO tweet.

IMO it is a little bit silly to describe “a system that works well until it intersects with a trillion dollar company’s PR campaign” as an outdated failure.

Very well said. Even for non-sensitive stuff that I was told was "super vulnerable", I didn't know if this was a full, actual RCE - some places said yes, others no. Did I need to take down everything running PHP? Just the apps dealing with data I didn't want leaked? Etc.

The rather long delay in getting official Docker images didn't help; we were told "patch now!!1!!" but that apparently meant building from source.

Great reply, this hits the nail in the head and is pretty much exactly how I spent my day. Just reading, waiting and stressing while being essentially in the dark about the whole thing.

I'm assuming the next few days will probably confirm if this was mostly FUD or not.

That has been the reality for your whole digital existence and will continue long into the future. We can only do the best we can.

But the author isn't saying that this isn't a crack in the door. He says it is. It's just not a wide open door.

The original video from where the dancing girl was taken from (she's a vtuber, not in an anime) has 148 million views.

https://www.youtube.com/watch?v=Ci_zad39Uhw

I think Heartbleed is close enough to memory safety to count. It was caused by memory allocator returning uninitialized memory and every memory safe language I know about does not allow this in best-practice code.

(And sure, there are escape hatches - like Python has "recv_into" that could be used to implement heartbleed if you are really inclined to - but this would not be a realistic python program. In python, even with buffer reuse, you'd be using memoryview or similar that can't have a heartbleed problem)

Heartbleed was a buffer overread. Sounds like a memory safety bug... is it not?

Serverside memory corruption is annoying to get working. As a dominant metagame strategy for attackers, it's much more impactful on the clientside.

(I'm not cosigning the analysis in this blog post. I think "I haven't seen a PoC I could get working" is not the evidence this author seems to think it is.)

The vast majority of web services are not written in memory unsafe languages so this is not surprising.

One of the exceptions (with regards to web facing attack surface in a memory unsafe language) is that people still use OpenSSL, which has a terrible history of memory unsafety, including the cited heartbleed.

Huh? Heartbleed is literaly memory safety (buffer over read)

If anything, claiming that this vulnerability has been known and unpatched for 22 years supports the author's point: clearly it's not that easy to actually use.

Glad to be proven wrong but as far as I can see there are no reports of it currently being exploited in the wild at the scale you are implying. It genuinely takes a lot of time to weaponize even with the assistance of frontier LLM models and it is way more difficult when you don't control the server.

I largely agree with the author and it is a common annoyance in cyber security discussions where people make strong claims but have nothing to back it up with.

Do you have any links to a working PoC that appeared before the details were released? I'm seeing a lot of conflicting info, and I'm not really sure what to think. People saying they were seeing people trying to exploit this hours ahead of the patch release on their servers, yet no one who seemingly actually got pwned by it (were people just misreading their logs?)

How about trying to verify the claims with your own brain? It seems you missed the main point of the article.

"I know, I know. It's all you're hearing about. That, and the number 4."

Doesn't look like confusion to me.

> or if it's some address that's truly free and could be picked up by another process

This isn’t a thing; virtual memory (https://en.wikipedia.org/wiki/Virtual_memory) is very old, and Linux has never not used it. It takes a separate vulnerability (a “local privilege escalation”) to do what you’re getting at. (However, those are plentiful, and arbitrary malicious code with PHP process privileges is often already catastrophic for a web service.)

That said,

> 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

No, nowhere does the article imply that at all.