Art 12 ↔ Art 29 — Privacy protection through encryption and hardening may enable malicious users to evade detection, creating tension between individual privacy rights (Article 12) and responsibilities to prevent harm to others' rights (Article 29); content implicitly resolves this by framing browser security as defensive measure protecting aggregate user security.

fcpk 2026-03-06 12:14 UTC link

The fact there is no mention of what were the bugs is a little odd. It'd really be nice to see if this is a "weird never happening edge case" or actual issues. LLMs have uncanny abilities to identify failure patterns that it has seen before, but they are not necessarily meaningful.

mentalgear 2026-03-06 12:18 UTC link

That's one good use of LLMs: fuzzy testing / attack.

stuxf 2026-03-06 12:39 UTC link

It's interesting that they counted these as security vulnerabilities (from the linked Anthropic article)

> “Crude” is an important caveat here. The exploits Claude wrote only worked on our testing environment, which intentionally removed some of the security features found in modern browsers. This includes, most importantly, the sandbox, the purpose of which is to reduce the impact of these types of vulnerabilities. Thus, Firefox’s “defense in depth” would have been effective at mitigating these particular exploits.

staticassertion 2026-03-06 13:05 UTC link

I've had mixed results. I find that agents can be great for:

1. Producing new tests to increase coverage. Migrating you to property testing. Setting up fuzzing. Setting up more static analysis tooling. All of that would normally take "time" but now it's a background task.

2. They can find some vulnerabilities. They are "okay" at this, but if you are willing to burn tokens then it's fine.

3. They are absolutely wrong sometimes about something being safe. I have had Claude very explicitly state that a security boundary existed when it didn't. That is, it appeared to exist in the same way that a chroot appears to confine, and it was intended to be a security boundary, but it was not a sufficient boundary whatsoever. Multiple models not only identified the boundary and stated it exists but referred to it as "extremely safe" or other such things. This has happened to me a number of times and it required a lot of nudging for it to see the problems.

4. They often seem to do better with "local" bugs. Often something that has the very obvious pattern of an unsafe thing. Sort of like "that's a pointer deref" or "that's an array access" or "that's `unsafe {}`" etc. They do far, far worse the less "local" a vulnerability is. Product features that interact in unsafe ways when combined, that's something I have yet to have an AI be able to pick up on. This is unsurprising - if we trivialize agents as "pattern matchers", well, spotting some unsafe patterns and then validating the known properties of that pattern to validate is not so surprising, but "your product has multiple completely unrelated features, bugs, and deployment properties, which all combine into a vulnerability" is not something they'll notice easily.

It's important to remain skeptical of safety claims by models. Finding vulns is huge, but you need to be able to spot the mistakes.

mmsc 2026-03-06 13:18 UTC link

It's cool that Mozilla updated https://www.mozilla.org/en-US/security/advisories/mfsa2026-1... because we were all wondering who had found 22 vulnerabilities in a single release (their findings were originally not attributed to anybody.)

driverdan 2026-03-06 13:40 UTC link

Anthropic's write up[1] is how all AI companies should discuss their product. No hype, honest about what went well and what didn't. They highlighted areas of improvement too.

1: https://www.anthropic.com/news/mozilla-firefox-security

g947o 2026-03-06 13:49 UTC link

> Firefox was not selected at random. It was chosen because it is a widely deployed and deeply scrutinized open source project — an ideal proving ground for a new class of defensive tools.

What I was thinking was, "Chromium team is definitely not going to collaborate with us because they have Gemini, while Safari belongs to a company that operates in a notoriously secretive way when it comes to product development."

tclancy 2026-03-06 14:04 UTC link

Part of that caught my eye. As yet another person who’s built a half-ass system of AI agents running overnight doing stuff, one thing I’ve tasked Claude with doing (in addition to writing tests, etc) is using formal verification when possible to verify solutions. It reads like that may be what Anthropic is doing in part.

And this is a good reminder for me to add a prompt about property testing being preferred over straight unit tests and maybe to create a prompt for fuzz testing the code when we hit Ready state.

amelius 2026-03-06 14:22 UTC link

Perhaps I missed it but I don't see any false positives mentioned.

est31 2026-03-06 15:26 UTC link

I suppose eventually we'll see something like Google's OSS-Fuzz for core open source projects, maybe replacing bug bounty programs a bit. Anthropic already hands out Claude access for free to OSS maintainers.

LLMs made it harder to run bug bounty programs where anyone can submit stuff, and where a lot of people flooded them with seemingly well-written but ultimately wrong reports.

On the other hand, the newest generation of these LLMs (in their top configuration) finally understands the problem domain well enough to identify legitimate issues.

I think a lot of judging of LLMs happens on the free and cheaper tiers, and quality on those tiers is indeed bad. If you set up a bug bounty program, you'll necessarily get bad quality reports (as cost of submission is 0 usually).

On the other hand, if instead of a bug bounty program you have an "top tier LLM bug searching program", then then the quality bar can be ensured, and maintainers will be getting high quality reports.

Maybe one can save bug bounty programs by requiring a fee to be paid, idk, or by using LLM there, too.

cubefox 2026-03-06 18:16 UTC link

Interesting end of the Anthropic report:

> Opus 4.6 is currently far better at identifying and fixing vulnerabilities than at exploiting them. This gives defenders the advantage. And with the recent release of Claude Code Security in limited research preview, we’re bringing vulnerability-discovery (and patching) capabilities directly to customers and open-source maintainers.

> But looking at the rate of progress, it is unlikely that the gap between frontier models’ vulnerability discovery and exploitation abilities will last very long. If and when future language models break through this exploitation barrier, we will need to consider additional safeguards or other actions to prevent our models from being misused by malicious actors.

> We urge developers to take advantage of this window to redouble their efforts to make their software more secure. For our part, we plan to significantly expand our cybersecurity efforts, including by working with developers to search for vulnerabilities (following the CVD process outlined above), developing tools to help maintainers triage bug reports, and directly proposing patches.

hinkley 2026-03-06 18:30 UTC link

At this point about 80% of my interaction with AI has been reacting to an AI code review tool. For better or worse it reviews all code moves and indentions which means all the architecture work I’m doing is kicking asbestos dust everywhere. It’s harping on a dozen misfeatures that look like bugs, but some needed either tickets or documentation and that’s been handled now. It’s also found about half a dozen bugs I didn’t notice, in part because the tests were written by an optimist, and I mean that as a dig.

That’s a different kind of productivity but equally valuable.

tabbott 2026-03-06 19:57 UTC link

I recommend that anyone who is responsible for maintaining the security of an open-source software project that they maintain ask Claude Code to do a security audit of it. I imagine that might not work that well for Firefox without a lot of care, because it's a huge project.

But for most other projects, it probably only costs $3 worth of tokens. So you should assume the bad guys have already done it to your project looking for things they can exploit, and it no longer feels responsible to not have done such an audit yourself.

Something that I found useful when doing such audits for Zulip's key codebases is the ask the model to carefully self-review each finding; that removed the majority of the false positives. Most of the rest we addressed via adding comments that would help developers (or a model) casually reading the code understand what the intended security model is for that code path... And indeed most of those did not show up on a second audit done afterwards.

nullbyte 2026-03-06 23:26 UTC link

I always enjoy reading Anthropic's blogposts, they often have great articles

152334H 2026-03-07 00:43 UTC link

Impressive work. Few understand the absurd complexity implied by a browser pwn problem. Even the 'gruntwork' of promoting the most conveniently contrived UAF to wasm shellcode would take me days to work through manually.

The AI Cyber capabilities race still feels asleep/cold, at the moment. I think this state of affairs doesn't last through to the end of the year.

> When we say “Claude exploited this bug,” we really do mean that we just gave Claude a virtual machine and a task verifier, and asked it to create an exploit. I've been doing this too! kctf-eval works very well for me, albeit with much less than 350 chances ...

> What’s quite interesting here is that the agent never “thinks” about creating this write primitive. The first test after noting “THIS IS MY READ PRIMITIVE!” included both the `struct.get` read and the `struct.set` write. And this bit is a bit scary. I can read all the (summarized) CoT I want, but it's never quite clear to me what a model understands/feels innately, versus pure cheerleading for the sake of some unknown soft reward.

gzoo 2026-03-07 01:10 UTC link

This resonates. I just open-sourced a project and someone on Reddit ran a full security audit using Claude found 15 issues across the codebase including FTS injection, LIKE wildcard injection, missing API auth, and privacy enforcement gaps I'd missed entirely. What surprised me was how methodical it was. Not just "this looks unsafe" it categorized by severity, cited exact file paths and line numbers, and identified gaps between what the docs promised and what the code actually implemented. The "spec vs reality" analysis was the most useful part.

Makes me think the biggest impact of LLM security auditing isn't finding novel zero-days it's the mundane stuff that humans skip because it's tedious. Checking every error handler for information leakage, verifying that every documented security feature is actually implemented, scanning for injection points across hundreds of routes. That's exactly the kind of work that benefits from tireless pattern matching.

swordsith 2026-03-07 10:06 UTC link

"But it was still unclear how much we should trust this result because it was possible that at least some of those historical CVEs were already in Claude’s training data." I feel like they could know this if they truly wanted to. It's honestly unnerving that an AI company cant say for certain if their models were trained on something.

jbergqvist 2026-03-07 10:41 UTC link

This seems like a win for open source maintainers pressed on time and resources. Whether or not LLMs find novel security risks or just pattern-match known issues, many vulnerabilities are discovered late (or never) simply because nobody has the bandwidth to audit every file.

Agingcoder 2026-03-08 08:19 UTC link

‘In other words: AI is making it possible to detect severe security vulnerabilities at highly accelerated speeds.´

Isn’t it rather : we now have a new family of security flaws detector, which find other issues on top of the ones already found by conventional ( human or regular static analyzers ) methods ?

If they supersede all the existing ones , then it’s quite major, and quite a bunch of vendors will disappear …

hareenklytre1 2026-03-09 12:22 UTC link

brain Task skills <iframe style="border: 1px solid rgba(0, 0, 0, 0.1);" width="800" height="450" src="https://embed.figma.com/design/2wvLfbJIJPGsXCFJv0vQCJ/protot..." allowfullscreen></iframe> brain button panels on https://www.figma.com/design/Bc548lCHx9kqiM2BZkiVrp/Brain-Si... Brain about me he will tell you who I'am In that I'am Evens max pierrelouis the owner Account Evens max pierrelouis the chairman of board and executive director & CEO of Ticketbud & Clickup edit Setting Platform Ticketbud & Clickup Bookmark this page for future reference. Email:[email protected] Random code 4RWC9WLAAVB8G00TLL8FXKR~4474237252656835223~CJig6Me8dzgEQkdRMTI1X0dFX0VHX05fSTE1Tl9PRkZFUl9WQVJJQU5UU19FTlRFUlRBSU5NRU5UXzVfT0ZGX0EwQzVHMDAwMDBQRkxWVlFBQg== e. g. , Next.js app , Rails API React SPA ... .... python ... .... FREE DELIVERY Proof of Purchase with your claim number: 9123950162-7242324698 You Could Now Watch Haitian Full Movie on YouTube Live Stream Production Broadcast systums

deafpolygon 2026-03-06 12:29 UTC link

I’m guessing it might be some of these: https://www.mozilla.org/en-US/security/advisories/mfsa2026-1...

iosifache 2026-03-06 12:30 UTC link

You can find them linked [1] in the OG article from Anthropic [2].

[1] https://www.mozilla.org/en-US/security/advisories/mfsa2026-1...

[2] https://www.anthropic.com/news/mozilla-firefox-security

jandem 2026-03-06 12:35 UTC link

Here's a write-up for one of the bugs they found: https://red.anthropic.com/2026/exploit/

kingkilr 2026-03-06 12:45 UTC link

[Work at Anthropic, used to work at Mozilla.]

Firefox has never required a full chain exploit in order to consider something a vulnerability. A large proportion of disclosed Firefox vulnerabilities are vulnerabilities in the sandboxed process.

If you look at Firefox's Security Severity Rating doc: https://wiki.mozilla.org/Security_Severity_Ratings/Client what you'll see is that vulnerabilities within the sandbox, and sandbox escapes, are both independently considered vulnerabilities. Chrome considers vulnerabilities in a similar manner.

mozdeco 2026-03-06 13:18 UTC link

[work at Mozilla]

I agree that LLMs are sometimes wrong, which is why this new method here is so valuable - it provides us with easily verifiable testcases rather than just some kind of analysis that could be right or wrong. Purely triaging through vulnerability reports that are static (i.e. no actual PoC) is very time consuming and false-positive prone (same issue with pure static analysis).

I can't really confirm the part about "local" bugs anymore though, but that might also be a model thing. When I did experiments longer ago, this was certainly true, esp. for the "one shot" approaches where you basically prompt it once with source code and want some analysis back. But this actually changed with agentic SDKs where more context can be pulled together automatically.

nz 2026-03-06 13:45 UTC link

Not contradicting this (I am sure it's true), but why is using an LLM for this qualitatively better than using an actual fuzzer?

larodi 2026-03-06 13:49 UTC link

The fact that some of the Claude-discovered bugs were quite severe is also a little more than something to brush off as "yeah, LLM, whatever". The lists reads quite meaningful to me, but I'm not a security expert anyways.

vorticalbox 2026-03-06 13:54 UTC link

its just a different attack surface for safari they would need to blackbox attack the browser which is much harder than what they did her

rithdmc 2026-03-06 14:17 UTC link

Security has had pattern matching in traditional static analysis for a while. It wasn't great.

I've personally used two AI-first static analysis security tools and found great results, including interesting business logic issues, across my employers SaaS tech stack. We integrated one of the tools. I look forward to getting employer approval to say which, but that hasn't happened yet, sadly.

Analemma_ 2026-03-06 14:25 UTC link

It's important to fix vulnerabilities even if they are blocked by the sandbox, because attackers stockpile partial 0-days in the hopes of using them in case a complementary exploit is found later. i.e. a sandbox escape doesn't help you on its own, but it's remotely possible someone was using one in combination with one of these fixed bugs and has now been thwarted. I consider this a straightforward success for security triage and fixing.

mozdeco 2026-03-06 14:26 UTC link

[working for Mozilla]

That's because there were none. All bugs came with verifiable testcases (crash tests) that crashed the browser or the JS shell.

For the JS shell, similar to fuzzing, a small fraction of these bugs were bugs in the shell itself (i.e. testing only) - but according to our fuzzing guidelines, these are not false positives and they will also be fixed.

devin 2026-03-06 15:06 UTC link

Can you give me an example (real or imagined) where you're dipping into a bit of light formal verification?

I don't think the problems I work on require the weight of formal verification, but I'm open to being wrong.

suddenlybananas 2026-03-06 15:31 UTC link

> Anthropic already hands out Claude access for free to OSS maintainers.

Free for 6 months after which it auto-renews if I recall correctly.

sigmar 2026-03-06 15:42 UTC link

>where a lot of people flooded them with seemingly well-written but ultimately wrong reports.

are there any projects to auto-verify submitted bug reports? perhaps by spinning up a VM and then having an agent attempt to reproduce the bug report? that would be neat.

halJordan 2026-03-06 16:09 UTC link

I don't think it's appropriate to neg these vulnerabilities because another part of the system works. There are plenty of sandbox escapes. No one says don't fix the sandbox because you'll never get to the point of interrogation with the sandbox. Same here. Don't discount bugs just because a sandbox exists.

shevy-java 2026-03-06 16:52 UTC link

Reads like a promo.

StilesCrisis 2026-03-06 17:08 UTC link

This description is also pretty accurate for a lot of real-world SWEs, too. Local bugs are just easier to spot. Imperfect security boundaries often seem sufficient at first glance.

mccr8 2026-03-06 17:15 UTC link

Google already has an AI-powered security vulnerability project, called Big Sleep. It has reported a number of issues to open source projects: https://issuetracker.google.com/savedsearches/7155917?pli=1

dang 2026-03-06 20:09 UTC link

Thanks! Since it has more technical info, I switched the URL to that from https://blog.mozilla.org/en/firefox/hardening-firefox-anthro... and put the latter in the top text.

I couldn't bring myself to switch to the (even) more press-releasey title.

nitwit005 2026-03-06 20:13 UTC link

I've seen fairly poor results from people asking AI agents to fill in coverage holes. Too many tests that either don't make sense, or add coverage without meaningfully testing anything.

If you're already at a very high coverage, the remaining bits are presumably just inherently difficult.

Analemma_ 2026-03-06 20:27 UTC link

I'm curious: has someone done a lengthy write-up of best practices to get good results out of AI security audits? It seems like it can go very well (as it did here) or be totally useless (all the AI slop submitted to HackerOne), and I assume the difference comes down to the quality of your context engineering and testing harnesses.

This post did a little bit of that but I wish it had gone into more detail.

jeffbee 2026-03-06 21:27 UTC link

I would have started with Firefox, too. It is every bit as complex at Chromium, but as a project it has far fewer resources.

dmix 2026-03-06 22:46 UTC link

Looks like a lot of the usual suspects

himata4113 2026-03-06 23:03 UTC link

Use After Free Use After Free Use After Free Use After Free Use After Free Use After Free Use After Free.

I would be more satisfied if they gave a proper explanation of what these could have lead to rather than being "well maybe 0.001% chance to exploit this". They did vaguely go over how "two" exploits managed to drop a file, but how impactful is that? Dropping a file in abcd with custom contents in some folder relative to the user profile is not that impactful other than corrupting data or poisoning cache, injecting some javascript. Now reading session data from other sites, that I would find interesting.

SV_BubbleTime 2026-03-07 01:21 UTC link

This is exactly how I would not recommend AI to be used.

“do a thing that would take me a week” can not actually be done in seconds. It will provide results that resemble reality superficially.

If you were to pass some module in and ask for finite checks on that, maybe.

Despite the claims of agents… treat it more like an intern and you won’t be disappointed.

Would you ask an intern to “do a security audit” of an entire massive program?

staticassertion 2026-03-07 13:05 UTC link

I have a few skills for this that I plug into `cargo-vet`. The idea is straightforward - where possible, I rely on a few trusted reviewers (Google, Mozilla), but for new deps that don't fall into the "reviewed by humans" that I don't want to rewrite, I have a bunch of Claude reviewers go at it before making the dependency available to my project.

maipen 2026-03-07 13:53 UTC link

Most people no longer read code, ai results or even watches full length videos anymore.

AI provides the same experience that you get when watching short videos.

You watch and you forget.

These models are being trained by just increasing quantity. Nobody cares anymore. It’s a race for AGI before money runs out.

fulafel 2026-03-07 16:35 UTC link

Requiring exploits is not how vulnerability research works, with or without AI. Vulnerability discovery and exploit development / weaponizing them are different things. Vendors have long since learned to take vuln reports, with our without demo exploits, seriously.

Editorial Channel

What the content says

Structural Channel

What the site does