Do software vulnerabilities transfer between products?

There is an old intuition in offensive security, usually stated informally: "every exploitation method already exists - it just hasn't been carried from one stack to the next yet." If that is true, then a vulnerability is not really a property of a product. It is a mechanism - a typed edge - that happens to have been filed against a particular product, and the same edge is sitting unexploited on other products that share its preconditions.

This is a testable claim, and we tested it. We took ~10,000 publicly disclosed HackerOne reports, distilled each into a product-agnostic mechanism card, embedded the cards into a shared vector space, and measured two things:

1. Footprint - how many distinct products has each specific mechanism already been independently filed against?
2. Persistence - are old mechanisms still landing on new products today, or has the phenomenon saturated?

Base framing to keep in mind: this is a measurement of disclosed bugs - a selection-biased sample of what was found and chosen for publication, not of all bugs that exist. It tells us about the reuse structure of the public record, which is exactly the structure a researcher actually draws on.

Key findings (the short version)

• The median vulnerability mechanism has already been filed against 4 distinct products. Not "all XSS lands everywhere" - the specific edge (e.g. credential-leak-on-redirect, stored-XSS-via-a-name-rendered-to-admin), clustered tightly, has a median footprint of 4 products.
• 70% of mechanisms are multi-product; a third have hit 11+ products; 6% have hit 25+. The mean (8.6) is pulled up by a heavy tail of highly-reusable edges.
• 30% are single-product - a real, irreducible tail of genuinely product-specific bugs that do not transfer.
• Transfer is not saturated. It is ongoing. 27% of mechanisms first disclosed 3+ years ago recruited a brand-new product within the last 18 months - and because public-disclosure ingestion lags the real feed, 27% is a lower bound. Decade-old mechanisms are still spreading to new stacks right now.
• Independent corroboration that "mechanism" is the right unit: an academic system, Vul-RAG (Du et al., 2024), built almost exactly this representation - distilling vulnerabilities into product-agnostic knowledge and retrieving by functional semantics rather than raw code - and measured that it beats code-level retrieval for vulnerability detection (0.61 vs 0.50 accuracy). Our result is the corpus-scale counterpart: the reuse it exploits is real and large.

The rest of this page shows the work - and the limitations, which matter.

Method

Corpus. ~14,000 disclosed HackerOne reports (the public reddelexc/hackerone-reports feed plus HackerOne's own disclosed-report dump), of which ~10,367 carry a full enough writeup to distill. Each report is a real, paid, publicly-disclosed bug across 928 bug-bounty programs.

Mechanism cards. Each report's writeup is distilled by an LLM into a normalized, product-name-stripped card: bug_class / source / sink / trigger / preconditions / impact. The point of stripping the product is to represent the bug as a transferable edge - "an attacker-controlled URL reaches a server-side fetch with no internal-IP filter" - rather than "a Sentry bug" or "a GitLab bug." This is the same de-anchoring move Vul-RAG formalizes as functional semantics.

Embedding. Cards are embedded with BAAI/bge-small-en-v1.5 (384-dimensional, ONNX). Prior work - and our own nearest-neighbour checks - confirm these embeddings cluster by mechanism, not by product: the nearest neighbours of one SSRF card are the same mechanism on Elastic, Imgur, Mozilla, the DoD, etc., at cosine distances of ~0.10–0.12.

Footprint measurement. We randomly sampled 250 mechanisms (seed cards). For each, we pulled its tight neighbourhood - cards within cosine similarity > 0.85 of the seed, i.e. the same specific edge on potentially different products - and counted the number of distinct programs in that neighbourhood. That count is the mechanism's already-realized transfer footprint.

Persistence measurement. Within each neighbourhood we recorded, per product, the first disclosure date of that mechanism on that product. A mechanism is "still recruiting" if a product whose first-disclosure-for-this-mechanism falls in the last 18 months appears in a neighbourhood whose overall first disclosure was 3+ years ago - i.e. an old mechanism that found a genuinely new home recently.

All measurement was read-only over the corpus; no systems were probed.

Result 1: the same mechanism is already on several products

Footprint of a specific mechanism (distinct products it has been independently filed against), n = 250 sampled mechanisms, tight clusters (cosine > 0.85):

The distribution is the story. There is a real single-product tail (30%) - bugs so specific to one product's logic that the mechanism never recurs. But 70% of mechanisms have already landed on two or more products, the median is four, and a full third have hit eleven or more. The product was, for most of these bugs, just a label on a recurring edge - exactly as the informal intuition claims.

This is the fine-grained version of a coarser, well-known fact: bucket the same corpus by bug class and SSRF alone spans 183 products, code-execution 205, IDOR 202. The contribution here is showing it holds at the level of the specific mechanism, not just the broad class.

Result 2: the transfer has not saturated - it is perpetual

If mechanism reuse were a one-time land grab - every reusable edge gets carried to every obvious product within a couple of years, then stops - the phenomenon would be of historical interest only. It is not.

• 238 of the 250 sampled mechanisms were first disclosed 3+ years ago (the corpus skews historical).
• 27% of those old mechanisms recruited a genuinely new product within the last 18 months.

A quarter-plus of decade-old mechanisms are still finding new homes, continuously. And this is a lower bound: public disclosure lags discovery by months-to-years, so the most recent transfers are systematically under-counted. The reuse structure is not a frozen map; it is a live, refilling one.

Discussion: what this does - and does not - mean

It means the public vulnerability record is, structurally, a transfer map: for most mechanisms, you can read off which products an edge has already been filed against and infer which comparable products it has not been tried on yet. Because the map keeps refilling (27%+/18 months), that inference has lasting, not one-off, value. Thinking in mechanisms rather than products is not a stylistic preference; it is what the data's reuse structure rewards.

It does not mean automated exploitation. We are careful here, because this is the line where security tooling routinely over-claims. That a mechanism has transferred to many products, and keeps transferring, does not imply that any specific candidate target is exploitable, or that the next transfer can be found automatically. In separate work we ran exactly that harder test - take a transferred mechanism, pick a fresh well-maintained target, and source-verify whether the edge survives - and on hardened, heavily-audited targets it usually does not: the obvious instances of a recurring mechanism are typically the ones already found and patched. The map tells you where to look and why; whether the bug is actually there, on a specific deployment, remains a verification step a human (or a careful agent) must perform. The value is orientation and grounding, not a push-button finder.

That distinction is the honest one, and it is consistent with the academic result: Vul-RAG's knowledge-level retrieval improved analysts' detection accuracy (in their user study, from 60% to 77%) - it primed the human; it did not replace the judgment.

Limitations (threats to validity)

• Selection bias. This is disclosed HackerOne data - found bugs that were chosen for publication. It describes the reuse structure of the public record, which over-represents web/app classes and under-represents whatever never gets disclosed.
• Cluster-threshold sensitivity. "Same mechanism" is operationalized as cosine > 0.85. Loosen it to 0.80 and the mean footprint roughly doubles (16.7); tighten it and footprints shrink. The median-is-multi-product and still-recruiting conclusions are robust to the threshold; the exact magnitudes are not.
• Program, not product, granularity. A "new product" is a new program handle, which can occasionally be a new program for a known company rather than a genuinely new product.
• Distillation noise. Cards are LLM-distilled; a fraction mislabel the mechanism. We use the embedding (not the noisy bug_class string) for clustering to mitigate this.
• "Transferred" ≠ "exploitable-by-you." As above - the strongest limitation. Reuse in the record is necessary but not sufficient for a live finding.

The hypothesis the data tempered

The seductive version of the thesis is: "because mechanisms transfer, a corpus of mechanisms can generate new bugs on demand." The footprint and persistence numbers are real, and they make a corpus a genuine research-direction engine. But the harder follow-up test (verify a transferred mechanism on a maintained target) says the corpus mostly re-derives the already-found set - because the corpus is made of found bugs. So the honest claim is narrower and, we think, more useful: mechanism reuse is real, large, and ongoing - and that makes the public record a map of where to look, not an oracle of what you will find.

Practical takeaway

If you hunt or defend, the operational consequence is simple: index your knowledge by mechanism, not by product. When you see one bug, its real signal is the edge, and the question worth asking is "which other systems in my scope satisfy this edge's preconditions and have not been tested for it?" The data says that question has a non-empty answer for 70% of mechanisms, and a fresh answer 27%+ of the time even for decade-old edges.

FAQ

Are vulnerabilities reused across different products? Yes, and measurably so. In a sample of 10,000 disclosed HackerOne reports, the median specific vulnerability mechanism had already been independently filed against 4 different products, and a third had been filed against 11 or more.

Does this mean a tool can find new bugs automatically? No. Mechanism reuse tells you where a known edge has and hasn't appeared - it is a map and a priming signal. Whether a specific target is actually exploitable still requires verification; on well-maintained targets the obvious instances are usually already patched.

Is the transfer phenomenon saturated? No. 27% of mechanisms first disclosed more than three years ago recruited a brand-new product within the last 18 months, and that figure is a lower bound because public disclosure lags discovery.

What does "mechanism" mean here? A typed edge: a source (attacker-controlled input) reaching a sink (dangerous operation) via a trigger, given preconditions - stripped of the product name. The same representation Vul-RAG calls functional semantics.

References

• Du et al., "Vul-RAG: Enhancing LLM-based Vulnerability Detection via Knowledge-level RAG", 2024. arXiv:2406.11147 - independent evidence that de-anchored, knowledge-level retrieval beats artifact-level retrieval.
• HackerOne disclosed reports - reddelexc/hackerone-reports.
• Embedding model - BAAI/bge-small-en-v1.5.
• CWE (cwe.mitre.org) and CAPEC (capec.mitre.org) - the standard weakness and attack-pattern taxonomies; the "mechanism" framing is a finer-grained, empirical cousin.
• Related field notes: What actually predicts vulnerability exploitation?

Method note: all measurements were read-only over a private fused vulnerability corpus; figures are point-in-time (2026-06-29) and will drift as the disclosed-report feed grows.