Post · bonfire.cafe

I'm a little concerned about the general tech attitude towards the Mozilla bug findings. Yes, I'm an AI hater, so add that to the biases, but that's not really the point here.

People seem excited about the fact that Mythos was used to find a bunch of security bugs in Firefox, which is cool:

https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/

However, the general attitude seems to be that devs can keep pushing for more new things because some AI system will catch the bugs for them. But to me, there should be more concern about how there were so many previously unknown unfixed bugs in Firefox to begin with. These findings should be a cause for concern and give pause to evaluate how so many security bugs make it to prod. And I'm not just talking about Firefox, everyone should be learning from each other in this space.

If nothing else, people celebrating the LLM-fueled bug findings should be recognizing just how much harm the whole Move Fast and Break Shit approach really creates rather than allowing the LLMs to be the excuse to move faster and break more shit.

Mozilla Hacks – the Web developer blog

Behind the Scenes Hardening Firefox with Claude Mythos Preview

New details about what we found, and how agentic harnesses are now able to reproduce real bugs and dismiss false positives.

David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall@infosec.exchange · 2 hours ago

@cR0w Browsers are a bit interesting in terms of defining what actually is a security vulnerability. A modern browser's job is to download untrusted code from probably malicious people, run it, and not let them gain access to the host system. As a result, browsers (Firefox was late to the party by a very long time here, but they've done some very interesting work recently in this space) are some of the most aggressively compartmentalised software that exists. This means that most vulnerabilities in a browser are not exploitable by themselves, you need to chain a bunch of them together.

I suspect there's some psychological effect here, that when you're writing code that you know runs sandboxed, you aren't quite as careful as you would normally be. But there's also a real effect that a lot of the vulnerabilities matter only as step 1 in a chain of several to get to any real kind of compromise that a user would care about.

cR0w h0 h0

@cR0w@infosec.exchange · 2 hours ago

@david_chisnall That's fair, but to my point, it seems like if there is awareness of that whole idea that the main issue is dev attitude, finding out that a bunch of vulns made it to prod seems like the perfect opportunity to address that rather than just be happy there's a new bug finder that will very quickly hit a wall in its effectiveness.

David Chisnall (*Now with 50% more sarcasm!*)

@david_chisnall@infosec.exchange · 2 hours ago

@cR0w For comparison, Chromium averages one vulnerability every 1.5 days. The Linux kernel is similar.

So, yes, I think this is a problem, but it's far from specific to Firefox. Most programming practices came from a time when most software never operated on untrusted data. People are still taught to program as if that were true today.

cR0w h0 h0

@cR0w@infosec.exchange · 2 hours ago

@david_chisnall Oh I don't mean to imply it's a Firefox-specific issue. Firefox happened to be the one in the article but it absolutely should be an example for all projects to take a step back and reevaluate rather than keep pushing forward and hoping the AI saves them. I don't know the internal discussions around Firefox but the way it's been portrayed in the articles I've read has been that devs can now lean harder on LLMs finding their bugs after the fact rather than preventing them in the first place.