__ __ _ _____ _ _ _
| \/ | ___| |_ __ _| ___(_) | |_ ___ _ __
| |\/| |/ _ \ __/ _` | |_ | | | __/ _ \ '__|
| | | | __/ || (_| | _| | | | || __/ |
|_| |_|\___|\__\__,_|_| |_|_|\__\___|_|
community weblog
Major PHP Vulnerability Discovered
Writeup at wiz.io A critical vulnerability in the PHP programming language has been recently discovered which can grant remote code execution on affected hosts. Almost all current versions of PHP (from 5.4 all the way up to current 8.x releases) are affected - just about all PHP-backed web apps can offer gateways to exploitation - Wordpress, Roundcube, Joomla, phpBB, etc Patches to mitigate the vulnerability have been released as of this morning.
posted by signsofrain on Oct 21, 2026 at 11:02 AM
---------------------------
Another solid writeup from Fastly, including a list of "things attackers can do with this vulnerability."
Most of my large university's web presence is either shut down entirely or 403ing everybody who's not coming from a campus IP block.
posted by humbug at 11:04 AM
---------------------------
My municipal government employer shut down most of our public facing websites this morning, in order to protect against this vulnerability while we applied those patches. Most of them are back up and running now, with a few still to come. As vulnerabilities go, this is...a lesser one? Sort of? I mean, it's objectively bad, but it's not Bringing Down The Internet-level bad, at least for relatively well-managed IT orgs.
posted by pdb at 11:18 AM
---------------------------
So if MeFi needs to go down for a patch do we get on IRC or what? I don't remember how to do that. It's been decades.
posted by postcommunism at 11:18 AM
---------------------------
I mean, it's objectively bad, but it's not Bringing Down The Internet-level bad, at least for relatively well-managed IT orgs.
The Fastly writeup that humbug linked to above is instructive on this one--they specifically call out high-risk targets, and most of them fit the profile of "inadequately resourced orgs." It's full-on RCE, and a 10-year-old Apache server running in full maintenance mode is also likely to be part of a badly-configured/nonexistent VPC, or running the reductive case of an unencrypted MySQL database on the same physical server. Big tech shops aren't going to be super vulnerable, but the internet is mostly made up of shitty PHP configurations that are going to be compromised quickly. All it takes is a user re-using login credentials on a single affected server.
This is gonna be bad.
posted by Mayor West at 11:32 AM
---------------------------
I mean, it's objectively bad, but it's not Bringing Down The Internet-level bad, at least for relatively well-managed IT orgs.
So much of the it is interconnected in not-so-obvious ways, though, and much of it is not relatively well-managed. Or managed at all.
posted by scottatdrake at 11:33 AM
---------------------------
At the same time we have the eMudhra Intermediate CA Compromise which is perhaps just as bad? Or worse?
posted by scottatdrake at 11:34 AM
---------------------------
For a responsive IT dept, on Ubuntu at least, the fix seems to be trivial? It looks like even PHP 7.x is covered with a patch via Ubuntu pro -- so pretty trivial to apply the patch released today.
posted by aletheia at 11:36 AM
---------------------------
I know someone who has clients building websites on a cPanel server with PHP 5 in their accounts and he is having a crappy day
posted by infinitewindow at 11:44 AM
---------------------------
Yeah, this seems to be in the realm of vulnerabilities that is absolutely devastating in impact BUT 1) the actual fix is pretty easy as long as you're not too too out of date with your PHP implementation and 2) Cloudflare and other similar infra providers have some ability to filter out the attacks at the network level, meaning slower/lazier orgs have at least some protection if they're behind that type of service.
There are also apparently a few simple PHP config settings you can make to mitigate against the vulnerability, but I don't really have a good enough understanding of the stack to immediately understand how much protection those give.
On an older PHP version, with minimal support staff around to fix it? Very bad. But also, PHP that old is probably already vulnerable in a dozen other directions if they don't have someone to watch over it.
posted by Room 101 at 11:51 AM
---------------------------
My debian server, my ubuntu server and my Mint laptop all have the latest PHP fixes.
My two Raspbian Pi computers still do not ( but they're not on the web)
Today is also the usual time Drupal releases any Contrib Security Releases so, it's been a busy day today.
And if you want a nice angry rant about it all:
So today some of the worst people on earth using the most environmentally destructive tools on earth brought down a huge part of the internet by exploiting a potential problem found many years ago in PHP which was previously not practical for anyone to exploit.
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 11:54 AM
---------------------------
Sounds eerily similar to an event in France last week where hackers turned up the temperature in thousands of grocer freezers that hadn't been patched with a new update.
posted by antibillionaire at 11:59 AM
---------------------------
Interesting take linked by f4a above. Looks like it's referring to this, from PHP themselves:
A first external audit and increased security focus
In 2024, PHP underwent its first external security audit in years. The PHP Foundation secured funding from the Sovereign Tech Agency to organize this audit through OSTIF, and it was carried out by Quarkslab. While fixing one of the issues Quarkslab reported, a PHP core developer contracted by the PHP Foundation found the first signs of the OOM problem behind CVE-2026-109618. In 2024, a potential exploit for the OOM problem was theorized, but no concrete vectors were found and other concrete issues with clear impact overshadowed these concerns.
To fix the OOM problem, the PHP security team developed several competing approaches, but each came with its own trade-offs: backward compatibility breaks, new denial-of-service potential, or requiring changes to many third-party extensions which seemed impossible to coordinate. The PHP security team, operating on consensus, struggled to choose between these and feared the repercussions of shipping the wrong choice. Combined with the lack of a known path to remote code execution and the small team of core developers with the necessary deep knowledge of the engine occupied with many responsibilities, this decision process caused work on a fix to stall and restart repeatedly over months. We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources. The security team has since started changing its processes, and that work continues, so that decisions can be made by majority and compromises are encouraged.
(italics mine.)
posted by postcommunism at 12:05 PM
---------------------------
It's been a very long time since I've had to worry about or even think about PHP so I'm curious right now... is a machine on the internet vulnerable to remote PHP execution if it has runtime (or Apache execution or whatnot) enabled, even if it is not hosting any PHP files?
> ...the internet is mostly made up of shitty PHP configurations that are going to be compromised quickly.
Like I said in the eMudhra TLS thread, what most hosting companies have done in the past during previous PHP crises and are probably doing right now is plow ahead, patching the vulnerability in place.
Granted they're going to test and update their centrally-managed applications like cPanel, Wordpress, web mail and forum sites. Once those are vetted, though, any breaking bugs introduced are going to be their customers' problems, not theirs. And that's going to include for example any instances of WordPress that a customer uploaded on their own in lieu of using the hosted version.
posted by at by at 12:13 PM
---------------------------
> is a machine on the internet vulnerable to remote PHP execution if it has runtime (or Apache execution or whatnot) enabled, even if it is not hosting any PHP files?
From what I understand, the vulnerability is in the PHP processor itself, so if it's enabled, you are vulnerable even if you don't have a single .php file on your server. Having PHP "Enabled" is a little more difficult to confirm, you'd need to check your web server configuration (the most common ones being Apache and NGINX).
I notice that hosting companies are applying mitigations already at the Web Application Firewall level (WAF)as well as by updating PHP. For example : https://www.dreamhoststatus.com
posted by soylent00FF00 at 12:25 PM
---------------------------
So today some of the worst people on earth using the most environmentally destructive tools on earth brought down a huge part of the internet by exploiting a potential problem found many years ago in PHP which was previously not practical for anyone to exploit.
One can certainly argue that AI companies have been irresponsible in racing to release systems that can power exploit automation to the general public (though when they made a point of holding back people called that a publicity stunt), and that may change the calculus around public disclosure, but when in the history of computer security has it been considered appropriate to blame the people who proved that an exploit for a longstanding vulnerability was practical?
posted by atoxyl at 12:30 PM
---------------------------
> ...when in the history of computer security has it been considered appropriate to blame the people who proved that an exploit for a longstanding vulnerability was practical?
Probably more to the point, we should expect that any exploit that becomes public has already been known to unaffiliated parties who would prefer it to remain their own special secret.
posted by at by at 12:39 PM
---------------------------
Happy Cybersecurity Awareness Month, everyone!
posted by rum-soaked space hobo at 12:42 PM
---------------------------
Yeah, it's been interesting how the AI discourse has shifted at conferences - in 2024 RedHat connect was all "Hey this LLM AI stuff is great, everybody should be using it!", while in 2025 is was more of a "ehhh make sure you have an actual ROI on those AI plans, hey?". In 2026 a lot of it has been sort of geared towards establishing a proactive stance towards AI vulnerability discovery and disclosure, between Redhat Lightwell for fixing vulnerabilities in old and out of date libraries to using event driven Ansible for generating processes to accept that maybe a short outage (SIEM notification->EDA play->app/OS lockdown) is better than a prolonged vulnerability and legal liabilities.
Because yeah, it used to be that there was a window between a vulnerability being discovered and actively exploited that remediations could be engineered, patches could be applied, etc, but now with what amounts to automated attack tooling, that buffer basically doesn't exist any more. What can you do to be proactive beyond patching more frequently?
I'm curious how this is going to upend containerization and suchlike - I get that maintaining library compatibility with an in-house app isn't necessarily just as easy as patching to the most current release, but on the other hand it feels like a lot of containerization is based around pinning at some downrev and potentially vulnerable version of a library because the alternative is too much effort. I suppose the counter-argument is that great, you've exploited your way into the application's container, now what? But the developing situation seems to be that stringing together compromises that used to be too much of a pain in the ass to do by hand are now pretty trivial for the robots, so application exploit to container exploit to OS exploit to bitcoin miner install, baby!
Good times.
posted by Kyol at 12:49 PM
---------------------------
So today some of the worst people on earth using the most environmentally destructive tools on earth brought down a huge part of the internet by exploiting a potential problem found many years ago in PHP which was previously not practical for anyone to exploit.
This is a comically bad take. There are dozens of orgs for whom spending the resources to develop an exploit would be practical. Almost all of those orgs would be heavily incentivized to keep such an exploit private.
posted by yeahwhatever at 1:31 PM
---------------------------
The eMuhdra certificate compromise (which is hilariously bad) is going to reach further than people think because electron apps store their own certs internally, and don't rely on the OS or external sources. They'll all need updates/reinstalls.
The PHP vulnerability is going to reach further than people think because an awful lot of rarely-updated web-facing appliances run PHP, including ISP-provided routers the world over.
The number of "relatively well-managed IT orgs" out there is far smaller than anyone realizes, because being a well-managed IT shop is far, far more expensive and difficult than anyone thinks and the number of undermanaged and underfunded organizations out there, like libraries, schools, non profits and a million small shops whose main priority is literally anything but IT is not small.
posted by mhoye at 1:32 PM
---------------------------
I'm curious how this is going to upend containerization and suchlike - I get that maintaining library compatibility with an in-house app isn't necessarily just as easy as patching to the most current release, but on the other hand it feels like a lot of containerization is based around pinning at some downrev and potentially vulnerable version of a library because the alternative is too much effort. I suppose the counter-argument is that great, you've exploited your way into the application's container, now what? But the developing situation seems to be that stringing together compromises that used to be too much of a pain in the ass to do by hand are now pretty trivial for the robots, so application exploit to container exploit to OS exploit to bitcoin miner install, baby!
I think like anything else in security, the enterprises with competent IT leadership will be doing everything they can to prevent exploitation via a defense in depth strategy, will require some sort of update cadence even for these legacy software applications to get security stack updates and will provide mitigations to help customers who can't update. Enterprises that lack that level of IT competency in leadership will continue to leave things alone until such a time they get exploited, then it's an all hands on deck scramblefest that sucks for all involved. I don't think containerization ends up helping much if you can find ways to move laterally on the network and just use this php vulnerability as the first link in a chain. It's going to be a pretty miserable time to be on the IT staff of companies that are being reactive, but not proactive.
posted by Fidel Cashflow at 1:37 PM
---------------------------
So today some of the worst people on earth using the most environmentally destructive tools on earth brought down a huge part of the internet by exploiting a potential problem found many years ago in PHP which was previously not practical for anyone to exploit.
Would they prefer it exploited by blackhats instead of disclosed and patched?
posted by BungaDunga at 1:37 PM
---------------------------
the internet is mostly made up of shitty PHP configurations
But wait, I thought it was a series of tubes...?
posted by Greg_Ace at 1:41 PM
---------------------------
> From what I understand, the vulnerability is in the PHP processor itself, so if it's enabled, you are vulnerable even if you don't have a single .php file on your server. Having PHP "Enabled" is a little more difficult to confirm, you'd need to check your web server configuration (the most common ones being Apache and NGINX).
Part of why I'm curious is that the exploit (or one of the exploits) appears to require forcing PHP into certain kinds of execution errors, which to the best of my understanding (again, been a long time since I've had to deal with PHP) can't be done remotely if there are no accessible PHP files.
posted by at by at 1:41 PM
---------------------------
There's an order to these things. FIRST you quietly tell the developers of the thing you've found an exploit in. THEN you work with them to come up with a disclosure timeline. THEN they fix the problem. NEXT they help get the fix into distributions so that everyone can get fixed before they know there's a problem.
FINALLY they publish the exploit, and say "By the way, if you haven't upgraded over the past week, now's the time."
posted by rum-soaked space hobo at 1:41 PM
---------------------------
> There's an order to these things.
That was PHP's intended timeline but somebody leaked the exploit yesterday.
posted by at by at 2:11 PM
---------------------------
Even if there's no leak and you quietly ship a fix without announcing the precise nature of the exploit, anyone who knows there's a bugfix can reverse engineer an exploit with a decent LLM.
posted by BungaDunga at 2:14 PM
---------------------------
Because yeah, it used to be that there was a window between a vulnerability being discovered and actively exploited that remediations could be engineered, patches could be applied, etc, but now with what amounts to automated attack tooling, that buffer basically doesn't exist any more. What can you do to be proactive beyond patching more frequently?
Yeah this is what I meant about changing the calculus around disclosure. But in a world where this kind of automation of vulnerability analysis exists, I'd argue that the people who run the models that are currently the best at it partnering with major software projects/vendors to proactively patch things before the capabilities diffuse to the masses is kind of the only responsible way to handle it? So blaming OpenAI for the impact doesn't make a lot of sense to me. Especially if the "we knew this kind of exploit might be possible in theory but thought it was impractical" framing is correct, though I'm not certain it is, because in that case one ought to behave as if it's a matter of time until somebody figures it out.
posted by atoxyl at 2:15 PM
---------------------------
I assume sufficiently well-resourced blackhats are scanning every unexpected (and expected) patch coming out of big projects to see if they contain patches that they can front-run
posted by BungaDunga at 2:17 PM
---------------------------
There's an order to these things. FIRST you quietly tell the developers of the thing you've found an exploit in. THEN you work with them to come up with a disclosure timeline. THEN they fix the problem. NEXT they help get the fix into distributions so that everyone can get fixed before they know there's a problem.
That was PHP's intended timeline but somebody leaked the exploit yesterday.
Even if there's no leak and you quietly ship a fix without announcing the precise nature of the exploit, anyone who knows there's a bugfix can reverse engineer an exploit with a decent LLM.
I don't know the exact story here but yeah the basic issue is that it used to be that if you published a high level description of a vulnerability or a patch that implicitly identified the problem code, turning that into a practical, repeatable exploit was still a fairly specialized skillset, so you had some time for the patch to get rolled out. But now there is a much lower barrier to brute force it.
posted by atoxyl at 2:22 PM
---------------------------
> But wait, I thought it was a series of tubes...?
Easy to explain: shitty PHP configurations are a type of tube. I hope that helps.
posted by vibratory manner of working at 3:12 PM
---------------------------
My university got hit with this, I imagine, based on the you-can-read-the-panic in the email they sent out - it's the middle of midterms and all the course management software, course content, online exams, etc., are all down, as is off-campus access to the entire university domain including the library. Anyway thank god I retired.
It may be a coincidence but also we are a few days from a provincial election and the official government website for election info, advance voting, etc has been down for hours.
posted by Rumple at 3:30 PM
---------------------------
My mid-sized company is already struggling with this.
The old SLAs were 30-60-90 days, depending on severity, (excepting actively exploited zero-days) and with all the best-practices steps in place:
review the vulnerabilities
prioritize the vulnerabilities
send to the Infrastructure Team who would confirm patches wouldn't break some legacy system,
get the plan into the every-other-week Change Management queue,
then fit proposed patches into allotted patch windows, which sometimes meant pushing some patches out a month.
Then it's download all the patches and validate hashes, and set up job.
Then week 2 apply to Dev and attach report for audit;
Week 3 apply to Pre-Prod, test again, and update CM ticket;
Week 4 patch Production, then spend another week nagging users to really this time, yes just like last month, keep your laptop on, or remediating RDP issues or manually logging onto servers for those handful of patches that have given the server an existential crisis.
Pretty standard set-up. It was busy, but it flowed.
NOW, our windows are days or weeks, not months, and there's talk of moving to twice-a-month patching. Result being EVERY part of this Patching Chain has to be revised, because the *system* is not fast enough to keep up with the need.
Patching was a small part of our Infrastructure Team's workload, but nope - not now. The disruption to all other projects and BAU preventive work is already suffering. We will likely have to hire new Infrastructure people, and I have no idea how we are going to find more "after-hours" nighttime slots not currently taken up by code releases, to ensure we stay up to date on this.
posted by Silvery Fish at 3:41 PM
---------------------------
I had to start early last week due to a Windows patch kicking every one of our laptops off the corporate Wi-Fi, so we had a discussion about slowing down patches for testing. Now there's a conversation about speeding patches up. The Venn diagram of patching safe enough and patching fast enough is two separate circles. A new process will need to be found. A comprehensive mitigation phase involving firewalls, upstream gateway services, and anti-malware solutions will become essential to buy time to make changes safely. Companies will need to release patches along with all the info necessary to rapidly deploy temporary mitigations ahead of the permanent fix, partnering with the major players and not just shoving a patch onto their update servers.
posted by krisjohn at 4:31 PM
---------------------------
apparently the source code changes are not very elegant, something like this:
x = x + 1;
If OUT_OF_MEMORY_ERROR() jumpto OMG_WE_ARE_PWNED
y = x * 42
If OUT_OF_MEMORY_ERROR() jumpto OMG_WE_ARE_PWNED
z = z + 1
If OUT_OF_MEMORY_ERROR() jumpto OMG_WE_ARE_PWNED
I'm exaggerating but only slightly.
Once that was released, there would be no way the black hats wouldn't be all over it looking for exploits.
posted by soylent00FF00 at 4:55 PM
---------------------------
People should've stuck with Perl.
posted by pseudocode at 5:12 PM
---------------------------
PL/I and a bunch of punch cards in a shoebox.
posted by signal at 5:37 PM
---------------------------
These whirlwind patching cycles are needed but can't help wondering that at some point, a bad patch is going to put out there because in the rush a human got left out of a loop. And then all hell will break loose.
posted by storybored at 7:28 PM
---------------------------
PHP has always been not great where security is concerned, and that is a problem made worse when fixes are not applied to older versions, which introduces numerous problems where compiled PHP components intersect with and are tied to narrowly-specific versions of other 3P software (such as database drivers, which are what make PHP actually useful at the end of the day).
It seems like the operations that allow its use and are also serious about security basically give little (or perhaps no) grace at allowing versions with known exploits to run on the company network. Up or out.
That's probably for the greater good because it puts serious pressure not only on the people fixing PHP, but also on the people who have to decide what technology stack to use, who evaluate less vulnerable alternatives.
posted by They sucked his brains out! at 7:29 PM
---------------------------
We're already hearing rumbling from one of our Big Governmental Customers that maybe we'll get 5 days from disclosure to prod patching for critical and KEVs. And nearly everything is a critical these days, so I keep proposing that we should go whole hog on patching each environment every other day, just automate the ever loving heck out of it so dev gets patched on even days and prod gets patched on odd days, you get 24 hours to figure out if an update broke your shit otherwise it's going live.
I mean, it'll certainly grease the wheels for figuring out whatever service dependency hell every environment halfassedly puts up with all along because it's just something they deal with every couple of weeks on a more traditional schedule, right? If you get to come back to work every evening to restart your apps because it comes after the database but before the front end but not until the authentication servers are fully stabilized again well maybe you'll care a bit more won't you Frank.
But that just gets the OS, and we never had a strong mandate for only installing OS supported and maintained libraries, so the apps have the usual hodgepodge of upstream sources, so we'll have to see.
And, again, that's only tolerable-ish for an environment with a strong IT focus. Your local government? Library? Travel agent? Not so much. It would be good eating for MSPs, except the money just isn't there anyway.
Congrats, we solved the Fermi paradox? Early AI knocks out technological development QED no aliens. kiddingnotkidding - it'll probably just be AI red and blue teams boiling the oceans instead
Anyway, yeah, I sort of wonder about an old environment of mine back around the 2010s where most systems only got quarterly patching at best and I'm not entirely convinced the FDA validated ones ever got patched more than annually due to the validation ballache - has validation finally accepted the potential risks, or have they just shoved them behind air gapped mechanical turk API servers or something.
posted by Kyol at 7:35 PM
---------------------------
Thanks for throwing light on that. Wow. That soak window length - it may miss memory leaks, etc and dev better be running prod-level traffic profiles. What about s/w that requires certification? How does that work if there's a critical fault and a patch requires recertification?
posted by storybored at 7:45 PM
---------------------------
Also will need automatic(?) rollback in case spam hits the fan out in the field.
posted by storybored at 7:46 PM
---------------------------
AI self-regulation is going great.
Could the swarms of Agents at least form an orderly line and break one piece of Internet infrastructure at a time?
posted by Hardcore Poser at 8:47 PM
---------------------------
apparently the source code changes are not very elegant
PHP? Not elegant? You astonish me.
posted by flabdablet at 12:11 AM
---------------------------
> There are dozens of orgs for whom spending the resources to develop an exploit would be practical.
The main innovation of the AI industry has been to convince people to stop asking whether expenses are practical.
If it costs $X to develop an exploit to gain some advantage worth $Y to you, then you can weigh the costs against the benefits. And when $X is paid for by loss-leader economics, then you can do whatever you want as long as $Y is positive.
But it seems like vandalism on this scale is a profoundly negative result, except as a demonstration of destructive power.
posted by Phssthpok at 12:54 AM
---------------------------
The PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
PHP calls them a "minimal mitigation for EOL version" (7.4 , 8.0 , 8.1 ). They are much smaller than the fix for the supported versions, and they switch session upload progress off completely, whatever your php.ini says. If your app shows upload progress bars on these versions, they stop working.
posted by Lanark at 1:29 AM
---------------------------
Here's some possible good news. No one has published a practical exploit yet despite the whole world pointing their AIs at the problem.
posted by grahamparks at 3:58 AM
---------------------------
Silvery Fish: "My mid-sized company is already struggling with this. [...]
We will likely have to hire new Infrastructure people, and I have no idea how we are going to find more "after-hours" nighttime slots not currently taken up by code releases, to ensure we stay up to date on this."
Ah, there are the new jobs for everyone being displaced by AI.
What about s/w that requires certification?
It takes days to weeks to get new versions of apps through the assorted app stores certification process. Super annoying for the game I play with cross system support but only if all systems are on the same version. Kinda system breaking if a new exploit goes unpatched because it takes a week to clear the Apple store process.
posted by Mitheral at 4:21 AM
---------------------------
PHP finally had it with all years of snubs and disrespect!
posted by bombilla at 5:36 AM
---------------------------
Between this and the CA thing this week, I am this close to just flinging my laptop into a lake and wandering off to be a goatherd somewhere in the Peak District.
posted by Mr. Bad Example at 6:55 AM
---------------------------
Add this to my near future rpg world building: the ultra rich and the elite hackers run custom OS on custom silicon.
Everyone else is fucked.
posted by small language model at 12:34 PM
---------------------------
No, the ultra rich don't have to use computers at all. They have humans do that stuff for them.
posted by postcommunism at 12:48 PM
---------------------------
At the same time we have the eMudhra Intermediate CA Compromise which is perhaps just as bad? Or worse?
The eMudhra thing looks suspiciously like human incompetence, and some allowance for that has been built-in. And those certs are already dead to any TLS implementation that bothers to check a CRL immediately, and to most-everything with the next browser or OS patch. That's not... great, but it's managed.
(I am sort of looking forward to using the eMudhra certs to MITM crappy IoT devices that try to phone home, and are also too stupid to update their certs. I bet that includes a lot of smart TVs and shit.)
posted by Kadin2048 at 4:45 PM
---------------------------
eMudhra was absolutely human incompetence: in the now-public Bugzilla discussion, they admitted multiple levels of bad judgment starting with deviating from the process in the middle of the key generation ceremony, using untested code which generated a second set of very weak keys, using the wrong key and not checking the name, and then missing a second chance to realize they had made a huge mistake:
The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys.
posted by adamsc at 6:02 PM
---------------------------
Charlie Warzel, on Bluesky (with a gift link to his article in the Atlantic):
70 percent of the internet was vulnerable yesterday to very bad security flaws inside a coding language. Turns out, *one volunteer* is mostly responsible for maintaining that code & helping push updates. Yesterday Ondřej Surý saved the internet. So I called him up
The Atlantic article is here.
posted by adrienneleigh at 10:27 PM
---------------------------
Here's some possible good news. No one has published a practical exploit yet despite the whole world pointing their AIs at the problem.
I think there's a thing with people who share their opinions a lot online where they forget that it's possible to do something not tell people about it. The people who have the skill and interest in doing this are (still!) heavily incentivized to not say anything, so the fact that no one has posted it is not good evidence that it's impossible!
Here is a response. If you don't care to watch the video, it directly contradicts this article in terms of feasibility and specifically shows default server exploitation. The video's producer is reputable.
The original post seems to start from an ideological position on LLMs and then derive an opinion on this bug's exploit feasibility from there, which is at least a little ironic considering the complaints about people not thinking for themselves.
posted by yeahwhatever at 11:14 PM
---------------------------
From the small team that discovered the bug, here's it is in (human) webcomic form.
posted by Markov Polo at 3:13 AM
---------------------------
Regexp compilation fixes related to GitLab's CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264 in the 4.0.9, 3.4.12 and 3.3.13 updates to Ruby, this week's not over yet.
posted by mhoye at 9:04 AM
---------------------------
But I was told the scary computer security warnings from Anthropic et al were just marketing. Or was it that this wouldn't be happening if they just sandboxed correctly? Big if true, right?
posted by jjwiseman at 9:49 AM
---------------------------
But I was told the scary computer security warnings from Anthropic et al were just marketing. Or was it that this wouldn't be happening if they just sandboxed correctly? Big if true, right?
Not "just" marketing, but they absolutely were marketing. Any statement out of a for-profit company about the capabilities of their product is marketing.
My perspective is that there isn't anything inherently paradigm-shifting about the models themselves but the amount of cycles and focus being brought to bear using it to tackle problems. Looking at it another way, if you'd been given a $10Bn budget to go hire engineers and bug-hunt without the aid of any AI tools, they'd turn up vulnerabilities like this--after all, the underlying bug allowing this attack was identified years ago.
It's just becoming cheaper and cheaper to do it with the aid of the tools. A warning to us all that we've not historically had sufficient funding of security research for the public good.
posted by Room 101 at 10:56 AM
---------------------------
But I was told the scary computer security warnings from Anthropic et al were just marketing. Or was it that this wouldn't be happening if they just sandboxed correctly? Big if true, right?
Both of those were true and continue to be, along with the third part: LLMs are great for combining techniques and expanding range. The PHP attacks relied on things humans discovered in 2004 and 2020 but nobody found a way to combine the attacks and get past the earlier safeguards until a well-resourced team including the guy who made that first discovery in 2004 spent a lot of time on an area of code they knew had a history of bugs.
That's not to say that there's nothing here but that it's more like when fuzzers became common and flushed out a bunch of bugs in code which hadn't had that level of attention before. They're not finding novel attacks but they're getting a level of deep attention which used to be more expensive, so you could think of it like how moving from archery to firearms changed a lot of things even though nobody got a death ray.
posted by adamsc at 11:53 AM
---------------------------
Both of those were true and continue to be.
But It's not just marketing, the models have strong software capabilities that make them extremely good at finding vulnerabilities and exploiting them. And this would be happening no matter how well Anthropic and OpenAI sandbox or air-gap their agents during evals, because other people are using the models to find vulnerabilities and exploit them.
Part of why they do the evals in the first place is to determine what capabilities the agents have. They announced in April that Mythos was dangerously good at this stuff. If you were smart, you listened to them and you planned on how you would be responding to the situation we find ourselves in today. If you thought it was just marketing to pump up an imminent IPO or the problem was that they didn't air-gap the models then you were wrong and you wasted 6 months of potential prep time.
posted by jjwiseman at 9:10 PM
---------------------------
Has anybody seen reliable reports of these vulnerabilities actually being maliciously exploited IRL? So far it's all been "widely attacked", "multiple attempts" etc. There are headlines that scream "actively exploited", but when you look at the actual articles they describe exploit attempts, not successful attacks ( example ), and I've yet to come across one that does not follow this pattern. Neither CISA nor the EUVD list the two CVEs as a "known exploited vulnerability" and one guy at the ISC analysed the exploit proof-of-concepts published so far and found them to "have several pre-requirements and are almost cheating" (i.e. they would almost never work under real-world conditions).
It's still early days, and possibly somebody will be able to build a more reliable and general-purpose exploit in time. But it sure is beginning to feel like another AI marketing stunt by the AI startup that published the vulnerability and that the sensationalist publication possibly caused more damage than the real vulnerability ever would have (not that I'm bitter about the overtime or anything).
posted by Incorrection at 6:17 AM
---------------------------
They're not finding novel attacks but they're getting a level of deep attention which used to be more expensive, so you could think of it like how moving from archery to firearms changed a lot of things even though nobody got a death ray.
Yeah but who said it's a death ray? To reuse my other recent comment about AI externalities in a slightly different context
You know the (fake) Stalin line about quantity and quality?
I'm not really sure what the "they're not novel attacks" distinction means. Most things aren't novel attacks, they're, you know, memory safety bugs. If you're waiting for an entirely new category of attack to get concerned you're definitely missing the core point. The immediate concerns raised by LLMs are
a.) the ability to scrutinize everything for vulnerabilities on demand
b.) a new level of script-kiddie-dom as the execution of attacks becomes more autonomous at every stage
Archery to firearms is actually a great analogy for (b). (a) I suppose is guns to machine guns.
posted by atoxyl at 11:01 AM
---------------------------