A vulnerability queue becomes harder to use when every CVE is presented with the same urgency. CISA’s Known Exploited Vulnerabilities (KEV) catalog provides a useful signal because it records vulnerabilities that CISA says have been exploited in the wild. It is not an asset inventory, a scanner result, or a patch instruction. It is a prioritization input that still has to be matched to the products an organization actually owns.
On September 2, 2026, CISA added seven entries to KEV, including entries for Starlette, Kestra OSS, LiteLLM, Artifactory, SonicWall SMA1000 Appliances, Sangoma Switchvox, and another SonicWall SMA1000 issue. A daily report that shows only additions lets a responder start with a bounded list, then ask the questions that matter: do we run the affected product, which version is installed, is it exposed, does the vendor provide a fix, and does the catalog call for forensic triage?
This guide downloads CISA’s JSON feed into a local working directory and filters it by the feed’s dateAdded field. The result is a tab-separated report suitable for attaching to a ticket or feeding into an internal workflow. It deliberately does not scan a network, query an appliance, or claim that a listed CVE affects a particular environment.
Treat the catalog as an input, not an inventory
CISA publishes the catalog as a web page, CSV, JSON feed, and JSON Schema. The JSON form is the best fit for a small repeatable check because it contains structured fields such as cveID, vendorProject, product, vulnerabilityName, dateAdded, dueDate, requiredAction, and forensicTriage.
The dateAdded field answers a narrow operational question: which entries entered the catalog on a given catalog date? It does not mean the underlying vulnerability was disclosed that day, that a patch was released that day, or that exploitation began that day. Keep the distinction intact in incident notes. Use the vendor advisory to determine affected versions and remediation, then use the local asset inventory to determine exposure.
CISA’s September 2 alert is a useful example of why a delta view helps. Seven new entries are small enough to triage deliberately. The feed also supplies different due dates and triage flags. A single bulk patch window may be the right response for some assets, while an entry marked for forensic triage deserves an incident-response decision before routine maintenance begins. CISA’s BOD 26-04 implementation guidance applies directly to federal civilian agencies, but its sequence—scope, preserve evidence, stabilize, contain, analyze, and decide whether to escalate—is a useful defensive model for any organization.
Download a feed copy
Work outside a repository that publishes a site or application. The feed is changing data, so retain the downloaded copy with the time of retrieval and its checksum. That makes a later report reviewable even after CISA publishes another catalog version.
mkdir -p kev-delta
cd kev-delta
curl --fail --silent --show-error --location --proto '=https' --tlsv1.2 \
https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
--output kev.json
sha256sum kev.json
--fail makes an HTTP error a command failure rather than saving an error page as JSON. --location follows CISA redirects, while the protocol restriction prevents a redirect to a non-HTTPS scheme. The checksum is not a vendor signature; it records exactly which downloaded feed the report used. Do not treat it as a substitute for transport security or provenance verification.
Validate the data before writing a report. Python’s standard library is sufficient for a basic syntax check:
python3 -m json.tool kev.json >/dev/null
A zero exit status means the file is parseable JSON. It does not validate every field against CISA’s schema, so use the published schema if a pipeline will make enforcement decisions from this data.
Make the daily delta explicit
Save this script as kev_delta.py. It reads a local copy rather than fetching during parsing. Separating download from parsing makes retries predictable and lets an operator inspect the captured feed before distributing results.
#!/usr/bin/env python3
"""Report CISA KEV entries added on one catalog date from a local feed copy."""
from __future__ import annotations
import argparse
import json
from pathlib import Path
parser = argparse.ArgumentParser()
parser.add_argument("feed", type=Path)
parser.add_argument("--date", required=True, help="YYYY-MM-DD from KEV dateAdded")
args = parser.parse_args()
payload = json.loads(args.feed.read_text(encoding="utf-8"))
vulnerabilities = payload.get("vulnerabilities")
if not isinstance(vulnerabilities, list):
raise SystemExit("feed has no vulnerabilities array")
matches = [
item for item in vulnerabilities
if isinstance(item, dict) and item.get("dateAdded") == args.date
]
for item in sorted(matches, key=lambda row: str(row.get("cveID", ""))):
print(f"{item['cveID']}\t{item.get('vendorProject', '')}\t{item.get('product', '')}\t{item.get('vulnerabilityName', '')}")
print(f"COUNT\t{len(matches)}")
Run it with the date being reviewed:
python3 kev_delta.py kev.json --date 2026-09-02
The validation run used the CISA JSON feed retrieved on September 5, 2026 and Python 3.13.5 on Linux amd64. It returned seven records, matching CISA’s September 2 alert. This is a report of catalog content, not evidence that any product was present or vulnerable:
CVE-2026-48710 Kludex Starlette Kludex Starlette HTTP Request/Response Smuggling Vulnerability
CVE-2026-49869 Kestra Kestra OSS Kestra OSS OS Command Injection Vulnerability
CVE-2026-59822 BerriAI LiteLLM BerriAI LiteLLM Improper Authentication Vulnerability
CVE-2026-82329 JFrog Artifactory JFrog Artifactory Improper Authentication Vulnerability
CVE-2026-83548 SonicWall SMA1000 Appliances SonicWall SMA1000 Appliances Server-Side Request Forgery Vulnerability
CVE-2026-83549 SonicWall SMA1000 Appliances SonicWall SMA1000 Appliances OS Command Injection Vulnerability
CVE-2026-9586 Sangoma Switchvox Sangoma Switchvox SQL Injection Vulnerability
COUNT 7
A run for September 5 against that captured September 4 catalog returned COUNT 0. That second result is important: an empty report is an expected outcome, not a script failure. Schedule the download and report once per day, retain the raw feed privately for the period required by the response process, and alert only when the count is nonzero.
Turn a catalog hit into a safe response
Do not immediately patch every matching product based only on a vendor name. First match the CVE ID to an approved asset record, package inventory, SBOM, or authenticated management source. Record the installed version, owner, business role, internet exposure, and maintenance constraints. For a cloud service, establish whether the provider owns remediation or whether a customer-managed component is affected.
Then read the requiredAction, dueDate, forensicTriage, and notes fields in the individual KEV entry. Follow the linked vendor advisory for fixed versions and configuration-specific mitigations. Preserve relevant logs and volatile evidence before a change when the catalog entry or the organization’s response policy requires triage. Do not use this report to run intrusive probes against appliances or applications; confirmation belongs in an authorized, product-specific procedure.
Finally, close the loop. Record the decision for every owned match: not present, not affected by version or configuration, mitigated, patched, isolated, or escalated. Store the catalog version, retrieval time, and checksum alongside that decision. The useful outcome is not a longer CVE list. It is a small, reviewable daily signal that connects CISA’s exploitation evidence to an organization’s own inventory and response process.