Vulnerability-Lookup (https://github.com/vulnerability-lookup/vulnerability-lookup) is an open-source platform (AGPL) for fast vulnerability lookup and correlation across many sources — CVE, EUVD, GHSA, OSV, CSAF/VEX, national CERTs — with collaborative annotation, sightings and coordinated disclosure. 6.0.0 is out today; two big additions this round.
Webhook notifications
Product notifications are no longer e-mail only. A subscription can push its reports to any HTTPS endpoint — a chat channel, a SIEM, a ticketing system — instead of, or in addition to, e-mail. HTTP method, custom headers and a payload template are all configurable, so the same mechanism feeds a generic JSON collector or the specific shape Mattermost/Teams/DingTalk/Telegram expect.
Targets are held to a strict outbound policy, enforced when the form is saved and again at delivery time: HTTPS on a standard port, no redirects, delivery pinned to the validated IP, private/loopback/link-local refused (IPv6 transition addresses judged by their embedded IPv4 destination), URL-shortener and dynamic-DNS domains rejected via the MISP warning lists, and URL paths redacted from failure logs.
Local exploit hazard
An implementation of the model from arXiv:2607.24618 (https://arxiv.org/abs/2607.24618), which turns an EPSS forecast into an exploitation risk estimate that accounts for your environment — compensating controls (globally or per attack vector), KEV policy weighting, and exponential or KEV-calibrated Weibull age decay.
- POST /api/exploit-hazard — a single vulnerability instance, resolved from a vulnerability id or from explicit values.
- POST /api/exploit-hazard/batch — aggregates a whole exposed set into the aggregate daily hazard, the expected number of exploitation events over the horizon, and the Poisson probability of at least one event.
The same model drives the notifications: reports are ordered by individual hazard and annotated with EPSS score, age and horizon probability. Each subscription can localize the estimates with its own parameters, and a daily standing exposure evaluation alerts on upward threshold crossings, listing the vulnerabilities whose remediation would lower the exposure most.
There’s a longer write-up on how the paper became running code in nine days: https://www.vulnerability-lookup.org/2026/08/11/local-exploit-hazard/
Also in this release
- A vulnerability credits index — credited researchers from CVE 5, OSSF and CSAF records, indexed and ranked at /credits/ with search and pivots from every advisory
- SSVC v2.0 decisions on the CVE page, extracted from every container (CNA and ADPs), normalized and attributed
- import_dump — bootstrap a fresh instance from the public NDJSON dumps (a one-time bootstrap, not a sync mechanism)
- EUVD: KEV catalog linking and a score-ordered EPSS index
- Security fixes: XSS in tag rendering, SSE stream gated on confirmed accounts, single-use activation/recovery tokens, outbound-URL policy on remote sync, and authenticated responses kept out of shared caches
- Project governance, maintainer list, roadmap and privacy documentation
Links
- Release notes: https://www.vulnerability-lookup.org/2026/08/13/vulnerability-lookup-6-0-0/
- Source: https://github.com/vulnerability-lookup/vulnerability-lookup
- Public instance operated by CIRCL: https://vulnerability.circl.lu/
Co-funded by CIRCL and by the European Union through the NGSOTI project.
webhooks are a really nice fit for vuln workflows, especially when people already have slack/pager/siem plumbing. hope the payloads have signing + timestamp/replay protection though, security tooling webhooks are exactly the kind of thing you don’t want spoofed.
webhooks are the part i’d probably use right away. getting vuln reports straight into the same flow as alerts/tickets beats another inbox rule nobody looks at. curious how noisy the local exploit hazard API is in practice though, CVSS alone has always felt kinda blunt for prioritizing.
webhooks are a really nice fit for this kind of workflow. i’d want signing/verification and some payload filtering pretty early though, otherwise every downstream secops tool ends up doing its own messy trust checks.
webhooks are the bit i’d use right away. getting vuln reports into slack/opsgenie/whatever beats another inbox rule nobody looks at, and the local exploit hazard api sounds pretty handy for cutting through the usual cve feed noise.
webhook notifications are gonna be super useful for vuln triage workflows. the local exploit hazard API is the part i’d poke at first though, feels like it could help cut through a lot of noisy CVE queues.
webhooks are a pretty big quality of life thing if your team already lives in Slack, Matrix, or a ticket queue. the local exploit hazard API sounds like the really useful bit though, since prioritizing vuln noise is usually where the pain is.
webhooks are a really nice add for this. email-only vuln alerts always end up buried, but pushing them straight into an ops queue or incident channel makes the data way more usable. curious to try the local exploit hazard API too, prioritization is still the annoying part.
