Wazuh Vulnerability Report Automation: From Detector Inventory to a Weekly Patch Plan

The manual version of a weekly vulnerability report goes like this. Filter the Wazuh vulnerability inventory to the last week, export it, paste the CVE IDs into a spreadsheet, then check each one against NVD and the CISA KEV catalog. When the sheet is finally readable, the engineers still have to work out which packages to touch.

I automated it in n8n. Once a week the workflow pulls the findings from the Wazuh Vulnerability Detector, enriches every CVE, ranks them by how likely they are to be exploited, has a local model write the patch guidance, and emails an HTML report and a PDF.

This post walks through what each stage does and why, using a real report the workflow produced for one test host (WIndexer-VM). If you only want the workflow, it is on the store.

What the dashboard gives you, and what it does not

The Vulnerability Detector does the hard part: it inventories packages on every agent and matches them against vulnerability feeds. What it gives you is a list of findings, one per package per CVE.

That last detail is why the dashboard numbers feel inflated. One glibc CVE on an Ubuntu host shows up three times, once each for libc-bin, libc6 and locales. In the report below, one host produced 23 package-level findings, which came down to 12 distinct CVEs.

The dashboard also tells you severity and CVSS, which describe how bad a vulnerability would be if exploited. It does not tell you which of those CVEs attackers are actually using, and it does not turn the list into "run these upgrades". Those are the two things a weekly report has to add.

Stage 1: pull and deduplicate

The workflow starts on a weekly schedule and reads the Detector findings for the detection window, the last 7 days by default. The first real work is grouping: findings are collapsed by CVE ID, and each CVE keeps the list of packages and hosts it affects.

Everything after this step works on CVEs, not on package rows. That is what makes the counts in the report match what an engineer would count by hand, and the report footer says so, because the first question a reader asks is why the numbers differ from the dashboard.

Stage 2: enrich with NVD, KEV and EPSS

Each CVE is then looked up in three free sources:

• NVD for the description, the CVSS score and the reference links (vendor advisories, patches, exploit write-ups)

• The CISA Known Exploited Vulnerabilities catalog, which answers "is anyone exploiting this in the wild right now?"

• EPSS from FIRST, which gives the probability that the CVE will be exploited in the next 30 days

KEV is a yes or no. EPSS is a number between 0 and 1, and it changes daily as exploitation data comes in. Together they answer the question CVSS cannot.

Stage 3: rank by exploitation, not by score

This is the stage that changes what lands at the top of the report. In the sample report, the first card is CVE-2018-6952, a double free in GNU patch, rated High with CVSS 7.5. The second card is CVE-2026-10536, a use-after-free in libcurl, rated Critical with CVSS 9.8.

The High sits above the Critical because its EPSS score was 8.4% against 0.9%. Sorted by CVSS, the curl bug would lead. Sorted by likelihood of exploitation, the old patch bug does. Anything in the KEV catalog would go above both; that week there was nothing on it, and the summary says "0 actively exploited" in plain words so nobody has to infer it.

You may still decide the curl bug goes first on a particular host. The report gives you the CVSS and EPSS side by side on every card, so you can make that call with the numbers in front of you.

Stage 4: group the fixes by package

Engineers patch packages, not CVEs. So the last section of the report is a remediation plan by package: each package, its installed version, how many of this week's CVEs it carries, and which ones.

In the sample, the three glibc CVEs (CVE-2026-4046, CVE-2026-4437 and CVE-2026-5435) all sit on libc-bin, libc6 and locales at version 2.39-0ubuntu8.7. One upgrade of those packages clears three of the twelve CVEs, a quarter of the report. That line is worth more to whoever patches on Tuesday than the twelve cards above it.

Stage 5: let a local model write the guidance

For every CVE the workflow sends the NVD description, the affected packages and versions, and the host names to a model running in Ollama. It returns three things: a plain-language explanation, a one-line patch instruction, and a short list of remediation steps.

Running it locally matters for two reasons. The prompt contains your host names and exact package versions, which is a map of what is unpatched in your network, and none of that should go to a hosted API. And a weekly report that calls a model a dozen or more times would cost money every week on a paid API; with Ollama it costs nothing per token.

Read the steps before you forward the report. The model is good at turning an NVD paragraph into something a sysadmin can act on, but it does not know your environment. In the sample it suggested "identify and isolate" the host for a glibc bug in a deprecated DNS printing function, which is more than that bug calls for. The facts on each card (CVE, CVSS, EPSS, packages, versions, links) come from the data, and the guidance is a draft.

Stage 6: build the report and send it

The last nodes assemble the report: an executive summary with an overall risk level, four counters (open CVEs, actively exploited, Critical + High, affected hosts), a severity chart, one card per priority CVE with its reference links, and the remediation table. It is rendered as HTML for the email body and as a PDF attachment, then sent through Gmail or SMTP.

The summary at the top is written for someone who will read only that paragraph. For the sample week it reads: 12 open vulnerabilities across 1 host, 23 package-level findings, none on the KEV list, 12 Critical or High. A manager can stop there; an engineer scrolls to the table.

What you need to run it

• n8n, self-hosted or cloud

• Wazuh 4.x with the Vulnerability Detector enabled

• Ollama with a model pulled

• Gmail or an SMTP account for delivery

• No paid APIs: NVD, CISA KEV and EPSS are free

Import, connect your credentials, and run it once by hand. Your first report can be ready in about 15 minutes. There is a

of a full run if you want to see it before buying.

Get the workflow

The Wazuh Vulnerability Report workflow is $39.99, with setup documentation and a 7-day refund if it does not do what this post describes.

If you would rather not wire up Ollama and the credentials yourself, Done For You is $129 one-time: we install it in your environment, test it end to end and fix anything that breaks in the first 30 days. And because this workflow depends on Wazuh's vulnerability data, it is one of the ones a Wazuh upgrade can affect. Updates + Support ($39.99 a month) sends you the fixed version when that happens. More on why in What Breaks in Your n8n Security Workflows When Wazuh Upgrades.