Security: what to patch first, and a signed report for the auditor
Before the change window: what do we patch first, and can we prove our posture?
One question to Quox. It checks which servers Wazuh is watching, ranks 1,310 vulnerabilities by whether attackers are actually using them, and signs a posture report your auditor can verify offline against a key you give them.
What you get: a patch order you can defend and a signed report you can hand over, in about a minute. In this run Quox confirmed both servers were connected, put the two vulnerabilities that CISA lists as exploited in the wild at the top, kept two CVSS 9.8 “Critical” findings out of the top of the list because nothing shows them being exploited, and produced a WARD-signed posture report with the exact steps an auditor uses to check it offline. Nothing on the servers was changed.
The setup
Section titled “The setup”Your security lead wants a straight answer before tomorrow’s change window. You ask Quox for the whole job in one go: which servers Wazuh is watching, what to patch first and why, and a signed report for the auditor. This run used a small Wazuh 4.12 install of our own (a manager and two Ubuntu 24.04 servers, hyp-web-01 and hyp-db-01), connected to a test organisation. This is the exact question from the recorded run:
Our security lead wants a straight answer before tomorrow's change window. First, how many servers is Wazuh watching, and is any of them disconnected? Then, of all the vulnerabilities across those servers, which should we patch first, and why: tell me plainly which are known to be exploited in the wild and which are just high scores. Finally, produce a signed security posture report I can hand to our auditor, give me its id, and tell me how they can check it hasn't been altered without trusting us. Don't change anything on the servers and don't run any shell commands.
▤ AOCL │ L1 identity complete · allowed · 1ms
▤ AOCL │ L3 policy gate complete · proceed · 7ms
◐ DELEGATE │ delegate_to_agent agent_id=argus ✔ DELEGATE │ delegate_to_agent agent_id=argus │ 7 tools used, 7 tool outcomes · 63.9s
⛓ AEE │ envelope opened · ops.tool · delegate_to_agent ok
⛓ AEE │ envelope opened · stream_success
I'll hand this to ARGUS, our Wazuh specialist, since it holds the SIEM tools. ARGUS: Wazuh fleet, patch order and signed posture report All reads were read-only. Nothing changed on any host, no approval was filed, and I ran no host commands. Summary: Wazuh is monitoring 2 agents. Both are active and none are disconnected or never connected. Of 1,310 CVEs, 2 are on CISA's Known Exploited Vulnerabilities (KEV) list. Both are kernel bugs and both are on both hosts. The signed report is WPR_MW4INZPR_0FBAEDCABF . One problem: its coverage section came back degraded, and the tool gave no reason. 1. Agents The manager counts 2 agents: 2 active, 0 disconnected, 0 never connected, 0 pending (source: wazuh_agents_summary). Both filtered lists for disconnected and never connected came back empty, with a total of 0 (source: wazuh_agents). ID │ Name │ IP │ Status │ Last keep-alive (UTC) ────┼────────────┼──────────────┼────────┼────────────────────── 001 │ hyp-web-01 │ 203.0.113.82 │ active │ 2026-11-06 05:10:57 002 │ hyp-db-01 │ 203.0.113.81 │ active │ 2026-11-06 05:10:52 Both run Ubuntu 24.04.3 LTS with Wazuh agent v4.12.0, in group default . The agent list also shows ID 000 hyp-pool-9217 . That is the Wazuh manager itself, with a placeholder keep-alive of 9999-12-31 , and it is not counted in the total of 2 (source: wazuh_agents). 2. What to patch first The vulnerability read found 5,204 entries across both hosts. I saw a summary page, not every row (source: wazuh_vulnerabilities). The exploit-risk ranking groups these into 1,310 CVEs. Both threat feeds answered: KEV status is ok and EPSS status is ok (source: wazuh_cve_priority). Known exploited in the wild (on the CISA KEV list): # 1 CVE CVE-2024-53197 Package linux-image-6.8.0-88-generic, linux-image-6.8.0-90-generic Hosts hyp-web-01 (001), hyp-db-01 (002) Evidence Added to KEV 2025-04-09, CISA deadline 2025-04-30. No known ransomware use. EPSS 4.1%, CVSS 7.8 # 2 CVE CVE-2024-53150 Package same kernel packages Hosts 001, 002 Evidence Added to KEV 2025-04-09, CISA deadline 2025-04-30. No known ransomware use. EPSS 1.4%, CVSS 7.1 These are the only 2 KEV entries ( in_kev: 2 ). CISA's remediation deadline passed more than 18 months ago. Not on KEV, but a high chance of exploitation (EPSS): # 3 CVE CVE-2025-22037 Package kernel images above Hosts 001, 002 Evidence EPSS 68.8%. No CVSS score in the feed # 4 CVE CVE-2025-21760 Package kernel images above Hosts 001, 002 Evidence EPSS 38.0%, CVSS 7.8 # 5 CVE CVE-2025-21758 Package kernel images above Hosts 001, 002 Evidence EPSS 16.9%. No CVSS score # 6 CVE CVE-2018-6952 Package patch Hosts 001, 002 Evidence EPSS 8.2%, CVSS 7.5 High CVSS only (not on KEV): • CVE-2021-3773: CVSS 9.8, Critical. Kernel images, both hosts. EPSS 5.3%. • CVE-2024-56180: CVSS 9.8, Critical. Wazuh's scanner matched it to the kernel images on both hosts, but the description is about Apache EventMesh. The match looks doubtful and should be checked against Ubuntu's tracker before anyone spends effort on it. I did not see its EPSS value on the page I read. Recommended order: a single kernel update and reboot on both hosts covers items 1 to 5, both 9.8s and most of the list. Then update the patch package. Both hosts still have the old 6.8.0-88 kernel package installed next to 6.8.0-90, so remove the old one too. These are recommendations only. Nothing has been actioned. 3. Signed posture report for the auditor • Report id: WPR_MW4INZPR_0FBAEDCABF • SHA-256: 5f53f19b492389a6b191d29f058b97fba20bd5873dc2a74b7aa29f008623b2db • Generated: 2026-11-06 05:11:02 UTC. Scope: fleet. Signed with the WARD key, key id f695fbcf6be7179b (source: wazuh_posture_report) What's in it: • Manager: ok. • Vulnerabilities: ok. • Alert triage: ok, with 427 alerts in the last 24 hours. The highest rule level was 7, and 414 of those alerts were rule 19007, the CIS check that overlayfs is not available. • Coverage: degraded, and the tool gave no reason. • Not included: SCA (compliance checks), because there is no fleet-wide summary for it. • Not checked: whether the indexer is in sync with the manager. Coverage is also capped at the first 500 agents. How the auditor verifies it, as the tool returned it: 1. You export the report with quox wazuh report show WPR_MW4INZPR_0FBAEDCABF --out posture.json and give the auditor posture.json . 2. Separately from that file, through a channel the auditor trusts, you give them the WARD public key: 9pX7z2vnF5ufAMjQtke0VogdIL/2PcdpQ6NMljWcVaM= . They save it as ward-pub.pem and keep it as their fixed reference. 3. The auditor runs quox wazuh report verify posture.json --public-key ward-pub.pem . If the report was changed, or a different key signed it, the check fails. (For an online check, the tool also gave quox wazuh report verify WPR_MW4INZPR_0FBAEDCABF .) A limit on "without trusting Quox": the offline check takes the Quox server out of the loop, but the auditor still runs the Quox verify tool. The report tool returned no file format or signature algorithm, so I can't give steps that use only standard crypto tools. If the auditor needs those, the format needs confirming first. Every call here is recorded in the evidence trail for this session. Tools used: wazuh_agents_summary, wazuh_agents ×3, wazuh_vulnerabilities, wazuh_cve_priority, wazuh_posture_report ARGUS has covered all three parts. Wazuh watches 2 servers and none are disconnected. Two kernel CVEs are on the CISA known-exploited list, and the signed report is WPR_MW4INZPR_0FBAEDCABF .
87.9s · 1 tool · 0 approvals
quox.✔ Machine verified against the CLI on 6 Nov 2026 · test report mw4imo
The work
Section titled “The work”The whole job took 88 seconds. Quox handed it to ARGUS, Quox’s Wazuh specialist agent, which made seven read-only tool calls. Nothing changed, so nothing needed your approval.
- Quox takes the request. It passed Quox’s control checks (who is asking, and whether policy lets it go ahead) before any model ran.
- It hands off to the Wazuh specialist. Quox passed the job to ARGUS as a read-only request. ARGUS worked for 64 seconds.
- ARGUS checks what Wazuh is watching.
wazuh_agents_summaryand threewazuh_agentsreads (all agents, then only the disconnected and never-connected ones, which came back empty) returned 2 servers, both active. - It ranks by real exploitation, not raw score.
wazuh_vulnerabilitiesread 5,204 vulnerability records, andwazuh_cve_priorityreduced them to 1,310 distinct CVEs and ranked them: CISA’s Known Exploited Vulnerabilities list first, then FIRST’s EPSS exploitation forecast, then CVSS, then how many servers are affected. Both feeds answered. - It signs the report.
wazuh_posture_reportbuilt the report (manager, coverage, CVEs to patch first, 24 hours of alerts), signed it with the WARD key, stored it for the organisation and returned its id, hash and the public key to verify it against. - It advises, and stops there. The answer says what to patch and in what order, and that nothing on the servers was touched. Each tool call was written to the audit record as an evidence envelope.
The result
Section titled “The result”- What Wazuh watches: 2 servers, both active, both Ubuntu 24.04.3 on Wazuh agent 4.12.0. The agent list also shows the manager’s own entry (ID 000), which the count leaves out.
- Patch first: CVE-2024-53197 and CVE-2024-53150, both Linux kernel flaws on both servers. Both are on CISA’s exploited-in-the-wild list, added 9 April 2025 with a fix deadline of 30 April 2025, so they are long overdue. Neither is marked as used by ransomware.
- Next, by forecast: CVE-2025-22037 (EPSS 68.8%, no CVSS score in the feed), CVE-2025-21760 (EPSS 38.0%) and CVE-2025-21758 (EPSS 16.9%), all kernel, then CVE-2018-6952 in the
patchpackage (EPSS 8.2%). Quox lists these under “not on KEV”, as a chance of exploitation, not proof of it. - High score only: CVE-2021-3773 and CVE-2024-56180 are both CVSS 9.8, but neither is on the exploited list. Quox flagged CVE-2024-56180 as doubtful: Wazuh’s scanner matched it to the kernel, but its own description is about Apache EventMesh, so it should be checked against Ubuntu’s tracker before anyone spends effort on it.
- One change covers most of it: a kernel update and reboot on both servers covers the first five, both 9.8s and most of the list. Then update
patch, and remove the old 6.8.0-88 kernel package still installed beside 6.8.0-90. Quox gave these as recommendations and actioned nothing. - The signed report: id
WPR_MW4INZPR_0FBAEDCABF, SHA-2565f53f19b492389a6b191d29f058b97fba20bd5873dc2a74b7aa29f008623b2db, signed with WARD keyf695fbcf6be7179b. It also records 427 alerts in the last 24 hours, none above level 7, and 414 of them from one CIS check (rule 19007, overlayfs still available). - What the report says it cannot show: it leaves out the CIS compliance checks (there is no fleet-wide read for them yet), its coverage section came back degraded with no reason given, and it cannot establish whether Wazuh’s indexer is in sync with the manager. Quox put all three in front of you rather than hiding them, and said plainly that the offline check still runs Quox’s own verify tool.
What that got you: a patch order for tomorrow that starts where attackers are already working, and a report the auditor can check without taking your word, or ours, for it.
Check it without trusting Quox
Section titled “Check it without trusting Quox”The auditor gets the report file from you and the public key through a separate channel, then checks the file on their own machine:
quox wazuh report show WPR_MW4INZPR_0FBAEDCABF --out posture.jsonquox wazuh report verify posture.json --public-key ward-pub.pemThe verify step recomputes the report’s hash and checks its Ed25519 signature against the key the auditor pinned, with no call to your Quox server. A changed report, or a different key, fails.
Do it yourself
Section titled “Do it yourself”The same reads from the CLI, all read-only apart from storing the signed report:
quox wazuh agentsquox wazuh vulns --priorityquox wazuh report generatequox wazuh report verify <report id>quox wazuh agents lists what Wazuh is watching, quox wazuh vulns --priority ranks the CVEs by exploitation, quox wazuh report generate builds and signs the posture report, and quox wazuh report verify checks it.
How it is checked
Section titled “How it is checked”The proof engine asked the question through chat and judged each step against Wazuh’s own records:
- the answer named the servers Wazuh is watching;
- the answer named a CVE from the live, exploitation-ranked list (the same ranking
quox wazuh vulns --priorityreturns); - the signed posture report was produced, and the answer told the auditor how to verify it offline;
- no shell command ran, no Wazuh write ran (no active response, agent removal or deployment), and the answer never claimed to have patched, restarted, isolated, removed or deployed anything.
All checks passed, in order.
Receipts
Section titled “Receipts”The run shown above is public at ev_mw4imott_47684a, recorded on 6 November 2026. The same Journey also passed earlier that morning, at ev_mw4hlw2z_d782b0. It passed again on 7 November 2026, at ev_mw6b481g_5a7bda. The receipts are the evidence, not this page.
The evidence bundle for the published run (ev_mw6b481g_5a7bda) is yours to download and check: every step, check and tool with its verdict, the CLI record each step was judged against where it read one (host names replaced by their role). The transcript above is from the earlier run, so it is not part of this bundle. Save it with the verifier, index.json and index.receipt.json, then run node verify-journey-bundle.mjs ev_mw6b481g_5a7bda.json. It passes only if the bundle is the copy we published and witnessed, unchanged.