Zoe Kleinman: PHP Is the Cyber Equivalent of an Unexploded Bomb (bbc.com) 100
BBC technology editor Zoe Kleinman likens the recently discovered PHP security vulnerabilities to an unexploded bomb, writing, "The PHP story feels like the cyber equivalent of an unexploded bomb -- I have never seen such a dramatic, public and global response to a cyber event that hasn't happened yet." Although no successful attacks have been confirmed, the AI-assisted discovery of long-hidden flaws has triggered a worldwide security scramble, with websites taken offline as a precaution and administrators racing to deploy patches before attackers can exploit the vulnerabilities. From the report: The weaknesses found in the PHP programming language, which is used by millions of websites, had been quietly resting there for years and are not easy to exploit. One cyber security researcher told me he'd been up all night trying to do it as an experiment, but it was proving very difficult. [...] It was supposed to be kept quiet until everyone had a chance to fix their sites -- but the news was leaked. From that point the clock started ticking.
As I write this, there are no reports that anyone or anything has succeeded in using the flaws to attack a site. "There's a real dilemma," said Prof Alan Woodward from Surrey University. "How do you alert people they need to be ready, and then that a patch is urgently required, whilst not alerting attackers? Basically you're telling everyone about the problem at the same time and hoping the defenders aren't awake enough to act as soon as the patch is out."
But we do know from large web companies like Cloudflare and Palo Alto Networks that millions of attempts have been made. We probably won't know for a while whether it has worked for any criminals, because the companies affected might not be aware yet either. As far as we know the unexploded bomb remains intact for now, and for some experts this is a success. "We've seen how a team of people supported by the large AI company have used AI to find the problem, work for months together to solve it and get everybody ready to be safe and secure," Gina Neff, Professor of Responsible AI at Queen Mary University, told the Today Program on BBC Radio 4. "We have enormous capability to handle these risks."
As I write this, there are no reports that anyone or anything has succeeded in using the flaws to attack a site. "There's a real dilemma," said Prof Alan Woodward from Surrey University. "How do you alert people they need to be ready, and then that a patch is urgently required, whilst not alerting attackers? Basically you're telling everyone about the problem at the same time and hoping the defenders aren't awake enough to act as soon as the patch is out."
But we do know from large web companies like Cloudflare and Palo Alto Networks that millions of attempts have been made. We probably won't know for a while whether it has worked for any criminals, because the companies affected might not be aware yet either. As far as we know the unexploded bomb remains intact for now, and for some experts this is a success. "We've seen how a team of people supported by the large AI company have used AI to find the problem, work for months together to solve it and get everybody ready to be safe and secure," Gina Neff, Professor of Responsible AI at Queen Mary University, told the Today Program on BBC Radio 4. "We have enormous capability to handle these risks."
PHP (Score:3, Insightful)
Re: PHP (Score:2)
Why did it seem that way to you?
Re: PHP (Score:4)
Re: PHP (Score:5, Informative)
Because it embeds into html, rather than rendering the html. It makes for very fragmented code.
In my experience, most sufficiently advanced use of PHP involves rendering the HTML. You can do it either way.
And most sufficiently complex PHP uses PHP as a full-fledged language, complete with classes, etc., and to the extent templates are used, the code in them consists of tiny partial-line-long fragments of code that call some method in some other file that is basically just code.
In other words, very fragmented code isn't caused by PHP; it's caused by the way that the developer chose to use PHP.
Re: PHP (Score:2)
Quite. Drupal used to be a mess like that before they rebased on Symfony.
Re: (Score:2)
Because it embeds into html, rather than rendering the html. It makes for very fragmented code.
Yeah, that's pretty old-fashioned. In my experience, it's barely done now. Kinda like how nobody writes JavaScript like it's Pascal anymore.
Re: (Score:2)
Re: PHP (Score:2)
Re: (Score:1, Troll)
The reason it seemed that way to me was that it was invented by an idiot who thought programmers were stupid and arrogant and programming could be made "easier" by somebody who just ignored (or didn't learn) traditional algorithms and best practices.
Somebody who thought code architecture was lame and unnecessary.
Of course bad things happen. Again. And again. And again. And are still happening decades later.
Re: PHP (Score:5, Informative)
It sounds like you're talking about PHP 1.0 from 31 years ago. That's not at all like the current PHP.
Re: PHP (Score:3)
How dare you infringe on my right to cement my opinions based on something I heard decades ago!
Re: (Score:1)
So you're disputing even that it was true? You're as arrogantly stupid as he was!
Re: (Score:1)
"We added cruft again and again, surely that's what programmers do to make a language better!"
Yeah, you're right! It got even worse when they realized they did need those things, but didn't want to change the architecture to be like other languages. Why do other languages do it that way? Because they're stupid! We'll just tack it on in the least obtrusive way. Sure that's better than having architecture that's built around the algorithms everybody else knew we'd need....
Re: (Score:2)
The PHP team has been consistently improving the language, standard library, and runtime. Do you have any examples of recently added cruft?
Re:PHP (Score:4, Insightful)
They're all like that though.
Perl
PHP
Python
Ruby
Node.js
The only thing that makes PHP the language of choice here is how it was originally easily integrated into apache httpd via mod_php. This exact same scenario could happen to all of those, because all of those are scripting languages that run inside the security box of the user account or the web server. mod_php runs as the web server unless it's configured as mpm_event/mpm_worker in which case the child processes can be run in a different one.
The only case where this would never happen is if there is no scripting language. eg your web application is compiled (Which is the case with C/C++/Rust/Java) because there is no functionality within the application to execute something outside it's process.
like one of the things I do on servers is remove eval() and system() and exec() to prevent running anything from the scripting language. But most stock installations do not do this. removing the ability to open remote files is even better, but unfortunately that breaks the auto-updates in several CMS systems.
Re: (Score:1)
> The only case where this would never happen is if there is no scripting language. eg your web application is compiled (Which is the case with C/C++/Rust/Java) because there is no functionality within the application to execute something outside it's process.
That makes no sense at all. Compiled applications can have RCE bugs, it changes nothing. Well, maybe you need to make a few more requests, as you usually don't know the exact software & hardware platform of server, and have to try different shel
Re:PHP (Score:5, Insightful)
Over the next few months, this same story is going to repeat for Ruby, ASP, Python, Node (or JS in general),
Running a public-facing webserver is about to become the losing side of an inevitable arms race.
Re:PHP (Score:5, Interesting)
These are also many of the most looked at, most often fuzzed, SAST scanned, valgrind'd things in the world.
I really don't think it will be as bad as all that. We have not seen Apache, Nginx, etc pwnd like this, or OpenSSH, or Bind, or postfix ...
I could go on. I think the actual posture and condition of most of these project is far better than you apparently expect. (I guess we are going to see who is right).
What AI is finding is stuff the other scanners miss, which is stuff where there is a clear temporal component. We are going to see races, toc-tou, probably more stuff like these PHP issues which if I understand correctly is a use-after-free or something you could at least force into that taxonomy.
So there are going to be new bugs found, even seriously impactful appearing ones, but the reach-ability and chances of successful exploitation outside laboratory conditions is going be low... Do they work when it is a VM on you lab server you can hammer away at with 1000 threads yes; when there is a AWS ELB in-front or a waf that has any impact on request ordering or pipe-lining, good luck..
I am not saying people won't be spending more hours patching over the next year or so than they have been, they will but the sky probably also isn't falling
Re: (Score:3)
Wow, BIND, though? Do a quick search on "history of BIND vulnerabilities." Sure, people run all these tests on it now, and in the past, and the history has been there's been a lot of causes of concern.
Re: (Score:3)
Bind has gotten better, but 10 years ago and longer it was utter crap with regards to security.
Re: (Score:2)
What the AI does is not impressive. Finding use-after-free requires you to be competent and wanting to find them. Approaches for finding and avoiding them are well established, the current slop-coders (with or without AI) just do not know or use them. AI is not needed in any way. AI is just the ElCheapo approach when you do not care about finding all of them (due to LLM unreliability).
Re: (Score:2)
Probably not for .NET. Microsoft has been using AI to find bugs in its products for months now, hence the high number of patches through Windows Update. Doubtless they have already thrown it at .NET.
The Linux kernel is in the middle of this at the moment.
Re:PHP (Score:5, Interesting)
People say that but I think they say it without a lot of real understand of what the web was like when it was born, and second that PHP5(+) does not look much like PHP 4(-)
Before PHP there were CGI scripts/programs, which were Perl, sh, or C or if you were on Windows classic-asp. If you wanted maintainability your wrote in Perl (yeah I am being serious) and if you wanted performance or needed to do something complicated you wrote it in C. Remember we are talking 1995-97 here there isn't even a C++ standard yet! These were you main choices for 'web development'.
PHP let people do what demanded C in something that did not have to be compiled and did require understanding C style memory management. Here comes the big BUT though, all the really good, really useful library code out there was C. All those library authors did not talk to each other so everyone was different in terms of conventions, who allocates the the caller or the called, who frees, are we passing references or values for primitives, etc. All different and php did not attempt to hide any of that as it pulled in those libraries it wrapped them in its runtime and memory management without attempting make their use orthogonal and part of some consistent ecosystem.
It wasn't a 'hack' it just was not a complete abstraction.
That was 'fine' for people who came to PHP from writing C, and were using PHP because it let them make changes on the fly, saved writing a lot of boiler plate request life-cycle management stuff, etc. It all made sense, if you can at it not from C though it was confusing mine-filed of gotchas. It made web development possible for a whole lot of people who never got access to compiler. That was cool, but it also put a lot of power in the hands of people the way the Visual Basic "Declare" keyword did, and unsurprising they did hack-y things with it, cause themselves all sorts of problems..
Re: PHP (Score:2)
Re: (Score:2)
Having fragments throughout html was a bad idea from the start.
Rust Rocket whistles innocently.
Re: (Score:1)
>So you can write a PHP program that renders code now?
This sounds disingenuous. You could always do this, you were never forced to embed php within html. The 'smarty' templating library was released 26 years ago to simplify html rendering. The embedding technique has died off long ago for web development and is not recommended or considered as a serious approach.
PHP has come a long way since the 90s and is in active development despite all the handwavy dismissals of it.
Re: PHP (Score:1)
Re: (Score:2)
That is very very old.
Re: (Score:3)
It's popular for services that run on a shared hosting model because it can be run as either a cgi processor or via mod_php. It gives you access to backend scripting and all you need is a shell account. That's becoming less relevant in the age of containerization and VPSes, but it still has a lot of inertia.
Re: (Score:3)
I like hack languages. But many years ago, my friend setup PHP on my server (LAMP style) and it got hacked and defaced, so I updated it and tried to set it up correctly while also making sure the applications people wanted would work. (just a little hobby server). Got hacked again two years later, even though I was mostly just following the distro's updates. I kind of felt it was a bit of chore to keep PHP secure, more work than I could commit to.
I ran AOLserver for a while (Tcl-based apps server) and it wa
Re: PHP (Score:2)
It seems like most are now using php-fpm. It's convenient because it allows any number of PHP versions on one server.
Re: (Score:2)
FastCGI in general is an improvement over what I used to use, well I had mod_fcgid and some python stuff installed for a bit many years ago. And of course PHP-FPM is pretty battle tested, or so it seems. But I really do believe juggling multiple versions of PHP to be an anti-feature. Having to deal with more than one set of security forks multiplies the amount of work for the admin. You certainly don't have to use the feature, but I can't think of too many situations where going that road is going to help m
Re: (Score:2)
There are sadly just projects which depend on older versions still being used. It's pretty normal for an ISP to need to maintain at least a couple of versions. And since PHP changes important things in minor versions sometimes, you need at least a couple of minor versions of each as well. That's probably my least favorite thing about PHP.
An Unsatisfying Success Story (Score:5, Insightful)
A real, major vulnerability was discovered, its announcement was botched, the whole world rushed to protect people and systems, and we're sad that it wasn't a greater catastrophe. What a wonderful takeaway.
Re: (Score:3)
It reminds me of Y2K. The plebs say "It was a big nothing-burger." When they do, I say "You're welcome" as many of us spent time in the '90s making sure it would be a nothing-burger.
Nothingburger (Score:5, Interesting)
There isn't an easy exploit for this PHP vulnerability [eliastaylor.com]
Re: (Score:2)
Only one of the exploit chains requires LFI, there's other paths of triggering the exploit
Re:Nothingburger (Score:5, Interesting)
I had my clanker (Qwen3.8-abliterated) try for over 10h to weaponize some of the best looking PoC with no results except crashing workers.
ASLR was the first thing that blocked it, then it tried with it disabled for that process. It did manage to reliably crash a php-fpm or apache2 process with bad input.
So yes there is a problem, bad stuff is happening in the memory management and there are bugs.
ASLR is partly to thank for making exploiting this significantly harder.
There's also a lot of things that might be tied to the specific version of glibc and other hardening aspects.
Mitigations work (Score:4, Interesting)
See, this is a case of mitigations working. ASLR makes the exploit substantially harder weaponise. There are plenty of other mitigations you can use to reduce the chance of a bug being successfully exploited. Examples include:
You need to be paranoid and assume the network is hostile.
Re: (Score:2)
I would be wary of that statement. It says "nowhere as easy as log4shell". Log4shell was so easy to attack that it is hard to imagine making it any easier. And second, while the author claims the published exploits do not work against "vanilla PHP", that is a really weak statement and there is no analysis given why they do not work and what is needed in addition.
Ahh... youth (Score:5, Insightful)
I have never seen such a dramatic, public and global response to a cyber event that hasn't happened yet.
Somebody missed Y2K.
Re: (Score:2)
I'll never forget the Y2K crisis [youtu.be].
Re: (Score:2)
My friend filled up his bathtub with water on Dec 31st.
About a week earlier he found a giant sale on Earth Sugardrink at the discount warehouse and bought a whole pallet. If society collapsed, the water might not be safe to drink for awhile.
Fast forward two years, he had diabetes. I wish I was joking.
Re: (Score:2)
Y2K was completely overblown and exaggerated.
Re:Ahh... youth (Score:4, Insightful)
Y2K was completely overblown and exaggerated.
That's often said by clueless posers who have no clue how much work went into addressing it.
Re: (Score:3)
It was not. People did a lot of hard work to prevent the catastrophe and it paid off. Otherwise a lot of stuff would have collapsed.
Re: (Score:2)
Oh I'm absolutely aware and vividly remember it. While some work was absolutely necessary, the problems and fallout that could have happened really was never going to be as bad as anyone really made it out to be.
Re: (Score:2)
You're welcome. Yes, the media liked to overhype things like they always do, but many of us spent time in the mid '90s inspecting code and making changes where necessary to make sure it was a non-event. It was never going to be a case of planes falling from the sky and the world reverting to the stone age (sorry, Family Guy), but rather annoying things like not being able to run billing cycles or calculate interest correctly.
People have already been working to resolve issues so that the Y2038 problem is a
Re: (Score:2)
annoying things like not being able to run billing cycles or calculate interest correctly.
Oh no. So catastrophic. /s
Unexploded Bomb (Score:2)
All software has problems waiting to happen, nothing special about PHP in that regard.
Re: (Score:2)
First, many knowledgeable techies can't write for the general public. I'd say most can't. The general public doesn't need "intelligent technical articles" by the techies. It needs it explained in their terms.
Second, it is absolutely insulting to judge someone solely by their degree after 25 years of professional experience in the field of tech reporting for the general populace.
Re: (Score:1)
2. She has been talking shit about stuff she doesn't understand for a long time.
3. There are many well-spoken people with actual technical knowledge who can explain stuff clearly based on that knowledge. Unfortunately many of them are white and have penises, so will not be employed by the BBC.
Let me guess, you're a fan of Stephen Fry and you debug your TCPIP socket calls using Ted S
Re: (Score:2)
1. Slashdot is not the general public, FFS, and needs intelligent, factual technical stories written by their fellow "techies".
How many links about the PHP vulnerability have you submitted?
2. She has been talking shit about stuff she doesn't understand for a long time.
*Citation needed
3. There are many well-spoken people with actual technical knowledge who can explain stuff clearly based on that knowledge. Unfortunately many of them are white and have penises, so will not be employed by the BBC.
Not once today did I ever think about other peoples penises. You might want to do some deep self reflection. And while we're talking about skin color, Zoe looks pretty white to me. https://www.linkedin.com/posts... [linkedin.com]
Re: (Score:1)
Fuckwit: "*Citation needed"
Look up her explanation of cookies.
Re:Zoe Kleinman ?! WTAF ?!?! (Score:4, Interesting)
I did a web search "Zoe Kleinman cookies" and it didn't turn anything up. I guess it isn't a prominent example of her reporting.
Also... she's primarily a television presenter. Not a person who writes the stories.
She's now also "BBC Technology Editor," but note that she is the first person to serve in that role. Longtime readers of BBC content, or listeners, (and I assume watchers, though I don't watch their television programs) know that they do not include "technology" content targeted at programmers or engineers. Their coverage of technology covers two areas: Business, and Consumer Products. There is not, and never has been, coverage of technical aspects of anything. If they're talking about "cookies," they're explaining it to a grandma who thinks it is a segue into a baking program. You have to know the context and audience to weigh the content. If the explanation is silly, it doesn't mean the writer doesn't understand cookies.
Anything that around technology that is actually "news" and isn't a business, culture, or consumer story would be published by their Science reporters and editors.
TLDR; you're too stupid to talk about the BBC.
Re: (Score:1)
She described them INCORRECTLY. She did not simplify for her audience, SHE GOT IT WRONG.
That is because SHE KNOWS NOTHING about tech and is a crappy DEI hire who go the job by the usual BBC criteria of HAVING A VAGINA.
TLDR; You cannot do argument. Stop trying.
Re: (Score:1)
The vulnerability was known about 2 years ago. Only the working attack is new. AI has changed how fast we can do this.
https://tolmo.com/blog/faster-than-anyone-can-fix-them/
Re: (Score:2)
Apparently you live in a weird cave where you can only access slashdot and right wing social media, maybe faux news, so I'll give you a spoiler:
Most of the BBC editors (who choose the content) are old white men with a history of sexual harassment complaints. It should be your kind of content.
Re: (Score:1)
CLUEHAMMER: You're an idiot, you lost the argument.
Fuck you and your feminazi manhate.
Re: (Score:2)
Re: (Score:1)
DEI doesn't introduce a bias in favor of women, it reduces biases in favor of whoever the system is currently biased in favor of.
If you think DEI is affirmative action, then you don't know what DEI is. It's literally the exact opposite.
Re:Zoe Kleinman ?! WTAF ?!?! (Score:5, Insightful)
people will assume that any woman hired was hired due to this bias
No, "people" in general won't assume that, but pre-biased idiots that are looking for an excuse will.
Re: (Score:2)
> Second, it is absolutely insulting to judge someone solely by their degree after 25 years of professional experience in the field of tech reporting for the general populace
Oh, it's not just the degree he's judging the journalist on, it's also that she's a woman. Because everyone knows in "We use DEI as a pejorative despite not knowing what it means" lala conservative land women don't know things like us smart men do.
What a fucking tool the GP is. Not as bad, I suppose, as the guy who posted an anti-Se
Re: (Score:1)
A lie, you lying cunt.
Intelligent people support hiring on merit and oppose sexist, racist DEI.
And then there are stupid, lying, woke cunts like you.
Re: (Score:2)
Because the average person doesn't know PHP from PBJ. Oh and fuck off with your DEI bullshit.
Re: Zoe Kleinman ?! WTAF ?!?! (Score:2)
You forgot to mention "...And she's a woman! " as one of the reasons not to listen to her, if you're just going to list ad hominems and strawmen. Also, just say "She's Black" instead of "DEI hire", we all know what your real point is so no need to dress it up.
Re: (Score:1)
She got the job because of the BBC's SELF-CONFESSED DEI hiring.
And she is not black, you demented woke cunt.
Re: (Score:2)
Then men shouldn't be listened to about abortion since they know nothing about a woman's body.
Re: (Score:1)
Demented manhate comment, wholly unrelated to the discussion.
Let's guess: Gender Studies ?
Re: (Score:2, Informative)
She is unambiguously white, though.
She does have hazel eyes, though. Probably a lizard person. (/s)
That's why (Score:5, Funny)
The unexploded bomb resides in the MMU (Score:3, Informative)
CVE-2026-109619: Critical Use-after-free. Stale global state across requests. Can cause subsequent requests to access freed memory, potentially leading to memory corruption and RCE.
The underlying bug: PHP enforces its memory_limit setting. When execution exceeds that limit, PHP can use the C runtime mechanism longjmp() to escape the current execution path and abort request processing.
The problem is that this abrupt exit can interrupt internal PHP operations before their data structures have been fully initialised. Request cleanup may subsequently treat those incomplete structures as valid, potentially attempting to free or otherwise process invalid pointers.
This creates a memory-safety failure during error handling: the error-handling path itself can corrupt memory.
How come gweihir didn't find this before AI? (Score:1)
Is he too lazy?
Much unlike the epitomes of ... (Score:2)
... cybersecurity: .Net C# and Java.
*Dadum* *Crash* *Thud*
Thank you, thank you, I'm here all week.
bootstrap (Score:2)
Zoe's own site is a bootstrap.js site. I thought it would be funny if her site was built one of the millions of PHP CMS systems. But it's not.
Just update the system (Score:5, Insightful)
I just spent 3+ weeks updating a system, and was told multiple times it didn't need to be done, and I was wasting time and resources. This morning, that project released a major notification of a serious flaw, and we're already on the newer version which is safe. The real problem was never PHP, or Node.js, or X (not Twitter), it was the refusal to update and keep systems updated.
Re: Just update the system (Score:2)
PHP is easy to update if you use FPM. Just install the new version and twiddle your config.
Re: (Score:2)
Re: (Score:2)
They literally released the update yesterday you smug pinhead.
If you aren't running updates every hour, you probably don't have it. Hell, if you don't have a distribution with the latest version yet, you don't have it.
Re: (Score:2)
Prove Python, C#, JS, or Java safer (Score:2, Insightful)
or STFU about PHP.
Re: (Score:2)
Well, JS isn't any better, but the rest are superior to PHP. PHP is hot garbage.
Re: (Score:1)
Are you talking as a language per programming productivity, or per security?
Re: (Score:2)
Doesn't matter.
Reducing Risk (Score:2)
There are options which reduce the risk of this whole category of attack.
Two examples are (a) automatic zeroing of freed memory, and (b) inspecting and filtering suspicious HTTP requests.
These are not foolproof, but they reduce the risk of being attacked by an exploit of the next vulnerability.
The major reason they are not used is that they tend to come with a performance hit. But you'd think they might be useful as a temporary "switch on" option, when the alternative the company is considering is taking do
Re: (Score:2)
At this time, any kind of use after free vulnerability in production code musst be regarded as a sign of gross incompetence. This one seems to have been harder to find or nobody was looking. But still.
Ways to find/avoid: Zeroing pointers on free, "gcc -f analyzer", tests with valgrind (test data needs to trigger at leat a read to free'ed memory), code review, some other tools and less less general ways. The first two are cheap and should be standard. Code review for this problem should be at well.
Zeroing me
Re: (Score:2)
They need to be able to jump across memory to handle interrupts and exceptions.
And they have no way to know what kind of data there is in the objects THEY DID NOT MAKE.
So I asked ChatGPT, as you do..... (Score:2)
And this is what it told me. This is the best the BBC could fine to explain PHP to its viewers? Someone whose main acquaintance with technology has probably been writing literary criticism (nowadays called reporting and jurnalism) in Microsoft Word?
____________________________________
Zoe Kleinman is a British journalist and broadcaster who serves as the BBCâ(TM)s first-ever Technology Editor, a role she took up in 2021. Her background combines a university education in English literature with more th
Re; Unexploded Bum. (Score:2)