There isn't an easy exploit for this PHP vulnerability
文章洞見
原文內容目前無法安全取得，因此未產生文章摘要。
討論洞見
尚無可用的討論摘要。
代表性留言
https://aws.amazon.com/security/security-bulletins/2026-143-...??
squidlib · HN #50189430（在新分頁開啟）
He says it isn't an easy exploit but never explains why it isn't an easy exploit?!
smurf9852 · HN #50192178（在新分頁開啟）
Attacks never get better or stay the same. They only get worse.
hackeraccount · HN #50198627（在新分頁開啟）
So, yeah, this aged like milk. There are now multiple posts from vuln research teams all of whom have working RCE POCs against unmodified PHP applications.I don't really understand the intent behind a post like this. Sure, this is a harder vulnerability to exploit than Log4Shell. Everything is harder to exploit than Log4Shell. How, exactly, is that meant to weigh on people's decisionmaking?For the first time, I think, in my whole career, I saw sites yesterday go down instead of trying to mitigate an unpatchable critical vulnerability. They took the availability hit rather than putting their users at risk. Finally. What purpose is served by trying to dial back the concern?If this was a long nerdy post about exploitability, I'd get it. But it's not. It's essentially a high-level comparison of logic vulnerabilities to memory corruption vulnerabilities. What is this argument for?
tptacek · HN #50198093（在新分頁開啟）
> There are now multiple posts from vuln research teams all of whom have working RCE POCs against unmodified PHP applications.pics or it didn't happen
qudat · HN #50199583（在新分頁開啟）
mind sharing some links to those?
decisionSniper · HN #50199332（在新分頁開啟）
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 ;)
hn773746483 · HN #50189820（在新分頁開啟）
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.
iaaan · HN #50190396（在新分頁開啟）
The problem is, by and large, that AI has drastically reduced time to exploitation of vulnerabilities that modern CVEs are often under-representing their severity. If you've worked in security this year, it's been a march of vulnerability after vulnerability and everyone is waiting for the next big one that exposes your systems.The fact that this particular CVE doesn't have an easily exploitable path has meant very little, historically, in the modern threat landscape. AI has proven it's able to pull off chaining multiple exploits that are very difficult or hard to pull off, but a machine does not care for "ease" or "difficulty".All that is to say, the security community is currently a little gun-shy, but with good reason.
Ohmec · HN #50194233（在新分頁開啟）
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?
kgeist · HN #50189528（在新分頁開啟）
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.
bunderbunder · HN #50189735（在新分頁開啟）
> why is it being proclaimed the worst vulnerability in years?Also announced today: OpenAI’s software vulnerability initiative.
fwlr · HN #50190071（在新分頁開啟）
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.
nemothekid · HN #50190613（在新分頁開啟）
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
letmevoteplease · HN #50190701（在新分頁開啟）
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).
thoughtpeddler · HN #50191666（在新分頁開啟）
Two things can be true: it's a real, exploitable CVE 10, and it's hard enough to construct that you need a good harness + verification process to keep your LLM from cheating. So, the exploit may not be easy to construct, but it doesn't actually require the artificial settings that the OP implied.> What we demonstrated > Pre-authentication RCE on WordPress, Drupal and Joomla[0] https://www.wiz.io/blog/php2shell-php-rce
tibbar · HN #50191976（在新分頁開啟）
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.
dikei · HN #50193629（在新分頁開啟）
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.
lwhi · HN #50192059（在新分頁開啟）
This is such a strange claim from someone trying to sound knowledgable in the field of cyber security (maybe they are, I have no idea who this person is). Even if the exploit would be difficult to use properly, it's not like there's a lack of groups out there trying. Anyone serious about this would consider the fact that a working PoC was reported to the PHP security team. They confirmed the vulnerability and started making a lot of noise about the severity of it, by reporting 2 CVEs and pushing the patch to Linux distros ahead of the official patch release.Trying to understand what the message of the post is all about, I flipped the whole thing around in my head - and the message is basically "you don't need to upgrade your servers". Which is something someone with a working exploit would say. Or it's just noise on the Internet.
nallerooth · HN #50192149（在新分頁開啟）
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.
pms · HN #50192865（在新分頁開啟）
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?
silentbob7 · HN #50193069（在新分頁開啟）
Docker images from Wordpress, joomla, and drupal were all exploitable.https://www.wiz.io/blog/php2shell-php-rce
nickysielicki · HN #50190130（在新分頁開啟）
Name a more iconic trio when it comes to exploits.
Chaosvex · HN #50190395（在新分頁開啟）
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.
opsaythepocs · HN #50191807（在新分頁開啟）
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.
rectang · HN #50190002（在新分頁開啟）
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.
easterncalculus · HN #50189906（在新分頁開啟）
>This is absolutely exploitable...OK, can you share a working one so we can test that our servers are fixed?
1over137 · HN #50190322（在新分頁開啟）
Aren't most PHP sites out there running mod_php anyway?
noduerme · HN #50190210（在新分頁開啟）
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.
0x1F8B · HN #50190279（在新分頁開啟）
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 wordsAs Linus says: talk is cheap; show me the code
SOLAR_FIELDS · HN #50190542（在新分頁開啟）
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.
Maxion · HN #50191747（在新分頁開啟）
> 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.
stickfigure · HN #50189571（在新分頁開啟）
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.
bouncycastle · HN #50190189（在新分頁開啟）
> 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.
SXX · HN #50190738（在新分頁開啟）
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.
amstan · HN #50189456（在新分頁開啟）
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.
hobofan · HN #50191590（在新分頁開啟）
Ah yes, IoT devices, known for their rock solid security
pizzaiolo · HN #50191287（在新分頁開啟）
> 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.
SoftTalker · HN #50190591（在新分頁開啟）
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.
jamesfinlayson · HN #50191997（在新分頁開啟）
I think thats said tongue in cheek.
OrangeDelonge · HN #50190854（在新分頁開啟）
I have the feeling that for some time now the CVE scores are insane. A while back we have a security issue with a dependency in Java that had a score of 9 I believe. It had a requirement that the attacker had root access.
ivolimmen · HN #50191742（在新分頁開啟）
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.
dns_snek · HN #50192796（在新分頁開啟）
There is a strong indicator that this is true:There is no news about hacked websites due to this vulnerability.If anyone could ask Claude for an exploit, one would expect a lot of PHP sites to be hacked just for the fun of it, right? Like putting a message on some popular website or something.
TekMol · HN #50193016（在新分頁開啟）
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?
silentbob7 · HN #50193028（在新分頁開啟）
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
Nemo_bis · HN #50193096（在新分頁開啟）
> 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)
layer8 · HN #50189478（在新分頁開啟）
What's up with these weird ass videos with the anime girls though?
yunnpp · HN #50189831（在新分頁開啟）
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.
Genego · HN #50189601（在新分頁開啟）
In my Slim PHP application container, the only way I could reproduce the PHP2SHELL behavior was by adding `index.php` and `upload.php` from the attached gist to the webroot.As others have said, there are probably other ways to reproduce it, but it requires a lot of prior knowledge of the app environment, or at least a good guess.https://gist.github.com/mashiox/462e15b45a4c891b3a843e11b1d2...
cosinetau · HN #50191520（在新分頁開啟）
If the server supports file uploads (like profile avatar), you can upload an image with embedded PHP code in it.
codedokode · HN #50194497（在新分頁開啟）
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.
Insimwytim · HN #50189681（在新分頁開啟）
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.
Gigachad · HN #50189811（在新分頁開啟）
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.
jeroenhd · HN #50191740（在新分頁開啟）
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.
pinevale · HN #50189412（在新分頁開啟）
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.)
ameliaquining · HN #50189429（在新分頁開啟）
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.
Gigachad · HN #50189524（在新分頁開啟）
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
dguido · HN #50191174（在新分頁開啟）
good to know! are these working generically against fpm with the multipart-progress disabled or against mod_php?
fock · HN #50191942（在新分頁開啟）
I predict that this take will age poorly.
Retr0id · HN #50189595（在新分頁開啟）
Amazon reports finding evidence of an exploit attempt in logs from Saturday October 17, four days before public disclosure [1].[1] https://news.ycombinator.com/item?id=50194070
csense · HN #50194961（在新分頁開啟）
yeah there were several exploits running live by someone before the CVE got postedhonest to god the insane 1-to-1 "show us the code!1" responses we keep seeing here make me wonder if the state-level actor is trying their hardest to keep people from patching.it's painfully clear this is KEV and remotely exploitable on damn near every PHP install -- it's a big deal
red-iron-pine · HN #50195483（在新分頁開啟）
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.
furyofantares · HN #50190393（在新分頁開啟）
That actually increased my credence that the post is correct, because it indicates that the author isn't just a blind AI skeptic.
ameliaquining · HN #50191648（在新分頁開啟）
This was absolutely exploitable. The fact 1000 not-working PoCs exist does not invalidate the one that does.Sure maybe not on a vanilla install but most people don't install Php, they use a pre-made container or a platform using Php under the hood.Yesterday I simply wasn't confident in the security anymore and the data in my database is important enough to go offline for a few hours.
apexalpha · HN #50193117（在新分頁開啟）
Maybe the author does have a point. There are millions of PHP websites and do we know of any that was pwned?
pier25 · HN #50191036（在新分頁開啟）
"Script kiddies (and script adults, who have also switched their brains off)" not something i expected to hear ever but it's so real
dhruvagoyal · HN #50190864（在新分頁開啟）
There seems to be a group of actors, both in this thread and the one about the PHP release, that try to convince readers that patching existing PHP installations is not that critical.I think this group has a good reason for not wanting PHP installations to get patched.
antiloper · HN #50192327（在新分頁開啟）
Agreed. Just because no one has shared the exact exploit doesn't make it not exist.
bpbp-mango · HN #50193325（在新分頁開啟）
Sane people are doing patch management regularly, so no extra work is required hereInsane people never do patch management, so why would they now ? Updating your shit is not a 2026 discovery ..
JackSlateur · HN #50201269（在新分頁開啟）
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...
letmevoteplease · HN #50190765（在新分頁開啟）
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.
loire280 · HN #50190917（在新分頁開啟）
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
malfist · HN #50190835（在新分頁開啟）
I think this is way overthinking it. It's PHP. Even 2, 3 years ago before usable LLMs, if somebody had told me there is a remote execution vulnerability in php I would have found it completely plausible.
rklaehn · HN #50191694（在新分頁開啟）
>> 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...
yamanahlawat · HN #50190640（在新分頁開啟）
This is such a bad take.1. A proof of concept is not an exploit kit, it simply needs to demonstrate that there is an issue, improving it to be more reliable only serves to help bad actors get to real exploits sooner.2. Memory corruption bugs are notoriously flakey, crashing the target without getting code execution is generally always a possibility. Sometimes it is random from run to run, sometimes a particular attack pattern simply won't work against a particular target. Failure to find a working pattern does not imply that no such pattern exist.3. Attacks only get better. This is usually said about cryptography, but applies just as well in this case. Data execution bugs have this tendency to make idiots assert confidently that it is improbable that such a condition would occur without the program crashing. And so the bugs get to live on until someone finds out how to tickle the program in just the right way to make the improbable a lot more likely. Even if existing attacks were as bad as the author implies, it would almost certainly only be a matter of time before someone managed to tweak them to become a whole lot better.4. A big part of why this gets so much attention is the sheer number of high value targets, so many servers run PHP, and they were pretty much all vulnerable. Usually bugs like these still require that the PHP runtime is configured in a particular way and/or the actual PHP code run a particular function using attacker controlled data. That is still bad, but attackers will need to do a lot of digging to find the vulnerable servers.
NohatCoder · HN #50195926（在新分頁開啟）
Okay finally some sense. I felt like I was going insane seeing the freakout over this. From people who would care but a fraction if there weren't some AI angle.
decidu0us9034 · HN #50191863（在新分頁開啟）
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/
richardbarosky · HN #50189555（在新分頁開啟）
People mistake OpenAI and Anthropic for AI companies, but they are in fact primarily in the business of marketing, and business is good.
anonymous908213 · HN #50189664（在新分頁開啟）
It needs only one working exploit to invalidate this post entirely.Even if there aren't any that work OOTB today, there may be tomorrow. Or in a week. They may improve over time. They may combine other vectors. They will probably not exist on Github but somewhere on the dark web as a .zip you pay for in Monero.They will combine shodan with fingerprinting and other ways to find "older PHP versions". There will be brute force versions, that just try every home router for insecure NextCloud. And so on.This is real. This is dangerous. This will be exploited. Because I am sure even after all the noise, (hundreds) of thousands of PHP servers won't be updated for weeks. Many running on a forgotten corner of the web, on homeservers, on a VPS that no-one has access to anymore, in a CI, in a company on the old desktop underneath Jim's desk, on a raspberry-pi everyone totally forgot about.
berkes · HN #50193308（在新分頁開啟）
There only needs to be one working exploit, and yet even with thousands of people working either manually or with LLMs, no one managed to get one so far.Again, obvs you should patch your servers, but the point that this is not an easy exploit stands.
joaohaas · HN #50194699（在新分頁開啟）
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?
silentbob7 · HN #50193546（在新分頁開啟）
Where are the hacked websites? That is the litmus test. I'm looking around and I see... nothing?
JensenTorp · HN #50192367（在新分頁開啟）
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.
commandersaki · HN #50189868（在新分頁開啟）
> but anything of importance would have already had active maintenance and patchingMostly 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.
zer00eyz · HN #50189914（在新分頁開啟）
> It's been 10 hours since this vulnerability has been posted, and half the software world is looking at it, and lord knows 100,000 people have got their "superintelligence" on the case.This is the most compelling argument presented. If this PHP vulnerability were actually so bad, we'd be probably be seeing some kind of widespread impact by now. If every potential target requires a second coincidental, target-specific vulnerability I think we should probably call off the search party.The alternative way to describe this situation is "defense in depth". We've located a very thick part of the ship hull that we could technically drill through if we had enough time and money to do so, but this would not scale up in any meaningful way. What you can do to a vessel in dry dock vs on the open seas are two wildly different universes. Vulnerabilities located under pristine lab conditions or within the context window of a clanker do not bring me much concern.
bob1029 · HN #50192049（在新分頁開啟）