4 ms·

I was a bit confused by your definitions, but here's how Mozilla broke out [1] the 271, um, things: > As additional context, we apply security severity ratings

I was a bit confused by your definitions, but here's how Mozilla broke out [1] the 271, um, things: > As additional context, we apply security severity ratings from critical to low to indicate the urgency of a bug: > * sec-critical and sec-high are assigned to vulnerabilities that can be triggered with normal user behavior, like browsing to a web page. We make no technical difference between these, but sec-critical bugs are reserved for issues that are publicly disclosed or known to be exploited in the wild. > * sec-moderate is assigned to vulnerabilities that would otherwise be rated sec-high but require unusual and complex steps from the victim. > * sec-low is assigned to bugs that are annoying but far from causing user harm (e.g, a safe crash). > Of the 271 bugs we announced for Firefox 150: 180 were sec-high, 80 were sec-moderate, and 11 were sec-low. Mozilla uses the term "vulnerability" for even sec-high, even though they say right below that it doesn't mean the same thing as a practical exploit. And on their definitional page, they classify even sec-low as "vulnerabilities" [2]. Words are tools, that get their utility from collective meaning. I'd be interested where you recieved your semantics from and if they match up or disagree with Mozilla. [1] https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/ https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin... [2] https://wiki.mozilla.org/Security_Severity_Ratings/Client https://wiki.mozilla.org/Security_Severity_Ratings/Client

Gregaros 6mo ago
> Mozilla uses the term "vulnerability" for even sec-high, even though they say right below that it doesn't mean the same thing as a practical exploit. That’s not evident in what you pastedat all. What you pasted says > sec-critical and sec-high are assigned to vulnerabilities that can be triggered with normal user behavior […] We make no technical difference between these […] sec-critical bugs are reserved for issues that are publicly disclosed or known to be exploited in the wild. > sec-low is assigned to bugs that are annoying but far from causing user harm (e.g, a safe crash). From this one infers that the "180 were sec-high" bugs found are actually exploitsble but known to have been found in the wild, and are NOT mere annoying bugs. The difference between 180 and 270 does nothing to deflate the signicance, or lack there of, of the implication re: Mythos.
- epistasis 6mo ago
  Yes, it is not in what I pasted, as I said, "even though they say right below". If you don't believe me then click on either of the links.
throw0101c 6mo ago
Presumably there are (implicit?) "sec-none" things, like [a] from the recently released 150.0.2 [b] which makes absolutely zero mention about "Security Impact" or "Severity" in the bug report, unlike [c], which is listed in the Mozilla weblog post [2]. Security things are mentioned in the Release Notes [b] pointing to a completely different document [d]. Perhaps sometimes a bug is 'just' a bug, and not a vulnerability. [a] https://bugzilla.mozilla.org/show_bug.cgi?id=2034980 https://bugzilla.mozilla.org/show_bug.cgi?id=2034980 ; "Can't highlight image scans in Firefox 150+" [b] https://www.firefox.com/en-CA/firefox/150.0.2/releasenotes/ https://www.firefox.com/en-CA/firefox/150.0.2/releasenotes/ [c] https://bugzilla.mozilla.org/show_bug.cgi?id=2024918 https://bugzilla.mozilla.org/show_bug.cgi?id=2024918 [d] https://www.mozilla.org/en-US/security/advisories/mfsa2026-40/ https://www.mozilla.org/en-US/security/advisories/mfsa2026-4...
IainIreland 6mo ago
I work at Mozilla; I fixed a bunch of these bugs. In general, I would say that our use of "vulnerability" lines up with what jerrythegerbil calls "potential vulnerability". (In cases with a POC, we would likely use the word "exploit".) Our goal is to keep Firefox secure. Once it's clear that a particular bug might be exploitable, it's usually not worth a lot of engineering effort to investigate further; we just fix it. We spend a little while eyeballing things for the purpose of sorting into sec-high, sec-moderate, etc, and to help triage incoming bugs, but if there's any real question, we assume the worst and move on. So were all 271 bugs exploitable? Absolutely not. But they were all security bugs according to the normal standards that we've been applying for years. (Partial exception: there were some bugs that might normally have been opened up, but were kept hidden because Mythos wasn't public information yet. But those bugs would have been marked sec-other, and not included in the count.) So if you think we're guilty of inflating the number of "real" vulnerabilities found by Mythos, bear in mind that we've also been consistently inflating the baseline. The spike in the Firefox Security Fixes by Month graph is very, very real: https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/ https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
- epistasis 6mo ago
  I'm not a security dev or researcher or anything, but as an outsider my understanding matches how Mozilla uses the terms. Though words used by specialists and the general public can offer differ...
- paulvnickerson 6mo ago
  What types of vulnerabilities was it finding? Cross site scripting, privilege escalation, etc? Mostly memory corruption or any Javascript logic bugs?
  - IainIreland 6mo ago
    I work on SpiderMonkey, so I mostly looked at the JS bugs. It was a smorgasbord of various things. Broadly speaking I'd say the most impressive bugs were TOCTOU issues, where we checked something and later acted on it, and the testcase found a clever way to invalidate the result of the check in between. If you look closely at, say, this patch, you might get a sense of what I mean (although the real cleverness is in the testcase, which we have not made public): https://hg-edge.mozilla.org/integration/autoland/rev/c29515d5f859 https://hg-edge.mozilla.org/integration/autoland/rev/c29515d...

Gregaros 6mo ago

> Mozilla uses the term "vulnerability" for even sec-high, even though they say right below that it doesn't mean the same thing as a practical exploit. That’s not evident in what you pastedat all. What you pasted says > sec-critical and sec-high are assigned to vulnerabilities that can be triggered with normal user behavior […] We make no technical difference between these […] sec-critical bugs are reserved for issues that are publicly disclosed or known to be exploited in the wild. > sec-low is assigned to bugs that are annoying but far from causing user harm (e.g, a safe crash). From this one infers that the "180 were sec-high" bugs found are actually exploitsble but known to have been found in the wild, and are NOT mere annoying bugs. The difference between 180 and 270 does nothing to deflate the signicance, or lack there of, of the implication re: Mythos.

epistasis 6mo ago
Yes, it is not in what I pasted, as I said, "even though they say right below". If you don't believe me then click on either of the links.

throw0101c 6mo ago

Presumably there are (implicit?) "sec-none" things, like [a] from the recently released 150.0.2 [b] which makes absolutely zero mention about "Security Impact" or "Severity" in the bug report, unlike [c], which is listed in the Mozilla weblog post [2]. Security things are mentioned in the Release Notes [b] pointing to a completely different document [d]. Perhaps sometimes a bug is 'just' a bug, and not a vulnerability. [a] https://bugzilla.mozilla.org/show_bug.cgi?id=2034980 https://bugzilla.mozilla.org/show_bug.cgi?id=2034980 ; "Can't highlight image scans in Firefox 150+" [b] https://www.firefox.com/en-CA/firefox/150.0.2/releasenotes/ https://www.firefox.com/en-CA/firefox/150.0.2/releasenotes/ [c] https://bugzilla.mozilla.org/show_bug.cgi?id=2024918 https://bugzilla.mozilla.org/show_bug.cgi?id=2024918 [d] https://www.mozilla.org/en-US/security/advisories/mfsa2026-40/ https://www.mozilla.org/en-US/security/advisories/mfsa2026-4...

IainIreland 6mo ago

I work at Mozilla; I fixed a bunch of these bugs. In general, I would say that our use of "vulnerability" lines up with what jerrythegerbil calls "potential vulnerability". (In cases with a POC, we would likely use the word "exploit".) Our goal is to keep Firefox secure. Once it's clear that a particular bug might be exploitable, it's usually not worth a lot of engineering effort to investigate further; we just fix it. We spend a little while eyeballing things for the purpose of sorting into sec-high, sec-moderate, etc, and to help triage incoming bugs, but if there's any real question, we assume the worst and move on. So were all 271 bugs exploitable? Absolutely not. But they were all security bugs according to the normal standards that we've been applying for years. (Partial exception: there were some bugs that might normally have been opened up, but were kept hidden because Mythos wasn't public information yet. But those bugs would have been marked sec-other, and not included in the count.) So if you think we're guilty of inflating the number of "real" vulnerabilities found by Mythos, bear in mind that we've also been consistently inflating the baseline. The spike in the Firefox Security Fixes by Month graph is very, very real: https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/ https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...

epistasis 6mo ago
I'm not a security dev or researcher or anything, but as an outsider my understanding matches how Mozilla uses the terms. Though words used by specialists and the general public can offer differ...
paulvnickerson 6mo ago
What types of vulnerabilities was it finding? Cross site scripting, privilege escalation, etc? Mostly memory corruption or any Javascript logic bugs?
- IainIreland 6mo ago
  I work on SpiderMonkey, so I mostly looked at the JS bugs. It was a smorgasbord of various things. Broadly speaking I'd say the most impressive bugs were TOCTOU issues, where we checked something and later acted on it, and the testcase found a clever way to invalidate the result of the check in between. If you look closely at, say, this patch, you might get a sense of what I mean (although the real cleverness is in the testcase, which we have not made public): https://hg-edge.mozilla.org/integration/autoland/rev/c29515d5f859 https://hg-edge.mozilla.org/integration/autoland/rev/c29515d...