Firefox’s 271 AI-found bugs: counts, CVEs and severity explained

Mozilla’s April 2026 announcement that Claude Mythos Preview helped identify 271 Firefox vulnerabilities is a finding about a particular security-review effort. It is not a count of attacks against users, a list of 271 separate CVE identifiers or proof that all those bugs have the same severity.

The distinction became clearer in Mozilla’s May 7 technical follow-up. This historical explanation uses that clarification to correct the earlier article’s “zero-days” framing and unsupported operational predictions. Firefox 150 is the release discussed in these dated sources, not a recommendation to install that old version today.

The report concerned discovery and fixes

Kyle Orland’s April 21 Ars Technica report describes Mozilla’s use of an early Mythos Preview model to analyse Firefox code and identify vulnerabilities before release. It reports leadership’s assessment of the model and compares the result with an earlier exercise using Opus 4.6. Those attributed assessments are not a controlled comparison of every security-research method.

Ars also noted that the initial announcement did not give a detailed severity breakdown. The old article filled that gap with an unsupported reassurance about many issues being low or medium severity and predictions about future patch waves. Neither followed from the information available in that account.

The May follow-up supplies a more specific basis for interpretation. It describes findings, internal rollups and fixes across releases as different categories. A reader needs to identify the category before comparing its count with another headline number.

Why three CVE rollups can contain hundreds of bugs

Mozilla’s clarification lists three internal Firefox 150 rollups: CVE-2026-6784 with 154 bugs, CVE-2026-6785 with 55 and CVE-2026-6786 with 107. The sum is 316. It separately reports 271 Mythos findings in Firefox 150 and 423 security bugs fixed across April releases, including 41 externally reported bugs and 111 other internal findings.

The arithmetic reconciles the monthly total: 271 + 41 + 111 = 423. It does not equate the three rollups with the Mythos-only group. A release bucket, a discovery-method bucket and a calendar-month bucket need not contain the same entries.

This is a general counting problem with a concrete example. Before drawing a conclusion from a discrepancy, write down the unit and inclusion rule for each number. “CVE identifiers,” “underlying bugs,” “findings from one model” and “fixes shipped during a month” are different units or scopes. Mixing them can create a contradiction that the original data does not contain.

The severity breakdown changes the interpretation

Mozilla’s May account classifies the 271 as 180 high, 80 moderate and 11 low severity. Those figures sum to 271. Calculated from them, the shares are approximately 66.4 percent high, 29.5 percent moderate and 4.1 percent low. High severity is therefore the majority in this group; the earlier reassurance about low and medium issues was misleading.

Severity is still not a tally of successful attacks. Mozilla explains that high-rated bugs are not necessarily complete practical exploits and that compromising the browser can require chaining vulnerabilities across defensive layers. A list of serious flaws should not be minimized, but neither should it be relabelled as a list of observed compromises.

The percentages are calculations from Mozilla’s counts, not a new measurement of exploitation likelihood. They cannot establish a user's individual risk, predict which bug an attacker would choose or compare Firefox with a browser assessed under a different process.

A small evidence table prevents larger claims

For each claim, record five fields: source date, software/release scope, counting unit, discovery attribution and what outcome was actually established. The 271 entry belongs under model-assisted findings associated with a particular release. The 423 entry belongs under bugs fixed across a specified month.

Add an exploitation field only when the source provides exploitation evidence. An empty field means the reviewed statement does not answer that question; it does not prove that exploitation is impossible. Likewise, do not infer a vulnerability's presence in every ESR branch from a statement about Firefox 150.

This proposed table supplies a way to compare announcements without inventing a fleet-wide remediation schedule. Branch applicability and current fixed versions belong in current vendor advisories for the exact product, not in extrapolations from a six-month-old headline.

What remains useful beyond the headline

The case demonstrates why discovery, classification, repair and deployment should be reported separately. A dramatic discovery count can hide important work between producing a suspected finding and delivering a usable fix. It can also distract from whether two published numbers describe the same set.

The earlier article’s arbitrary disclosure deadlines, enterprise rollout promises and suggested feature disabling were not established by its source and have been removed. The dependable conclusion is narrower: Mozilla published a substantial model-assisted finding count and later gave details that make its units and severity distribution interpretable.

Sources

Mozilla’s May 7 technical clarification: https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/

Dated Firefox 150 security advisory: https://www.mozilla.org/en-US/security/advisories/mfsa2026-30/

Original report: https://arstechnica.com/ai/2026/04/mozilla-anthropics-mythos-found-271-zero-day-vulnerabilities-in-firefox-150/