Connect an AI Coding Agent to Your CVE Feed: Fix Real Vulnerabilities, Prove the False Positives

A vulnerability feed answers one question: which published CVEs mention something you run. It cannot answer the two questions your engineers actually ask: does this bug reach our code, and if it does, what is the fix. Those answers live in your repository and on your servers, and until recently getting them meant an engineer reading advisories, grepping code and logging into machines, one CVE at a time.

An AI coding agent connected to vulneraibility.com through the Model Context Protocol (MCP) changes that. The agent gets your stack-matched CVEs, with versions and statuses, from vulneraibility.com, and it already has access to your code and, if you allow it, a shell on your servers. Put the two together and it can do the investigation an engineer would do, in minutes, and leave a written trail of what it found.

The loop

The value is in steps 3 and 4. They turn "this CVE mentions a product you use" into "this function is called in two files, here is the patch", or into "this module is not loaded on any server, here is the command output".

What it looks like on a real stack

These are real findings from one team's stack of two web applications and a data pipeline, all investigated by an agent connected through MCP in a single session.

Five findings, five different answers, each backed by evidence. Severity alone would have sent the team to patch the Apache 9.8 first, a module they do not even load, while the CVSS 10 in a library their code actually calls waited in the queue.

Set it up in five minutes

1. Create an API key in Settings on vulneraibility.com (Max plan).
2. Add the MCP server to your agent. In Claude Code:

claude mcp add --transport http vulneraibility https://www.vulneraibility.com/api/mcp --header "Authorization: Bearer YOUR_KEY"

1. Make sure your stack and applications are described in vulneraibility.com, with versions. The agent can do this for you: "create an app called customer-api with Node.js 20.19, Axios 1.13.2 and OpenSSL 3.5.7". See the MCP documentation for Claude Desktop, Cursor and others.

Prompts that work

• "List the open CVEs that affect the customer app at the versions it runs, known exploited first."
• "For CVE-2026-40175, check whether our code calls the vulnerable function. Show me the files."
• "Check on this server whether the Apache module named in CVE-2026-57941 is loaded. Use read-only commands only."
• "If it is not reachable, mark it risk accepted with a note containing the evidence. Ask me before writing."
• "Prepare a branch that upgrades Axios to a fixed version, run the tests, and summarise what changed."

Guardrails that keep it safe

• Read-only on servers. Give the agent commands that inspect (list modules, print versions, search files), never commands that change configuration.
• Humans approve writes. Let the agent propose a status change or a pull request; a person confirms.
• Evidence or it did not happen. A "not affected" decision without a note is an audit gap. Ask the agent to paste the command and its output into the note.
• Re-check after changes. A module not loaded today can be enabled tomorrow. Review risk acceptances periodically; the executive report lists them with their justifications.

Why this is a step change

Vulnerability management has always had a gap between knowing and doing: the feed knows what was published, the engineer knows the code, and the advisory sits in between. An MCP-connected agent closes that gap. It brings the feed into the place where the code lives, so the question "are we affected?" gets answered with evidence instead of a guess, and the answer is recorded where your auditors will look for it.

Start by describing your stack, then connect your agent. The first investigation usually pays for the setup.