# vulntel (remote · mcp.vulntel.com) Free hosted CVE intel for bug-bounty agents: CVE fact-check, attack approaches from paid H1 reports - Trust score: 66/100 (medium) - Registry status: active - Liveness: live - Owner verified: no - Last scored: 2026-11-05 ## Components - remote · `mcp.vulntel.com`: 66/100 (this document), [markdown](https://verifymcp.io/servers/com-vulntel-mcp/mcp.md), [page](https://verifymcp.io/servers/com-vulntel-mcp/mcp) ## Channel facts - Endpoint: `https://mcp.vulntel.com/mcp` - Transports: `streamable-http` - Auth: `none` - Version: `1.2.0` ## Trust breakdown How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog) Scored 2026-11-05. - **Endpoint Security**: 74/100 - The endpoint's TLS certificate is valid, in date, and uses a strong key. - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one. - HTTPS is enforced; there's no plaintext access path. - HSTS check failed: the Strict-Transport-Security header is absent. - DNSSEC check failed: this domain isn't protected by DNSSEC. - **Transport & Reachability**: 100/100 - Verified streamable-http transport via a live MCP handshake. - **Schema Quality & AI Usability**: 57/100 - AI-judged instruction clarity (good). - Context-footprint check failed: tool/resource definitions use about 4735 tokens (~364/item across 13 items; 13 tools + 0 resources), over budget; trim descriptions and params. - Usage-examples check failed: none of the tools include examples. - **Stability & Change Management**: 7/100 - Stability observed for 2 of 30 days with no destabilising changes; credit accrues until the full window elapses. - **Tool Coverage**: 67/100 - 100% of tools have a non-trivial description (not blank, and not just the tool's name). - 0% of tool parameters carry a description. - **Tool Safety**: 100/100 - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured. - We read all 13 captured tool definition(s), and no name or description among them implies an irreversible operation. - An AI judge read all 14 captured unit(s) of tool text and found none that tries to manipulate the model reading it. - **Capabilities**: 100/100 - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28. ## Install ### How do I install the vulntel MCP server? vulntel is a hosted endpoint at https://mcp.vulntel.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation. ### Claude ```bash claude mcp add --transport http com-vulntel-mcp 'https://mcp.vulntel.com/mcp' ``` ### Cursor ```json { "mcpServers": { "com-vulntel-mcp": { "url": "https://mcp.vulntel.com/mcp" } } } ``` ### VS Code ```json { "servers": { "com-vulntel-mcp": { "type": "http", "url": "https://mcp.vulntel.com/mcp" } } } ``` ### Codex ```toml [mcp_servers.com-vulntel-mcp] url = "https://mcp.vulntel.com/mcp" ``` ### opencode ```json { "$schema": "https://opencode.ai/config.json", "mcp": { "com-vulntel-mcp": { "type": "remote", "url": "https://mcp.vulntel.com/mcp", "enabled": true } } } ``` ### OpenClaw ```bash openclaw mcp add com-vulntel-mcp --url 'https://mcp.vulntel.com/mcp' --transport streamable-http ``` ### Hermes ```yaml mcp_servers: com-vulntel-mcp: url: "https://mcp.vulntel.com/mcp" ``` ### Netclaw ```json { "McpServers": { "com-vulntel-mcp": { "Transport": "http", "Url": "https://mcp.vulntel.com/mcp" } } } ``` ### Vellum ```bash assistant mcp add com-vulntel-mcp -t streamable-http -u 'https://mcp.vulntel.com/mcp' ``` ### Other ```json { "mcpServers": { "com-vulntel-mcp": { "type": "http", "url": "https://mcp.vulntel.com/mcp" } } } ``` The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs. ## Changelog Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims. ### 2026-11-04 (score 66, +1) - [security] The server rewrote its instructions, which are the text every model session reads - [security] Tool “assist_submission” rewrote its description, which is the text the model reads - [security] Tool “check_technology” rewrote its description, which is the text the model reads - [security] Tool “find_attack_approaches” rewrote its description, which is the text the model reads - [security] Tool “find_continuations” rewrote its description, which is the text the model reads - [security] Tool “search_public_code” rewrote its description, which is the text the model reads - [security] Tool “search_vulns” rewrote its description, which is the text the model reads - [functional improvement] Stability: unverified → 0.03 - [functional] Server version: 1.30.0 → 1.2.0 - [cosmetic] Tool “assist_submission” changed its title: Strengthen a bug-bounty submission - [cosmetic] Tool “check_technology” changed its title: CVEs for a product and version - [cosmetic] Tool “corpus_stats” changed its title: Corpus size and freshness - [cosmetic] Tool “enrich_cve” changed its title: Enrich a CVE - [cosmetic] Tool “find_attack_approaches” changed its title: Find attack approaches from disclosed bounty reports - [cosmetic] Tool “find_continuations” changed its title: Next moves from a hunt position - [cosmetic] Tool “hunt_plan” changed its title: Rank a recon'd stack into a dig order - [cosmetic] Tool “new_in_scope” changed its title: What newly entered bug-bounty scope - [cosmetic] Tool “observe” changed its title: Scan a host's exposed stack - [cosmetic] Tool “program_outcome_prior” changed its title: What lands on a bounty program - [cosmetic] Tool “search_public_code” changed its title: Find public copies of a code string - [cosmetic] Tool “search_vulns” changed its title: Search CVEs by concept, keyword or seed CVE - [cosmetic] Tool “verify_cve_claim” changed its title: Fact-check a CVE claim ### 2026-11-03 (score 65) First indexed and scored. ## MCP tools (13) ### `enrich_cve` (~139 tokens) Enrich a CVE Full intelligence for a single CVE: CVSS, KEV status, EPSS, CISA SSVC (exploitation/automatable/technical_impact), P1-P4 priority with rationale, affected products/versions, Debian/Ubuntu/Alpine fixed builds per release (`distro_fixes`), and (live) public-exploit signal. Args: cve_id: e.g. "CVE-2025-12345". include_poc: also query GitHub for public PoC/exploit repos (live). Input parameters: - `cve_id` (string, required) - `include_poc` (boolean) ### `check_technology` (~638 tokens) CVEs for a product and version Find vulnerabilities affecting a product across NVD (CPE) and OSV (package ecosystems), de-duplicated and ranked by priority/EPSS/CVSS. Distinct products that share a name are kept distinct. If one name maps to several VENDORS' unrelated products (e.g. "Sentry" → sentry, mobileiron, apache; "Envoy" → envoyproxy, enphase), the result is flagged `ambiguous` with `distinct_vendors` — pass `vendor=` to disambiguate. Always check each result's `match.products` (vendor:product) before trusting a hit. Distro builds: pass a banner or distro package version as-is ("OpenSSH_9.2p1 Debian-2+deb12u3", version="1:9.2p1-2+deb12u3", "nginx/1.22.1 (Debian)", "openssh (Alpine 3.20)" + "9.7_p1-r4", "OpenSSH_8.9p1 Ubuntu-3ubuntu0.10", "nginx/1.18.0 (Ubuntu)"). Each result then also gets `distro_fix`: Debian's / Ubuntu's / Alpine's own fixed build and, when your build is known, whether it is past it (distros backport fixes without changing the upstream version, so the upstream `affected` can say vulnerable on a patched host). Ubuntu banners don't name the release: `distro_context.release_basis` says how it was placed. Statuses: fixed / affected / unfixed / not_listed (the distro's record for the CVE lists other packages, not yours); CVEs the distro settled for your build rank after the rest. Read with each verdict: `affected.sources_disagree` (records disagree on whether your version is in range), `affected.ranges_belong_to` (the ranges are a separate component's own versions, e.g. a provider package: unconfirmed for yours), and a top-level `truncated` when a big product matches more records than are considered (exploited ones are always kept). Args: product: product or package name, e.g. "nginx", "Keycloak", "mlflow", "lodash", or a server banner. version: optional exact version (e.g. "1.18.0", or a distro package build) — filters to vulns whose affected range (CPE or package) includes it. ecosystem: optional package ecosystem filter, e.g. "Py… Input parameters: - `ecosystem` - `limit` (integer) - `product` (string, required) - `vendor` - `version` ### `hunt_plan` (~272 tokens) Rank a recon'd stack into a dig order Turn a recon'd stack into a ranked dig-order for authorized bug-hunting. For each discovered component, returns its top high-risk CVEs (KEV / CISA-SSVC- active / high-EPSS first) AND its `recurring_loci` — the bug classes (CWE) this product family repeatedly fails at, ranked by real in-the-wild exploitation — i.e. WHERE to look first and WHAT shape to expect. Components are ordered by their most-exploitable bug (`dig_rank`). Grounded in exploitation data, not model guesses; lays out facts for triage/where-to-look, never a payload. Banners go in verbatim ("OpenSSH_9.2p1 Debian-2+deb12u3", "Apache/2.4.62 (Debian)"): a Debian/Ubuntu/Alpine build adds `distro_fix`, and CVEs the distro already fixed in that build rank below the rest. Args: technologies: discovered stack, e.g. ["craftcms 4.4", "nginx", "keycloak"]. per_tech: how many top CVEs to surface per component (default 4). Input parameters: - `per_tech` (integer) - `technologies` (array, required) ### `observe` (~315 tokens) Scan a host's exposed stack Scan a host's exposed stack and join it to the CVE corpus — the recon workhorse. Fingerprints the homepage + JS bundles (recovering the backend identity and API endpoints homepage detection misses on SPAs), then ranks against live KEV / SSVC-active / high-EPSS into a dig-order. Fetches only public pages — authorized targets only. NON-BLOCKING: a scan takes ~1-4 min, so observe() never waits on it. A recent scan (<24h) returns status="ready" instantly. A cache miss KICKS a background scan and returns status="scanning" immediately — POLL by calling observe() again with the same host until it returns status="ready". Returns: \- status="ready": host stack + endpoints + dig_order + top_across_stack (the scan result), plus bounty_programs: public programs whose current scope lists this host. \- status="scanning": retry_after_seconds + last_scanned_at (call again after that delay). \- status="error": a guard/validation error. Args: host: hostname or URL in an authorized bounty scope, e.g. "auth.example.com". fresh: force a re-scan (kicks a new background scan even if a recent one exists). per_tech: top CVEs to surface per component (default 4). Input parameters: - `fresh` (boolean) - `host` (string, required) - `per_tech` (integer) ### `search_vulns` (~542 tokens) Search CVEs by concept, keyword or seed CVE Search the CVE corpus — one entry point, three retrieval modes picked from your arguments: \- query= a concept / technique / weakness (e.g. "SSO SAML assertion replay", "deserialization gadget chain", "server-side request forgery cloud metadata"). By default it FUSES full-text keyword search AND semantic mechanism-search, so you don't have to guess whether your phrasing is lexical or conceptual. order='relevance' = keyword only; order='similarity' = semantic only; order='severity' = fuse then rank P1>P4. \- cve_id= a seed CVE (e.g. "CVE-2021-44228") -> its mechanism-siblings across OTHER products (the "what else looks like this?" move). \- days= and/or product= (with NO query) -> the recent high-risk window (KEV / P1-P2 / high-EPSS); product= is CPE-name-resolved and each hit carries match.products. "Recent" = published in the window OR added to CISA KEV in it (an old CVE newly confirmed exploited counts); each hit says which (in_window / kev_added). A recency phrase inside query ("this week", "in the last 30 days", "today") is read as days=; \`interpreted_as` says how the query was read. Returns ranked cards (each with priority/KEV/EPSS/CWE) + total_matches for coverage; the 'mode' field reports which retrieval ran. You decide which matches matter. (For one product's version-resolved vulns use check_technology, for a whole stack hunt_plan; for how bugs like this were FOUND in disclosed reports use find_attack_approaches.) Args: query: free-text concept / keyword / CWE. cve_id: seed CVE for semantic mechanism-sibling search. cwe: optional weakness filter, e.g. "CWE-502" or "502". days: window in days: published OR added to CISA KEV within it. product: product filter for the recent-window mode (CPE-name-resolved, carries provenance). order: relevance | similarity | severity (default: fused when query is text). limit: max r… Input parameters: - `cve_id` - `cwe` - `days` - `limit` (integer) - `order` - `product` - `query` ### `find_attack_approaches` (~492 tokens) Find attack approaches from disclosed bounty reports Find how bugs *like this* were actually FOUND — retrieve real disclosed bug-bounty report mechanic-cards whose approach is closest (by mechanism) to your query or a seed CVE. The "what approach worked on a bug like this, on which program, and what did it pay" layer: grounded in real publicly-disclosed, paid HackerOne reports, each distilled to a transferable mechanic (bug_class / source / sink / trigger / impact) and embedded in the same space as the corpus. Use it to BORROW a proven attack approach for a target or CVE you're working — especially to get UNSTUCK: results are novelty-ranked to surface non-obvious moves over the common playbook. Give EITHER: query: a free-text approach/bug description, e.g. "SSRF via webhook URL to cloud metadata", "IDOR swapping an object id to read another tenant's data". cve_id: a seed CVE you're working — returns the human attack approaches that transfer to it. Optional: limit (default 10) caps the cards; bug_class filter (e.g. "SSRF") sharpens precision; days filters by disclosure recency; tried=["IDOR","XSS","SSRF"] = bug-classes you've ALREADY attempted: cards of those classes (and their common aliases, IDOR = object-level auth) are left out and near-synonyms pushed down, so you get the nearest approaches you HAVEN'T thought of (the "I've exhausted the obvious, what else?" move). capec="CAPEC-664" = constrain to a canonical attack-pattern class (CAPEC). Pass it ALONE (no query/cve) to pull the real disclosed mechanics for that pattern, ranked by bounty — the coverage-driven "give me proven moves for this attack class" retrieval. Each result carries its canonical 'capec' class(es), the transferable 'trigger', the program, the bounty paid, and whether that program is still active/in-scope. Complements search_vulns (CVEs by mechanism). Input parameters: - `bug_class` - `capec` - `cve_id` - `days` - `limit` (integer) - `query` - `tried` ### `find_continuations` (~358 tokens) Next moves from a hunt position When you're STUCK mid-hunt: describe your POSITION — the attacker state/capabilities you hold, stripped of product names — and get the CONTINUATIONS that worked from positions like it, matched against the full disclosed-report BODIES (the concrete step/payload/precondition), not just the distilled card. This is the "I have a messy pile of capabilities, what are my legal moves?" layer. position: a product-free statement of what you can already do, e.g. "a backend fetches a user-supplied URL during import/webhook and I can't read the response (blind)", or "I hold a low-priv token and can store config that is later rendered to an admin". The richer/sharper the position, the better — vague positions retrieve generic moves. Optional program: restrict to one program's reports (substring match on handle); limit (default 10) caps the moves. Returns concrete 'move_step' techniques from real reports — including non-obvious cross-class moves the by-card layer can't surface (e.g. credential-leak-on-redirect, request-smuggling desync). HARD CONTRACT: every result is status=UNVERIFIED — a LEGAL MOVE, never a confirmed bug. Each carries a 'decisive_check' you must verify against the target (read its code / fire a test) before claiming anything; the corpus generates the move, the TARGET decides if it survives. Complements find_attack_approaches (by-card mechanism) — this is the by-step, full-body layer. Input parameters: - `limit` (integer) - `position` (string, required) - `program` ### `assist_submission` (~252 tokens) Strengthen a bug-bounty submission Submission & escalation co-pilot for a bug-bounty finding. Paste your DRAFT finding (and what you already tried / couldn't achieve) and get a grounded brief built from the closest REAL disclosed reports: (1) precedent & validity — is this an accepted class, with citable reports (ammunition if it was disputed/closed); (2) what's novel/stronger about yours — what to lead with; (3) an escalation playbook INCLUDING moves you may NOT have tried, each with honest feasibility; (4) submission-framing tips. Every cited report URL is validated against the retrieved corpus — ungrounded citations are flagged in 'citations.ungrounded' with 'citations_grounded=false', so the brief can't smuggle in a fabricated precedent (this guards the citations only — never read it as a verdict on whether your finding itself is real). Optional 'query' overrides the retrieval text (default: the finding itself); limit (default 15) caps the prior-art reports. Complements find_attack_approaches (which returns the raw prior-art cards). Input parameters: - `finding` (string, required) - `limit` (integer) - `query` ### `program_outcome_prior` (~256 tokens) What lands on a bounty program At the START of an engagement on a bug-bounty PROGRAM, get a grounded prior over what bug classes have historically LANDED there — to decide what to look at first and what to skip. Built from real HackerOne disclosed reports: the class distribution for this program, each with LIFT over the global base-rate, sample size, and cited example reports; plus `lands_rarely` — the classes that land broadly across programs but almost never here (where NOT to spend the first hour). DESCRIPTIVE, not predictive: it reports what *landed*, never claims what you *will* find. It's a disclosure-selected sample, HackerOne-only (~379 programs with public disclosures), models bug-class not payout, and withholds a prior when the program has too few reports (an anecdote isn't a distribution). Pass a program handle or name, e.g. "gitlab", "shopify". Complements find_attack_approaches (mechanism transfer) and hunt_plan (CVE dig-order) — this is the minute-zero "where to start" prior an agent has no tacit target knowledge to form on its own. Input parameters: - `program` (string, required) ### `new_in_scope` (~458 tokens) What newly entered bug-bounty scope Find FRESH attack surface: bounty-eligible assets that entered a public bug-bounty program's scope in the last `days` (HackerOne, Bugcrowd, Intigriti, YesWeHack, mirrored daily), the least-hunted surface there is. Raw scope additions are mostly not new (in one week 57 of 80 were re-added after a removal), so each asset is checked against its program's own scope history: you get `new_asset` (never in this program's scope before) and `new_program` (the whole program first appeared in the window: a launch or a first public listing) assets; re-added, renamed and redacted ones are only counted in `filtered_out`. Additions only: removals are not listed. Per asset: `in_scope_since`, max severity, the host and its cached `stack` if observe has fingerprinted it (else a `stack_note` saying to call observe), and for a single GitHub repo its `repo_advisories` (advisories found under the repo name: a name match, check match.products; recent ones are variant-hunting seeds). Per program: platform, max bounty, safe harbor, and its HackerOne disclosed-report history (top classes, last disclosure; null on other platforms, where we hold none). Facts, not a ranking: you decide what is worth hunting. Hunt only programs you are enrolled in and follow each program's rules. Then: observe(host) for the stack, program_outcome_prior(program) for what lands there. Args: days: look-back window, 1-90 (default 7). platform: hackerone | bugcrowd | intigriti | yeswehack. asset_type: url | wildcard | api | source (code repositories) | mobile | other ... program: program handle or name, substring match (e.g. "openai", "cloudflare"). limit: max assets returned (default 50); `count` says how many qualified. Input parameters: - `asset_type` - `days` (integer) - `limit` (integer) - `platform` - `program` ### `verify_cve_claim` (~397 tokens) Fact-check a CVE claim Fact-check a claim about a CVE against the corpus — catch hallucinations before they ship. Verifies: does the CVE exist; does it affect the claimed product at the claimed version; is the severity right; is it actually KEV-exploited. Returns per-assertion verdicts (supported / refuted / unverifiable) with cited evidence. Use it to check what another agent (or a draft report) asserted, e.g. "Spring4Shell (CVE-2022-22965) is critical, actively exploited, and affects Spring 5.3.18" → verify_cve_claim("CVE-2022-22965", product="spring framework", version="5.3.18", severity="critical", exploited=True) (the version claim is refuted: fixed in 5.3.18). A distro build as product/version ("OpenSSH_9.2p1 Debian-2+deb12u3", or version "1:9.2p1-2+deb12u3") adds a second assertion with the distro's own verdict for that build. A CNA-rejected id comes back exists=true with rejected=true: treat any claim citing it as unsupported. Args: cve_id: the CVE/GHSA/PYSEC id being claimed about. product / version: optional — checks the affected-version claim in range. severity: optional — a CVSS number ("9.8") or label ("critical"/"high"/…). exploited: optional bool — the "actively exploited / in KEV" claim. claim: optional free text — returns evidence (summary, CWE) for you to judge. Input parameters: - `claim` - `cve_id` (string, required) - `exploited` - `product` - `severity` - `version` ### `corpus_stats` (~27 tokens) Corpus size and freshness Corpus size and data freshness (CVE / KEV / EPSS counts and latest timestamps). ### `search_public_code` (~172 tokens) Find public copies of a code string Search public repositories for an exact code string; return WHERE it appears. Use it to hunt vendored / copy-pasted copies of known-vulnerable code: search a distinctive line or symbol from the vulnerable function, then FETCH AND READ the hits to judge which copies are still unpatched, reachable, or just fossils/forks. Returns RAW search results only -- it makes no vulnerability judgment; that reasoning is yours. Args: code: an exact code string, e.g. "VP8LBuildHuffmanTable" or a distinctive line. lang: language filter for the code search (default "c"). limit: max hits to return (default 50). Input parameters: - `code` (string, required) - `lang` (string) - `limit` (integer) ## Diagnostics Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-vulntel-mcp/mcp#diagnostics ## Score history - 2026-11-05: 66 - 2026-11-04: 66 - 2026-11-03: 65 ## Common questions ### What is the vulntel MCP server? vulntel is an MCP server listed in the public MCP registry as com.vulntel/mcp. Free hosted CVE intel for bug-bounty agents: CVE fact-check, attack approaches from paid H1 reports. This page covers its hosted endpoint (https://mcp.vulntel.com/mcp). ### Is the vulntel MCP server safe to use? vulntel scores 66 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm. ### What tools does the vulntel MCP server expose? vulntel exposes 13 tools: enrich_cve, check_technology, hunt_plan, observe, search_vulns, and 8 more. Their descriptions and schemas cost roughly 4,318 tokens of context every time the server is loaded. ### Does the vulntel MCP server require authentication? No. We connected to vulntel without credentials and it answered, so anything it exposes is reachable by anyone who knows the address. ### Is the vulntel MCP server still maintained? vulntel is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced. ## Links - Remote endpoint: https://mcp.vulntel.com/mcp - Repository: https://github.com/rozetyp/vulntel-mcp - Website: https://vulntel.com/ - Changelog RSS feed: https://verifymcp.io/servers/com-vulntel-mcp/mcp.xml - Changelog JSON feed: https://verifymcp.io/servers/com-vulntel-mcp/mcp.json - HTML version of this page: https://verifymcp.io/servers/com-vulntel-mcp/mcp