Stay Ahead of CVE Risk: Know Which of Your Apps a New Vulnerability Hits

Most security teams do not lose to zero-days. They lose to a known vulnerability, in a product they run, that was published weeks earlier and drowned in the feed. More than 80,000 CVEs have been published in 2026 so far (see the live CVE statistics), which is over 200 a day. Nobody reads that. The only question worth asking each morning is narrower: which of my applications does today's news touch, is my version affected, and is anyone exploiting it?

This guide walks through how a small team uses vulneraibility.com to answer that question in minutes, and stay ahead of the risk instead of reacting to it.

The team in this example

Picture a two-person engineering team running three applications:

Same host, overlapping components, different versions. That last detail matters more than it looks: the same Next.js CVE can affect one app and not the other.

Step 1: describe what you run, app by app

Start by listing your stack: the products your applications depend on. Then group them into apps, each with its own versions. In this example the customer web app runs Next.js 15.5.9 while the marketing site runs 16.2.6, and that is exactly what gets recorded.

You do not need a scanner or an agent on your servers for this. A list of products and versions is enough, and it takes a few minutes per application. You can type it in Settings, or let an assistant do it through the API or the MCP server ("create an app called marketing-site with Next.js 16.2.6 and Apache HTTP Server 2.4.68").

The payoff is immediate: instead of 80,000 CVEs, the dashboard shows the few hundred that touch something you run, and each row says which of your apps it touches.

Step 2: separate real hits from noise

Matching on product names alone produces noise. A CVE about a Perl module called Crypt::OpenSSL::X509 mentions OpenSSL, but it is not an OpenSSL vulnerability. A Windows privilege escalation that abuses a crafted openssl.cnf is not either.

So every row carries a label:

• Product name with your version, for example "OpenSSL 3.5.7": one of your technologies is named as an affected product.
• mentions OpenSSL: your technology only appears in the text.

Mentions are never hidden by default, because occasionally the mention is the story. But with one click on the mentions toggle you can focus on the CVEs that name your products, which in practice removes most of the list.

Step 3: check your version, not just the product

A CVE that affects Axios does not necessarily affect your Axios. Where the vendor or CNA published an affected range, vulneraibility.com compares it with the version you declared:

• affects your 1.13.2 (in red): your version is inside the published affected range.
• outside your 1.15.0: your version falls outside it. Hover to see why that is not a guarantee: vendor ranges can be wrong, and backported builds keep old version numbers.
• No badge: there is no published range to compare against, so treat it as possibly affected.

The detail panel shows the evidence, including the published range and the fixed release when the vendor gives one, so the verdict can be checked rather than taken on trust. If you decide to trust the ranges, the outside my version toggle hides the out-of-range rows. It is off by default: nothing disappears unless you choose.

Step 4: prioritize by exploitation, not by score

A list of CVEs that touch your versions is still a list. The order matters. Each CVE carries three signals, and they answer different questions:

In our example, the most urgent item was not the 9.8 that appears in every newsletter. It was a prototype-pollution flaw in the exact Axios version the customer web app imports, with a CVSS of 10 and an EPSS around 2%. The 9.8 Apache HTTP Server CVE sat in mod_http2, a module this team does not load, so it could wait. Severity alone would have produced the opposite order.

Step 5: decide, and write the decision down

Every CVE gets a status: open, in progress, risk accepted, archived or closed. Each decision can carry a note: "patched to 3.5.9 on all hosts", "mod_http2 not loaded", "owner: Alex, waiting on vendor patch".

Triage arrives in clusters, so it works in bulk too. Select everything in the current view (the select all button or Ctrl/Cmd+A), add one note, and apply a status to all of them at once. Every change, single or bulk, lands in the CVE's history with who made it and from where (the dashboard, the API or an assistant through MCP). When an auditor asks why a critical CVE was accepted in March, the answer is one click away.

This is also where you stay ahead: closed and accepted CVEs drop out of the active view, so tomorrow morning you only see what changed.

Step 6: let an assistant do the reading

The slowest part of triage is reading advisories. Connect Claude, Cursor or any other MCP client to the vulneraibility.com MCP server and ask questions in plain language:

• "Which of my apps are impacted by Next.js CVEs?"
• "What are my open critical CVEs this week, KEV first?"
• "Explain CVE-2026-84782 and tell me whether my OpenSSL version is affected."
• "Mark the Apache mod_http2 CVE as risk accepted with the note: module not loaded."

The assistant reads your matched feed, with your versions and statuses, rather than guessing from its training data. It can explain each finding, check the conditions an advisory lists against what you tell it about your setup, and propose a decision. Writes go through the same rules as the dashboard, and every change it makes is recorded as made via MCP.

A morning routine that takes ten minutes

1. Open the dashboard on MY STACK with mentions hidden.
2. Look at anything new with KEV, then anything marked affects your version.
3. For each one, read the conditions in the detail panel and decide: fix, accept with a note, or archive.
4. Bulk-close what last night's patch window fixed, with one note.
5. Once a week, review risk accepted items to make sure the reasons still hold.

Why this keeps you ahead

Attackers do not need a zero-day when a known vulnerability in a popular component goes unpatched for weeks. The gap they exploit is the time between publication and the moment someone on your team realizes it applies to them. Mapping your applications once, matching every new CVE against them, checking your actual version and ranking by exploitation closes most of that gap without adding headcount.

vulneraibility.com is in private beta. Request access, describe your stack in a few minutes, and tomorrow morning you will see only the CVEs that touch your applications.