Open Source Vulnerabilities: What Actually Ships in a Connected Device

Most lists of common open source vulnerabilities describe web applications. If you ship a device, that list is about somebody else's product, and so is the advice attached to it.

Read the top-ranking articles on open source vulnerabilities this month and you will find Apache Tomcat, Craft CMS, OpenProject, a set of VS Code extensions, and an npm proxy for AI tooling. Those are real vulnerabilities in real software. None of them ship in a connected device.

The components that do ship in your product are a much shorter list than the internet suggests. In the largest published analysis of firmware composition, ten components accounted for roughly 90% of the CVEs found across 34,136 images. Those ten are knowable. Most of them have been in your product since before anyone on your current team joined.

What follows covers which components carry the risk and which weakness classes they actually produce, why your build manifest cannot see most of them, why the average component was already years old the day the product shipped, what changed in the National Vulnerability Database in April 2026, why a version match is not an exposure, and what the Cyber Resilience Act makes you responsible for starting September 11, 2026.

The Common Open Source Vulnerabilities in a Firmware Image

SQL injection and cross-site scripting head almost every list of common open source vulnerabilities. In the largest study of firmware composition to date, neither one appears in the top ten weakness classes.

An open source vulnerability is a known flaw in a third-party component you did not write and, in a device, usually did not choose.

Researchers using a tool called FIRMSEC analyzed 34,136 firmware images across 13 vendors and 35 device categories, detecting 584 distinct third-party components and 128,757 vulnerability instances traced to 429 CVEs. The weakness classes below accounted for 88% of those CVEs.

Code injection appears ninth, at 8 CVEs. SQL injection and cross-site scripting do not appear at all. That is not a scoring quirk. A device with no SQL database and no browser rendering user-supplied markup does not have those attack surfaces, and a guide that leads with them was written for a different reader.

The component concentration is the more useful half of the finding. OpenSSL carried the most CVEs of any component at 132, affecting 1,304 firmware images. BusyBox was the most widely deployed, present in 3,326 images, where just 12 CVEs produced 12,072 vulnerability instances. That is roughly 1,006 instances per CVE. One flaw in one ubiquitous component propagates across vendors, architectures, and product lines that have nothing else in common.

Every router in the study carried BusyBox, OpenSSL, Dnsmasq, MiniUPnP, uClibc, L2tpd, and Util-linux.

The old vulnerabilities also do not leave. Heartbleed, disclosed in 2014, was still present in 380 firmware images from 8 vendors. GHOST was in another 224 images from 4 vendors.

That dataset was assembled in 2022, so treat the specific counts as the best available picture rather than this morning's telemetry. The composition finding is the durable part. A list of CVEs is stale in a year. A list of components is not.

Why Your Build Manifest Does Not Contain the Answer

Pin exact versions. Use a lockfile. Run a dependency bot. Restrict installs to a curated registry. Every one of those instructions assumes a package manager sits between a developer and a component, and embedded C and C++ have no standard one.

Components reach a firmware image through four routes that no manifest records. A vendored source tree copied into the repository. Files pasted into a directory in 2019 by someone who has since left. A board support package dropped in whole by a silicon or module supplier. And static linking, which folds a library into a single image with no separate artifact left to inventory.

Your build system records what it was told to fetch. It has no way to know what a supplier put in the blob it was handed.

Regulators have started asking about this gap directly. On July 29, 2026, CISA published the 2026 Minimum Elements for a Software Bill of Materials with the NSA, the FBI, and international partners, replacing the 2021 NTIA minimum elements. Among the added fields is SBOM Generation Context, which asks the author to record at what point in the build the SBOM was produced. The stated reasoning is that an SBOM generated from source differs from one generated after packaging, and the two can disagree.

Read that again. The guidance now assumes your build-derived inventory and your shipped product may not match, and asks you to disclose which one you are showing. Component Hash Algorithm and Component License were added in the same revision.

Your manifest is a record of intent. The binary is a record of outcome. This is also why application security tools struggle against firmware: they were built to read repositories, and a shipped image is not a repository.

If any part of your product arrived from a supplier as a binary, your manifest is not an inventory. It is a claim about an inventory.

The Component Was Already Years Old on Launch Day

Outdated components are not rot that sets in after release. They are built in on day one.

In the same study, the average third-party component lagged the then-current release by 1,948.2 days at the moment the firmware shipped. The product was new. The code inside it was more than five years old before a customer powered it on. One vendor averaged 3,457.2 days, which is closer to a decade.

Shipping firmware updates does not fix this, because firmware updates rarely touch the components. Across 22 consecutive firmware sets covering 162 images, only 6 changed their third-party components at all, and those only during major version updates. One set ran 43 consecutive images through three major updates while continuing to ship BusyBox 1.20.2 and uClibc 0.9.33.2, both carrying known CVEs the entire time.

There is a defensible reason this happens. A newer component version can change behavior, break a validated build, or blow a resource budget on constrained hardware. So teams pin. The pin is a reasonable engineering decision that then outlives the reason anyone made it, and nobody schedules the conversation about revisiting it.

Inertia shapes selection as well as versioning. The same study found fewer than 1% of firmware images using MbedTLS, a library designed specifically as a lighter-weight OpenSSL alternative for embedded systems. OpenSSL kept its position, and with it the largest CVE count of any component in the dataset.

The part that is harder to defend sits in the same data. In all but two of those 22 sets, the components shipped with CVEs that had already been publicly disclosed before the firmware was released. Not discovered later. Public, indexed, and searchable on the day the product went out the door.

Your release cadence is not a component update cadence. It only becomes one when somebody makes that an explicit job with a name attached.

The Vulnerability Database Changed in April 2026

A scanner that reports nothing and a product that contains nothing produce identical output. Since April 15, 2026, telling them apart got harder.

On that date, NIST stopped enriching every CVE in the National Vulnerability Database. Enrichment now goes to three categories: CVEs appearing in CISA's Known Exploited Vulnerabilities catalog, which NIST aims to process within one business day, CVEs for software used within the federal government, and CVEs for critical software as defined by Executive Order 14028. Everything else is labeled "Lowest Priority - not scheduled for immediate enrichment."

Look at those three categories from where you sit. A TLS library inside an infusion pump is not federal government software. A DNS forwarder in an industrial gateway is not EO 14028 critical software. Unless the CVE reaches KEV, the components in your product are exactly the ones that land in the lowest-priority pile.

The pressure behind the change is real and NIST is direct about it. CVE submissions rose 263% between 2020 and 2025. NIST enriched nearly 42,000 CVEs in 2025, 45% more than any previous year, and submissions in the first quarter of 2026 still ran nearly a third higher than the year before. Working faster stopped being enough.

Two further changes matter to a triage workflow. Every unenriched CVE published before March 1, 2026 moved to "Not Scheduled." And NIST no longer routinely adds its own severity score when the submitting CNA already provided one, which removes a layer of independent validation many programs treat as a default input.

Enrichment is not cosmetic. It is what produces the CPE product mappings a scanner matches against. No CPE data, no match, no finding, and no signal that anything was missed.

Selling into the EU adds a second source to reconcile. ENISA's European Union Vulnerability Database has been publicly available since May 2025 under a NIS2 mandate.

Find out this week which feed supplies CPE matching in your toolchain, and what your scanner does with a CVE that has none.

A Version Match Is Not an Exposure

The researchers who found 128,757 vulnerability instances refuse to call them vulnerabilities. They call them potential vulnerabilities, on the stated grounds that vulnerable code may be unreachable because a configuration option is disabled or another remedy is in place.

The people holding the largest number in this field will not treat a version match as a finding. Every article currently ranking for this keyword does.

Three separate questions hide inside one CVE hit:

• Is the component present in the shipped image?
• Is the vulnerable function present in what was actually compiled in, given that embedded builds routinely strip unused code?
• Is that function reachable and triggerable in your shipped configuration?

Only the third describes an exposure. A version string answers the first and guesses at the other two.

This is not an argument for ignoring findings. It is an argument for being able to explain them. You cannot patch several thousand CVEs, which means your program is defined by what you chose not to patch and whether that choice survives contact with an assessor. Triaging by exploitability rather than severity alone is what makes that survivable at portfolio scale.

In practice that means a status and a justification per finding, in a machine-readable format your customers and assessors can consume rather than a spreadsheet somebody maintains by hand. A not-affected determination that names its reason, such as the vulnerable code path being absent from the build, is defensible. The same conclusion with no stated basis is an assertion.

Treat the determination as an artifact you produce, not a judgment you make once and remember.

What the Cyber Resilience Act Makes You Responsible For

Most coverage of the Cyber Resilience Act points at December 11, 2027. The first operative deadline is September 11, 2026. [verify before publishing]

Article 13(5) is the provision that closes the argument that open source vulnerabilities are somebody else's problem. Manufacturers must exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product, including components of free and open-source software that have not been made available on the market in the course of a commercial activity. The drafters wrote that last clause deliberately. Pulling a library off GitHub does not put it outside your obligations.

Article 13(6) adds a duty most manufacturers have no process for. On identifying a vulnerability in a component, including an open source component, you must report it to the person or entity manufacturing or maintaining that component, and remediate it in line with the vulnerability handling requirements in Annex I Part II. That is an upstream notification, not just a patch.

Legacy products are in scope. Article 69(3) extends the reporting obligations to products already made available on the EU market before the regulation applies in full. [verify before publishing] That is usually the harder half, because the products already in the field carry the oldest components and the thinnest records.

Both duties assume you can answer "is this component in this SKU" quickly. A reporting clock does not pause while you go and find out what is inside a product.

Set that against the finding from earlier: components shipping with CVEs that were public before release. Annex I Part I requires products with digital elements to be placed on the market without known exploitable vulnerabilities. The gap between those two facts is not a hygiene problem. The dates and staging are set out in the CRA milestone timeline for 2026 and 2027.

No conformity, no CE mark. No CE mark, no EU market.

Key Takeaways and Where to Start

• Weakness classes differ by product type. Resource management errors, buffer overflows, cryptographic issues, and improper input validation dominate firmware. SQL injection and cross-site scripting do not appear in the top ten.
• Ten components carry roughly 90% of the CVEs, led by OpenSSL and BusyBox. Track components, not CVE lists.
• Manifests cannot see vendored trees, pasted files, supplier BSPs, or statically linked code, which are the components most likely to be unmanaged.
• The average component was 1,948.2 days behind current on the day it shipped, and firmware updates rarely change components.
• The NVD stopped enriching every CVE on April 15, 2026. The three prioritized categories mostly exclude device components.
• CRA Article 13(5) and 13(6) name open source explicitly, and Article 14 reporting applies from September 11, 2026, including to products already on the market.

One first move, and it costs a build cycle. Pick one SKU, generate the SBOM your build system produces, generate a second inventory from the shipped image, and diff the two lists.

Every component that appears only in the binary has no owner, no update path, and no entry in your triage queue. The 2026 minimum elements ask you to record how and when your SBOM was generated, so you will document that distinction anyway. Better to find the delta yourself.

Finite State builds that inventory from the shipped firmware image rather than the build manifest, with no source code and no supplier cooperation required. To see it run against one of your own products, request a walkthrough.

FAQ

What are the most common open source vulnerabilities?

It depends on what you ship. In web applications, injection and cross-site scripting classes dominate. In device firmware, the largest published analysis found resource management errors, buffer overflows, cryptographic issues, and improper input validation leading by CVE count, concentrated in about ten components including OpenSSL, BusyBox, Dnsmasq, and uClibc.

Are SQL injection and cross-site scripting common open source vulnerabilities in firmware?

No. Across 34,136 firmware images, neither appeared in the top ten weakness classes by CVE count. Code injection ranked ninth with 8 CVEs. Both are common in web applications, which is why they lead most general guides, but a device with no SQL database and no browser rendering user content lacks those attack surfaces.

Why does my SCA tool find nothing in a firmware image?

Because it reads a dependency manifest, and embedded C and C++ have no standard package manager. Components arrive as vendored source trees, copied files, supplier board support packages, and statically linked objects. None appear in a manifest, so a manifest-based tool reports a clean result on a product full of components.

If a CVE has no CVSS score in the NVD, does that mean it is not serious?

No. Since April 15, 2026, NIST prioritizes enrichment for CVEs in CISA's KEV catalog, federal government software, and EO 14028 critical software. Everything else is marked lowest priority. NIST states directly that CVEs failing those criteria may still have significant impact on affected systems. An unscored CVE means unenriched, not harmless.

Does the Cyber Resilience Act make me responsible for vulnerabilities in open source I did not write?

Yes, for products you place on the EU market. Article 13(5) requires due diligence when integrating third-party components, explicitly including free and open-source components not made available commercially. Article 13(6) requires you to report an identified component vulnerability to whoever maintains that component and to remediate it. [verify before publishing]

What do I do about a vulnerable component I cannot upgrade?

Establish whether the vulnerable function is present in what you compiled and whether it is reachable in your shipped configuration, then document that determination as evidence. Pinning a component to protect a validated build is common and often defensible. What is not defensible is a pin nobody has revisited and nobody can explain.