this post was submitted on 13 Aug 2026
4 points (100.0% liked)

cybersecurity

6441 readers
2 users here now

An umbrella community for all things cybersecurity / infosec. News, research, questions, are all welcome!

Community Rules

Enjoy!

founded 3 years ago
MODERATORS
 

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

Co-funded by CIRCL and by the European Union through the NGSOTI project.

top 7 comments
sorted by: hot top controversial new old
[–] clee89@lemmy.world 1 points 4 days ago

webhooks are the part i'd probably use first. getting vuln reports straight into an existing incident workflow beats yet another inbox rule, and the local exploit hazard API sounds way more useful than staring at CVSS alone.

[–] clee89@lemmy.world 1 points 4 days ago

webhooks are the bit i'd use first. getting vuln reports straight into slack/pager/whatever beats yet another mailbox nobody checks, and the local exploit hazard thing sounds way more useful than staring at CVSS scores in isolation.

[–] clee89@lemmy.world 1 points 4 days ago

webhooks are the bit i’d probably use first. dumping vuln reports straight into slack/jira/whatever beats yet another security inbox nobody checks until friday.

[–] clee89@lemmy.world 1 points 4 days ago

webhooks are the part that’d get me to actually wire this into a workflow. pushing vuln reports straight into slack/matrix/tickets is way more useful than another email pile, and the exploit hazard api sounds handy if it helps sort real priority from cve noise.

[–] clee89@lemmy.world 1 points 4 days ago

webhooks are the bit i’d actually use here. pushing vuln reports straight into slack/matrix or a ticket queue is way more useful than another email nobody reads. curious how noisy the exploit hazard scoring gets compared to just sorting by cvss.

[–] clee89@lemmy.world 1 points 4 days ago

webhooks are way more useful than email-only for this stuff. the local exploit hazard api sounds like the part i'd actually use day to day, since cve feeds get noisy fast without some kind of prioritization.

[–] clee89@lemmy.world 1 points 4 days ago

webhooks are the part i'd use immediately, especially for dumping vuln reports into slack or a ticket queue. the local exploit hazard API sounds useful too, but i'd want to tune it hard before letting it drive priority by itself or it's gonna get noisy fast.