vulntel

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). Complements find_attack_approaches (which returns the raw prior-art cards).

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. "PyPI", "npm", "Maven", "Go". vendor: optional CPE vendor filter to disambiguate a shared product name, e.g. vendor="sentry" (not mobileiron), vendor="envoyproxy". limit: max results.

Corpus size and data freshness (CVE / KEV / EPSS counts and latest timestamps).

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).

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: 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 find_similar_vulns.

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). 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.

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).

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).

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.

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.

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 a specific product's version-resolved vulns use 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 results.

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.