Forbes: Lazy Vulnerability Reporting & A Bit of Bias

It may have been almost two decades ago, I joked with colleagues that many Information Security news articles could just be done via Mad Libs. We later joked that breach notifications often appeared to be done via Mad Libs, using the same phrases with different organization names and the number of affected customers. Over the last few years, it seems Forbes has gotten lazy in their reporting on computer vulnerabilities.

First, a bit of background by querying Risk Based Security’s VulnDB, which I work on. While we track news articles on vulnerabilities, it is important to note that it is done in a best faith effort. We try to capture higher profile articles in the bigger publications within InfoSec and those outside the proverbial “echo chamber”, which includes Forbes, New York Times, Washington Post, Fox, etc. So by no means is this comprehensive, but it is important to understand the methodology which is using Google Alerts based on “CVE” strings. This started several years ago, maybe around 2015 give or take. Articles included before that were as they came across social media, referenced in modern disclosures, or some other current manner despite the publication date.

The first Forbes article we have associated goes back to June 17, 2001, covering a vulnerability in a GE Healthcare device. Up to 2010, almost every Forbes article we have is in a GE device along with one about Oracle and one about Linux Kernel. That alone is kind of interesting. From 2010 to 2020 we have Forbes articles covering a wide variety of vendors including Google, Onity, GE, Apple, Magento, PLX, and more. They also included articles covering big disclosures that covered multiple vendors of DVR systems, SIM cards, micro processors, and more. Last year, in 2020, Forbes produces a steady stream of articles for all the big vendors including Cisco, Microsoft, Apple, Google, Intel, Citrix, Zoom, and more.

This year though, it seems like Forbes got lazy. Perhaps it is burnout writing what is essentially the same article? You might think that, but no, because that is exactly what they started doing. Coverage is heavily based around Google Chrome and components in it, but disclosed via Google Chrome’s blog. Of the 48 vulnerabilities in 2021 cataloged by VulnDB, that have an associated Forbes article, only 12 are in non-Chrome products. What’s the gist of their coverage? Here’s three examples, see if you notice the similarities.

You may see the common phrase, “2 Billion Chrome Users”. Don’t worry, in a recent article that got increased to 2.6 billion! If it isn’t in the headline, you can find the phrase in almost every article talking about Chrome vulnerabilities. I get that these articles are repetitive, because there are only so many ways you can say Google fixed vulnerabilities in their browser.

That said, what’s more interesting to me is that they appear to have a single similar article for Mozilla Firefox vulnerabilities in all their time while continuing to encourage users to ditch Chrome. If I didn’t know better, I might think Forbes has chosen a side in the browser wars.

The Great (belated) Mozilla Firefox CVE Dump

[This was originally published on RiskBasedSecurity.com.]


On June 11th, MITRE published descriptions and references for 318 entries, all  relating to Mozilla Firefox. Yes; three hundred and eighteen entries. It may be tempting to think Mozilla was holding back on disclosures or there was a flurry of research activity leading to a slew of new vulnerabilities being discovered. But no, this would not be the case. These disclosures are an example of what happens when a backlog of reserved CVE IDs are finally processed and published. In fact, some of these CVE IDs have been reserved for as long as 4 years, with two issues tied to third-party library vulnerabilities that have been known since 2011. 

This means that for the last two years or more, CVE has had no public details on any Mozilla Firefox vulnerabilities, despite these issues being made public on Mozilla’s web site with each new release of Firefox. Any company relying solely on CVE for vulnerability intelligence on Firefox simply did not have it.

Among the Firefox vulnerabilities were over a dozen issues from the third-party libraries used by Firefox and Thunderbird. The culprits include:

  • Google Skia (4)
  • ANGLE (3)
  • Graphite (2)
  • Cairo
  • Expat
  • HarfBuzz
  • Hyphen
  • Libvpx
  • Libvorbis / libtremor
  • Freetype

While not exactly household names, these libraries are used in a wide variety of well-known products including Android, Samsung devices, Google Pixel devices, VM Server, Pivotal Application Service, XEROX printers, IBM Scale Out Network Attached Storage (SONAS), IBM PowerKVM, Micro Focus iPrint Appliances, AlienVault OSSIM, AlienVault USM, Symantec SSL Visibility, Python, Apple iOS, and macOS / Mac OS X.

To put the Firefox vulnerabilities included in the CVE dump into better perspective, we refer to VulnDB’s VTEM (Vulnerability Timeline and Exposure Metrics). Looking at Firefox, and narrowing the disclosure history to 2016 – 2018, it paints a more complete picture of what their vulnerability history actually looks like. The first thing to jump out is that we track 890 vulnerabilities vs the ~ 300 CVE included. This is due to CVE’s practice of lumping multiple unique vulnerabilities into a single entry, as well as missing some disclosures completely. The VTEM also shows the average CVSS score, average time to patch, and much more. Imagine missing this many vulnerabilities in a two year period for a single product. Organizations relying on CVE don’t have to imagine it unfortunately.

Not to be overlooked, the dump included another important disclosure; the OpenPGP / S/MIME vulnerability known as ‘Efail’ – which garnered huge press and dire warnings from the Electronic Frontier Foundation – was present. While the severity of Efail is a hotly debated topic, it is still critical to know about such issues so that your organization can evaluate the risk in the context of your systems and users.

When it comes to vulnerability intelligence, timeliness is critical. Getting information on a given vulnerability days, weeks, or even years late can leave organizations needlessly exposed to attackers. In this case, CVE delivered information on 318 vulnerabilities up to seven years late. Compare that to VulnDB, which had information on all of these issues available immediately after disclosure, including additional technical details still not available in some of the CVE entries. Timely, high quality vulnerability intelligence is the only way an organization can properly evaluate the risk, triage the constant flood of new vulnerabilities, and better protect their organization.