GitLab, Cisco, WordPress on the KEV List: Which CVEs Are About You?
On 29 October 2026 CISA added a GitLab flaw, CVE-2026-97229 with a CVSS score of 10, to its Known Exploited Vulnerabilities (KEV) catalog, after attackers tried it against targets including Alpine Linux. The same batch added CVE-2026-76418 in Cisco ASA and FTD, and on 3 November WordPress Core CVE-2026-119977 followed (The Hacker News).
Each of those headlines lands in a year that already set a record: 48,185 CVEs were published in 2025 (Jerry Gamblin via The Stack). Nobody reads them all, and nobody should. The useful question is narrower: which of these are about us, and would we notice if someone used one?
Step 1: separate "exploited" from "published"
Most CVEs are never exploited. The KEV catalog lists the ones that are, and EPSS scores how likely the rest are to be exploited in the next 30 days. Together they turn a list of tens of thousands into a short list you can act on this week.
LogPulse pulls KEV every six hours, NVD every two hours and EPSS once a day into its Intelligence Hub, so the priority of a CVE is already known before you open it.
Step 2: match it against what you actually run
A CVE only matters if the affected version runs somewhere you own. That answer lives in your vulnerability scans, not in the advisory. If you send the output of Trivy, Grype, Snyk or Clair to LogPulse with the sourcetype `security_vulnerability`, the findings are matched against the CVE knowledge base every six hours. A GitLab image with the vulnerable version then shows up as exposed, with the KEV and EPSS context next to it.
Without scans there is no exposure answer, and we would rather say that than guess. Firmware on edge devices such as firewalls is usually not in container or package scans, so check those vendors' advisories directly.
Step 3: make sure something is watching
Patching is the fix, and LogPulse does not replace it. But patches take days and attackers take hours, so the next question is whether a detection would see an attempt. In LogPulse a hub rule names the log sources it needs. If a rule cannot fire because, for example, your GitLab or firewall logs are not coming in, the Security page tells you which source is missing and how to connect it.
New rules from the hub only go live after a person has reviewed them and the rule passed its test in the Detection Lab. No AI publishes a rule on its own.
Step 4: look back, not only forward
When a CVE lands on KEV, exploitation has usually been going on for a while. LogPulse runs a retro-hunt when new indicators or rules arrive: known attack IPs are checked 30 days back in your logs, new rules 7 days back. If the attempt was already in your data, you find out now instead of never.
Try it on your own systems
The free plan includes security monitoring and needs no credit card. Connect a scan and one log source, and the next time a CVE is in the news you can answer the question in minutes. See how the chain works on Threat intelligence.