The identifier is right there. The answer is four tabs away.
Vulnerability identifiers are text. They appear in vendor bulletins, release notes, tickets, pull requests, newsletters and chat, and every one of them is inert. To find out whether one matters you select it, copy it, open a tab, search, read, then come back and find your place again. Do that thirty times on one Patch Tuesday page and the afternoon is gone, most of it spent on identifiers that turned out not to matter. The expensive part was never the lookup, it was the context switch around it, and the fact that you had to pay it before knowing whether it was worth paying.
One vendor bulletin. A hundred and twenty identifiers.
On a real security update guide the extension finds 120 identifiers and loads 55 of them. The rest wait, because fetching a hundred and twenty records to answer a question about four of them is how a daily allowance disappears on a single page. The page is ordered by release date; the sidebar re-orders it by what is being exploited, and the footer shows exactly what quota remains and when it resets.
Two surfaces: read one, or triage all of them
The hover card. Every identifier in the page text gets a dotted underline. Hovering one shows the same summary the Vulnetix console renders: severity and vector, how old the record is, the affected product, whether an exploit exists and whether it has been seen in the wild. One hover fetches one record; nothing is loaded speculatively.
The sidebar. A real browser sidebar, not a popup that closes when you click the page. It lists every identifier on the active tab and stays open while you read. Sort KEV-first, then filter to KEV, malware, high and critical, or exploit available. It loads in batches of 25 with four concurrent requests, so a long page fills in progressively rather than stalling. Both surfaces deep-link into the Resolve console for full triage: complete record, affected version ranges, remediation and the ability to record a decision against your organisation.
Fourteen identifier schemes, because not everything has a CVE
A distribution notice cites a USN or a DSA. An ecosystem advisory cites a GHSA or a PYSEC. A malicious package has a MAL record and frequently no CVE at all. An extension that only recognises one scheme goes quiet on exactly the pages where the others appear.
CVE
MITRE / NVD
GHSA
GitHub Security Advisories
OSV
Open Source Vulnerabilities
EUVD
ENISA EU database
GCVE
Global CVE allocation
MAL
Malicious package records
RUSTSEC
Rust advisory database
PYSEC
Python advisory database
GO
Go vulnerability database
SNYK
Snyk advisory identifiers
DSA
Debian security advisories
USN
Ubuntu security notices
RHSA
Red Hat security advisories
ALAS
Amazon Linux security advisories
Both engines, not just the one with a store
Extensions in this category are commonly built for a single browser and published to a single store. That quietly excludes everyone on a fork and everyone on Firefox. Vulnetix ships a build for each engine.
Chromium
Chrome, Edge, Brave, Arc, Opera, Vivaldi, Chromium
One build, loaded unpacked or from the store. The sidebar uses the native side panel.
Firefox
Firefox, Firefox ESR, Firefox Developer Edition, Zen, LibreWolf, Waterfox
A signed XPI that installs permanently. The sidebar uses Firefox’s own sidebar and can open itself when identifiers are found.
Firefox ESR 128 predates the highlight API the extension prefers, so it is feature-detected: on older builds matches are wrapped instead, which also supplies a keyboard path to the card. An older long-term support browser is a supported configuration rather than a broken one.
Where it earns its place
A vendor bulletin with a hundred entries
Patch Tuesday, a quarterly critical update, a distribution notice. The page lists everything shipped in release-date order with no indication which four matter tonight. Sort by KEV, filter to what has a public exploit, and the list you actually work is on screen before you have opened a second tab.
A dependency bump in review
A pull request updates a lockfile and the description cites six advisories. Read them in the diff rather than reconstructing them in another window and losing your place in the review.
A ticket someone else raised
A CVE pasted into Jira, ServiceNow or Linear with no context and a due date attached. The card answers whether it is exploited, whether it is in a KEV catalogue and how old it is, without leaving the ticket.
A customer asking about one specific CVE
A questionnaire, an auditor, a security review email. You need a defensible answer in minutes, not a research project, and the console link is one click from the identifier they quoted.
Security news and research
A newsletter, a conference write-up, a vendor blog naming half a dozen issues. Which of them are actually being exploited is the only question that decides whether you keep reading.
Wherever your team is talking
Slack, Teams, Discourse and mailing list archives in a browser tab are where most identifiers are first seen. The extension treats them like any other page, because to it they are.
An extension is a delivery mechanism. The data is the product.
Two extensions can underline the same text and disagree entirely about what you should do next, because the difference is not the hover card. It is what the identifier can be joined to. Every card can carry four KEV catalogues rather than one, with CISA binding remediation deadlines where they apply; exploit records counted across twenty sources including ExploitDB, Metasploit, Nuclei, VulnCheck XDB, CrowdSec, HackerOne, Bugcrowd, MISP, nmap NSE and Shadowserver, each with first and last observation dates; malware and typosquat records for packages that never receive a CVE; end-of-life release data for a runtime nobody will patch again; and EPSS alongside CVSS v4, because how bad something would be and whether anyone is doing it are different questions. The VDB aggregates 150+ upstream sources, enumerable through the public /v1/sources endpoint, across 4.8M advisory records and 173M affected-version rows. The same records answer the same questions in the CLI, in CI, in the console and through the MCP server.
An extension that reads every page you visit should be boring
The page is never sent anywhere
Detection runs entirely in your browser. Only matched identifiers leave, and those are public catalogue numbers. Page URLs, titles, content, history, tabs, bookmarks and cookies are never transmitted, and the scanner skips inputs, textareas and contenteditable regions, so text you are typing is never even read.
The credential never reaches the page
Every request is made from the background worker, so the script running alongside the page never holds your key. A compromised site cannot exfiltrate a credential it was never handed. A lint rule bars the import and a test walks the whole import graph to catch a transitive one.
It paints without touching the page
Matches are drawn with the CSS Custom Highlight API, which mutates no DOM. It cannot break React or Vue reconciliation, cannot be clobbered by a re-render, and cannot feed a MutationObserver back into itself. It also spans element boundaries, so an identifier split across a link and a bold tag is still one match.
Scanning stays off the main thread
The matcher runs in a worker. Where a site content security policy blocks that, a handshake detects it and the identical matcher runs in idle-time slices instead, so a strict page degrades in speed rather than in function.
Permissions you can count
Storage, alarms, the side panel and two API hosts. Deliberately not requested: tabs, scripting, web navigation, cookies, offscreen documents, unlimited storage or all-URLs. Nothing is web-accessible, and a CI check fails the build if any of that changes.
You choose where it runs
Disable it per site, or invert the whole thing so it runs only on origins you name. An internal wiki that should never see an extension is one entry away from being excluded.
One honest limitation: extension storage is not encrypted at rest, so anyone with access to your browser profile can read the stored credential. Browser extensions have no route to an operating system keychain. That is a platform constraint rather than a decision, and it is worth knowing before you sign in on a shared machine.
Frequently asked
How do I install it in Chrome, Edge, Brave, Arc, Opera or Vivaldi?
Download vulnetix-chrome.zip and unzip it. Open chrome://extensions (edge://extensions in Edge, and the equivalent in the others), turn on Developer mode, choose Load unpacked and pick the unzipped folder. A raw .zip cannot be dragged onto the extensions page the way a .crx can, so unzipping first is the step people miss.
How do I install it in Firefox?
Download vulnetix-firefox.xpi, which is signed by Mozilla and installs permanently: open Add-ons and themes, then the gear menu, then Install Add-on From File. There is also an unsigned vulnetix-firefox.zip, but Firefox will only load it temporarily and removes it on restart, so it is for testing rather than daily use.
Where are the downloads and the checksums?
Every release publishes the Chromium zip, the Firefox zip, the signed Firefox XPI, the sources as submitted for review, and SHA256SUMS.txt covering all of them. The links on this page always resolve to the newest release, because each release ships copies of its assets under fixed, version-less names. Versioned filenames are attached too and remain authoritative for provenance.
Which identifiers does it detect?
Fourteen schemes: CVE, GHSA, OSV, EUVD, GCVE, MAL, RUSTSEC, PYSEC, GO, SNYK, DSA, USN, RHSA and ALAS. That matters on real pages, where a distribution notice cites a USN or a DSA, an ecosystem advisory cites a GHSA or a PYSEC, and a malicious package has a MAL record and no CVE at all.
Do I need an account?
Detection and highlighting need nothing. Looking an identifier up needs a Vulnetix credential, which you can obtain by approving the browser from an existing session, the same device-code flow the CLI uses, or by pasting an API key. The Community plan is free.
What actually leaves my browser?
Vulnerability identifiers, and only when you ask for them: when you hover one, when you open the sidebar, or if you have deliberately enabled prefetch. Your API key travels with each lookup. Nothing else is transmitted, and there is no telemetry, analytics or crash reporting of any kind.
Will it slow pages down or break them?
Scanning the page costs no network at all and runs off the main thread. Highlighting mutates no DOM, so it cannot interfere with a single-page application re-rendering underneath it. Lookups are cached for 24 hours, so returning to an identifier you have already seen costs nothing.
What happens when I run out of quota?
It degrades to a linker rather than failing. The card tells you how long until your quota resets and keeps the console link live, so the identifier is still one click from full triage. That is also why lookups are on request by default: a single vendor bulletin can carry more than a hundred identifiers.
Why does it ask to read all websites?
Because identifiers appear on arbitrary pages, and a content script has to be present to find them. The mitigations are inspectable: the script first action is to check the current origin against your list, Settings offers an only-run-where-I-allow inversion, and the extension requests none of the permissions that would let it act on what it sees.
Downloads
vulnetix-chrome.zip for Chrome, Edge, Brave, Arc, Opera, Vivaldi and Chromium · vulnetix-firefox.xpi, signed and permanent · vulnetix-firefox.zip for temporary loading · vulnetix-sources.zip as submitted for review · SHA256SUMS.txt