24b2e8ec4ba38a08636b85f1412b2ee22a1bef4d
579
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  vulncheckandClaude Opus 5
|
24b2e8ec4b |
fix(assets): Netdisco was missing from the source filter, and its switches counted as Manual
The inventory filter had no NETDISCO option, so neither the list nor the CSV export (which honours the same filter) could be narrowed to the switch estate. The filter keys on the netdisco_device_ip pin rather than the creation-time source enum — same rule as vCenter and IGEL — otherwise every switch Wazuh or Nessus registered first drops out. The MANUAL branch now excludes them too: without a scanner linkage of its own, a Netdisco switch was answering as "genuinely manual". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014bJSiCMEPYQYdi6emTDRj2 |
||
|
vulncheckandClaude Opus 5
|
62f4b0b76c |
fix(netdisco): a device with no name became the asset "192", and pulled the next one onto it
The IP fallback for a nameless device went through `.split(".")[0]` — the
short form of a hostname, which on an address leaves the first octet. That
name was also a match candidate, so the second nameless device in the same /8
found the first one's asset by hostname and was written onto it: one row with
a LANCOM router's vendor and a netgear switch's firmware.
A short form is now only derived from a real device name; a nameless device is
its full canonical address. Assets an earlier sync named after the first octet
of their own pinned IP are renamed on the next sync, so the existing rows heal
without an operator touching them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014bJSiCMEPYQYdi6emTDRj2
|
||
|
vulncheckandClaude Opus 5
|
2b4cf2f78f |
docs(netdisco): Testertext um den Extreme-Teil erweitert
Beide Fassungen. Der Punkt, der oben steht und nicht im Nebensatz: ob Netdisco die EXOS-Zeile so ausliest, wie die Zuordnung es annimmt (vendor "extreme", os "xos", Version aus dem sysDescr), ist von hier aus nicht pruefbar - das braucht ein echtes Geraet. Der Testertext sagt das ausdruecklich, nennt die Herkunft der Annahme (SNMP::Info Layer3::Extreme) und macht daraus einen konkreten Handgriff: Asset-OS muss "ExtremeXOS" heissen und die Version blank sein, sonst die deviceinventory-Zeile schicken. Sonst sieht "keine Findings" aus wie "sauber". Dazu die zwei Dinge, die beim Testen sonst als Fehler gelesen wuerden: dass Extreme im Gegensatz zu Cisco eine Fix-Version angibt (verglichen statt exakt nachgeschlagen), und dass die alten EXOS-CVEs sofort kommen, die 2026er aber erst nach dem Indexbau - NVD hat fuer die noch keine CPE-Eintraege. VOSS/ERS steht als eigener Pruefpunkt drin, nicht nur unter "bewusst nicht drin": dort kann nur etwas FALSCHES auftauchen, und genau das soll jemand mit echten Geraeten gegenpruefen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
vulncheckandClaude Opus 5
|
0bc08a6cc6 |
feat(netdisco): Extreme Networks EXOS switches, floored ranges
The third firmware line on the Netdisco path, and the one the connector's
stated scope still listed as "needs its own curated matching". An EXOS switch
(an X440G2 on 31.7.2.4, say) was inventoried as an asset and given no CVE
verdict at all.
Extreme is the plain case of the three, and the pass exists mainly for the
reconcile - a switch carries no software inventory, so the app scan's own
reconcile never reaches it. Versions are dotted numbers and the CNA writes
proper ranges, every one of them FLOORED. CVE-2026-8169 states four on one
record: 0 -> <31.7.4, 32.0.0 -> <32.7.4.15, 33.0.0 -> <33.1.100, 33.2.0 ->
<33.7.1, with defaultStatus "unaffected" - so unlike Cisco's records a release
outside all four is one Extreme judged and cleared. _ranges_from_affected reads
that as it stands, which is why there is no Extreme branch in the index build.
The one deliberate difference from the Aruba pass is that Aruba's branch guard
is NOT applied. HPE leaves the floor implicit and writes one range per branch,
so an unfloored "below 10.17.1021" there is a record about 10.17 and nothing
else. Extreme writes the floor itself, including the literal version "0", which
is the vendor saying every release below 31.7.4 whatever train it is on -
guarding that entry by branch would drop exactly the switches it is about.
Both sources, and here the NVD half is the load-bearing one: Extreme's CNA only
started filing in 2025, so every earlier EXOS CVE is a MITRE record whose
affected[] is {vendor: "n/a", product: "n/a", version: "n/a"} and carries no
structured data at all (verified 08.09.2026 on CVE-2023-43121 and
CVE-2024-27453). NVD also files the same firmware under TWO product names and
splits the CVEs between them, so both are queried - verified live the same day:
extremexos answers CVE-2024-27453, CVE-2020-18305 and the 2017 batch; exos
answers CVE-2023-43118..43121 (the Chalet traversal and privilege escalation)
and none of them appear under the other name. The reverse direction is the 2026
batch: CVE-2026-8169 and -8170 were still "Awaiting Analysis" at NVD with zero
CPE entries while Extreme's own records already stated all four ranges.
The product anchor matters for the same reason it did for Cisco: Extreme files
Fabric Engine (VOSS), ExtremeControl, ExtremeCloud IQ - Site Engine, Extreme
Platform ONE, ExtremeGuest Essentials and ExtremeCloud Universal ZTNA under the
one vendor string, and every one of them numbers releases in a scheme that
looks like a switch's ("25.5.12", "9.2", "26.02.11").
Two normalisations, both at the connector: SNMP::Info reads the version out of
sysDescr, so a row can carry the whole sentence, and a patch build spells
itself "22.7.1.1-patch1-11". The tag is dropped because neither source ever
states one as a bound - and Extreme fixes these by moving to the bound's
release, not by patching below it. The rule is aruba_version's, called rather
than copied, because it is genuinely the same rule.
Fabric Engine (VOSS) is deliberately out, and that is an INVENTORY limit rather
than a data one - both sources carry CVE-2025-11192. SNMP::Info has no VOSS
class, so a VSP is classed as Layer3::Passport and answers os "passport",
vendor "avaya" - precisely what an Avaya/Nortel ERS switch answers, whose 5.9.x
firmware is not Fabric Engine. Nothing else on the row separates them, and
"before 9.3" handed to an ERS numbered 5.x matches every one of them. Likewise
ExtremeWare (slug "extremeware"): a different product line whose NVD bounds
stop at 11.1. Both get the asset and no verdict.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
vulncheckandClaude Opus 5
|
a65747d365 |
docs(netdisco): Slack-Fassung als Nachricht an den Kollegen
Die Slack-Datei war eine unpersoenliche Ankuendigung; sie geht aber an den Kollegen, der die Cisco-Infos geschickt hat. Jetzt als Antwort formuliert: sein Geraet und seine CVE-Listen namentlich, die Bestaetigung dass seine Vorgabe (nur NVD und CVEListv5, Cisco-Advisories aussen vor) genau so umgesetzt ist — samt dem Beleg, dass sie richtig war: seine IOS-XR-Charge existiert bei NVD noch gar nicht. Dazu, was ihn beim Testen sonst irritieren wuerde: keine Fix-Version am Finding und warum, der Indexbau vor dem ersten Sync (XE sofort, XR erst danach), und der "os x"-Nebenbefund als eigener Pruefpunkt. Die ausfuehrliche TESTERTEXT.md bleibt unpersoenlich — die ist fuer alle. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
vulncheckandClaude Opus 5
|
ec7572ddd0 |
docs(netdisco): Testertext um den Cisco-Teil erweitert
Beide Fassungen auf den Cisco-Stand gezogen: warum bei IOS XE/XR exakt nachgeschlagen statt verglichen wird (beide Quellen zaehlen die Releases einzeln auf, 267 bzw. 268 fuer CVE-2026-20267), was daraus folgt (keine Fix-Version am Finding, ein nicht gelistetes Release wird nicht gemeldet), warum klassisches IOS draussen bleibt, der "os x"-Nebenbefund, und der Hinweis auf den Indexbau — v33 heisst, dass der erste Sync nur die NVD-Haelfte macht, was bei IOS XR sichtbar ist und bei IOS XE nicht. Testpunkte auf 13 erweitert: der Router aus dem Feldbericht mit seiner erwarteten CVE-Liste, ein Gegentest auf einem anderen Rebuild derselben Zeile (die Listen muessen sich unterscheiden), keine macOS-CVEs auf Netzwerkgeraeten, und die dritte Offline-Suite. Keine neue Migration — 052 bleibt head; steht jetzt oben, damit niemand danach sucht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
vulncheckandClaude Opus 5
|
7b69e804ca |
feat(netdisco): Cisco IOS XE / IOS XR routers, matched exactly
The Netdisco connector shipped with "Cisco, Cumulus and the rest need their
own curated matching" as its stated scope. This is Cisco's half: an IOS XE
router (a C1121X on 17.15.4c, say) was inventoried as an asset and given no
CVE verdict at all.
Cisco is the first product here whose match is EXACT rather than a range, and
that is not caution layered on the data, it is the data. Cisco publishes no
ranges: NVD enumerates 267 separate cpeMatch entries for CVE-2026-20267, each
an exact cpe:2.3:o:cisco:ios_xe:<release> with no versionStart/End anywhere,
and Cisco's own CNA record enumerates the same 268 releases as bare `version`
entries. So "affected" is set membership.
Comparing would be strictly worse, because the numbers are not the release.
Cisco ships 17.15.4, .4a, .4b, .4c and .4d as five separate releases and a
record names some and not others, but _vtuple reads all five as (17,15,4).
Two changes follow, and they are deliberately not the same change:
* _in_range's exact-version branch now also requires the release suffix to
be equal. That is a TIGHTENING, applies to every product, and can only
ever reject - numeric equality alone put all three of the 17.15.1w/x/y
CVEs on a router running plain 17.15.1.
* Reading "17.15.4c" as a version at all is NOT shared. _clean_version stays
dotted-numeric-only and the two Cisco registry entries carry
"lettered": True instead. That rule has thirteen call sites across six
services and every one of them compares RANGES, where _vtuple drops the
letters - letting 1.1.1w through there would hand a letter-blind
comparison a version whose letter is the release (OpenSSL: 1.1.1a..1.1.1w
all read as (1,1,1)). Only the exact path can honour a suffix, so only it
gets one.
Both sources, as everywhere here, and neither is redundant - verified
08.09.2026: the IOS XE batch (CVE-2026-20267..20273) is fully enriched at NVD,
while the IOS XR batch a month later (CVE-2026-20274..20280) is still
"Awaiting Analysis" with zero CPE entries and exists structurally only in
Cisco's own records. The reverse also happens: CVE-2019-12660 states its
affected release in the PRODUCT NAME ("Cisco IOS XE Software 3.2.11aSG",
version "unspecified"), so the CNA half cannot read it and only NVD carries it.
The product anchors matter more for Cisco than for anyone else so far: Cisco
files every product it makes under one vendor and states them as separate
affected[] blocks in the SAME record. CVE-2025-20363 carries five - IOS (2005
versions), IOS XR (13), IOS XE (456), ASA (220) and Firepower (94). Matched
loosely, a router collects an ASA's release list.
No fix version is reported, because neither source states one; a Cisco record
lists what is broken and is silent on what is not. The finding still has its
path to close - a device upgraded to a release the record does not enumerate
stops matching and the reconcile closes it. Likewise, defaultStatus is
"unknown", so an unlisted release is one Cisco did not judge and is read as
"no verdict": a brand-new rebuild is under-reported rather than flagged
forever, which is the direction NVD's own CPE data chooses too.
Classic IOS is deliberately out. It numbers releases "15.2(7)E3", which NVD
backslash-escapes into the CPE and no version scheme here reads; those devices
keep the asset and no verdict.
Also fixes a substring trap the same shape as the "ios" one the Aruba commit
fixed, one letter further along: _os_family tested `"os x" in n`, and "os x"
lives inside "cisco iOS XE" / "cisco iOS XR". Every Cisco router would have
been read as a Mac - compared against macOS ranges by scan_asset_os_apple
(17.15.4c sits below every macOS 26 bound) and stripped of its own NVD
findings by _platform_ok for naming the wrong platform.
Deliberately not included: Cisco's own Security Advisories. They carry the
same CVEs the records already state structurally; the one thing they add is
the fixed release, and scraping sec.cloudapps.cisco.com for it is a third
source with its own failure modes - add it when a missing fix version is what
is actually blocking someone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
vulncheckandClaude Opus 5
|
11172958f8 |
docs(netdisco): kein zweites alembic upgrade direkt nach "up -d"
entrypoint.sh migriert bei jedem Containerstart. Ein manuelles "alembic upgrade head" unmittelbar danach laeuft gegen denselben Schritt: beide lesen 050, einer schreibt 051, der andere findet beim UPDATE auf alembic_version keine Zeile mehr und bricht mit "expected to match one row" ab — obwohl die Migration angewandt ist. Anleitung prueft jetzt mit "alembic current" statt nochmal zu migrieren. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
vulncheckandClaude Opus 5
|
ea338d4e98 |
docs(netdisco): Testertext fuer den Netdisco-Connector
Beide Fassungen auf das aktuelle Update gezogen: was die Karte kann, welche drei Aruba-Familien erkannt werden und warum sie getrennt bleiben muessen, was bewusst fehlt (Bulletins, EoM, Nicht-Aruba), der Apple-"ios"-Nebenbefund, und neun Testpunkte samt der beiden Offline-Suites. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
vulncheckandClaude Opus 5
|
bcaa4f02ee |
feat(netdisco): switch estate as assets, with Aruba firmware CVEs
A switch runs no agent, no MDM enrols it, and a Nessus scan without SNMP
credentials sees an open port and no version — so the devices everything
else is plugged into had no coverage at all. Netdisco already asks them
over SNMP; this reads its deviceinventory report and turns it into assets
and findings.
Aruba detection is family-split on purpose: AOS-CX (10.13.1005), the
ProVision line (16.11.0016) and the Mobility controllers (8.13.1.1) are
three products HPE files under one vendor with overlapping numbers, and a
CX switch matched against a controller's range would be told to install
an image its hardware cannot take. Each family gets its own curated key,
its own anchored product regex and its own NVD CPE, and an index entry
without a floor must additionally share the installed release BRANCH —
HPE writes one range per branch on the same record (CVE-2026-73749
carries 10.18, 10.17, 10.16, 10.13 and 10.10 side by side).
Both CVE sources, as everywhere here: NVD carries usable cpeMatch ranges
for the three 2023 ArubaOS-Switch flaws, while the current AOS-CX batch
(CVE-2026-73749, -44880) sits there unenriched and exists only as HPE's
own CNA records. The switch records state their bounds as prose
("KB/WC/YA/YB/YC.16.11.0015 and below"), which the shared extractor reads
as the number salad (16,11,16,11,12) it looks like — so those are parsed
separately, per branch, and "All versions" is skipped: a finding with no
fix to reach is noise, not a verdict.
The two-letter code line ("WC.", "PL.") names the hardware family, not
the version. It is dropped for comparison and kept in the description,
where it is what an operator matches against HPE's download page.
Also anchors the Apple iOS patterns. They matched "ios" as a substring,
and Netdisco names a Cisco switch's OS exactly that — every Cisco device
in an estate would have been compared against Apple's iPhone ranges,
where IOS 15.2 sits below every bound ever written.
Deliberately not included: HPE's own bulletins (the same data the CNA
records already state structurally) and EOL/EOM (HPE publishes those per
hardware product, not per firmware line, and endoflife.date carries no
ArubaOS at all — an invented date would retire real assets on a guess).
Non-Aruba devices get an asset and no CVE verdict.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
vulncheck
|
ea064107fd |
feat(m365): a finding never showed the page it was raised from
M365 Apps fixes are not published to NVD and Wazuh's detector never sees them: the single public record of "CVE-X is fixed in build Y" is the Microsoft Learn security-updates page this check parses. The finding cited NVD, CVE.org, Exploit-DB and the EUVD — catalogues that either know nothing about the M365 fix or, for a fresh CVE, hold no record at all — but not the page the detection actually came from. The operator could read the claim and had no way to check it. Every M365 finding now carries that page under External References, deep- linked to the monthly section that lists its CVE. - The anchor is read off the page, never guessed. _parse_security_page collects the real h2/h3 ids and keeps the one that matches the date heading, trying both the padded and the unpadded day (Microsoft writes "December 09, 2025" and "June 9, 2026" and slugifies each verbatim). 94 of 95 sections currently resolve; a section with no id of its own falls back to the plain page URL instead of a fragment that lands nowhere. - detect_missing_cves reports cve_anchors alongside missing_cves, so the CVE points at the section that first published its fix, not at the newest one that happens to re-list it. - Both entry points pass it (nightly run_m365_check and the Intune detectedApps path), and the upsert re-attaches on every run, so findings raised before this pick the link up on the next pass. references is a shared column, so the cross-source contract applies to it as much as to sources: Vulnerability.add_reference() appends and dedupes, the M365 check replaces only its own earlier link, and the two writers that used to fill the column only while it was empty (Nessus see_also, the app-CVE scanner's vendor bulletin) now merge instead — otherwise an M365 reference on the same row would have cost the host its vendor advisory. Migration 051 fills in the rows the check will not re-raise (already closed, or on a host that no longer reports an M365 install) with the plain page URL, touching only rows m365_check raised and only where nothing is set. In the UI the link renders as "MS365 Apps Security Updates" rather than a bare learn.microsoft.com hostname. |
||
|
vulncheck
|
83d2757f3f |
fix(wazuh): a wrong indexer password synced nothing and the run was still COMPLETED
Only the indexer password was changed. The manager API (55000) still
answered, so the agent list came back and no phase raised; the indexer
(9200) refused every query with 401. query_vulnerabilities_from_indexer()
logged that and returned [] — so each of the 31 agents looked like a host
with no CVEs: "deferring backfill", agents_synced += 1, and at the end
"every agent returned 0 CVEs — treating as an outage" as a WARNING in the
container log. Ledger: "sync run #33 wazuh (manual): completed". Green Sync
Health, green "Synchronization Complete", no mail — nothing had been synced.
The earlier fix (
|
||
|
vulncheckandClaude Opus 5
|
bab6433b01 |
fix(reopen): a week-old Intune list reopened CVEs Defender TVM had just closed
Field report 06.09.2026: two hosts in Intune AND Defender TVM, no Wazuh agent.
Defender saw the Microsoft Edge update and closed a dozen Edge CVEs at 02:10
("device remediated"). At 03:20 the app-CVE scan pulled those hosts' inventory
— Intune detectedApps, which had not caught up and still listed Edge
132.0.6199.32 — and the MSRC fixed-build pass it drives reopened every one of
them. Edge was really at 132.0.6199.62. Next night the same, until Intune
caught up: a change history describing our polling, not the host.
The brake existed. reopen_if_patched already refuses a reopen whose data is
older than the close — but the grace was keyed on the SCANNER, and 'app_scan'
and 'msrc' sat there as "reads a live inventory". That holds on a Wazuh host.
On an Intune host both read the one list already known to lag: they fetch
nothing themselves, they decide from whatever run_app_cve_scan handed them, and
by the time the decision is made the provenance was gone.
Key the grace on the INVENTORY instead. A scan declares whose list it is
deciding from (audit_events.scanning_inventory / use_inventory), and the two
relaying scanners inherit that lag; every other source keeps its own. The
Wazuh-login-refused fall-through, where Intune answered for a Wazuh host, is
covered by the same declaration — it used to count as live.
The numbers were also backwards: Intune stood at 1 day and Defender at 3.
detectedApps depends on the tenant's refresh policy and is routinely a week
behind, while the Defender software list follows device telemetry (the reason
defender_service feeds it to the app scan in the first place). So Intune goes
to 7 days, m365_check with it — same Graph list — and the Defender software
list declares no lag at all; the 3 days under "defender" describe the TVM CVE
feed and stay there.
Deliberately not done: letting Defender TVM override the app scan outright.
"Defender reports nothing" is not "the host is patched" — for software Defender
does not inventory, or a device that stopped reporting, that would bury a
genuine MSRC finding for good, and for Edge MSRC is the only machine-readable
source there is. Past its lag the reopen goes through, so a host that really
regressed still resurfaces. Nothing about how inventories are fetched changed.
Test: tests/test_reopen_stale_inventory.py — the field case, the reopen after
the lag, and a control that a Wazuh host keeps its immediate say.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
vulncheckandClaude Opus 5
|
f29f83653d |
fix(app-scan): CVEs closed as "no longer detected" from an inventory that was not the host's
Field report 06.09.2026, asset 36: the Wazuh API was dead — the Asset view
could not fetch that host's software inventory at all — and an app-CVE scan
started anyway closed exactly two CVEs on it as "App CVE scan no longer
detects this CVE". Nothing had been patched; the asset was ACTIVE, and the
next scan after Wazuh came back reopened both.
The auto-resolve guard asked only whether `packages` was non-empty, never
where the list came from. The inventory pick is
if asset.wazuh_agent_id and wazuh: ... else: intune detectedApps
and that host is registered in both. With the Wazuh login refused, the scan
fell through to Intune's detectedApps — a thinner list with different product
names that does not carry everything syscollector reports. Non-empty, so the
guard passed, and every product Intune does not list read as "no longer
detected". Only that one host, because every other one is Wazuh-only and got
no list at all.
Same shape for browser extensions: they come from the indexer, and a failed
fetch returned [] — "this host has no extensions" — so the reconcile closed
extension findings against a list that cannot contain them.
Track, per asset, which source OWNS the inventory and which one ANSWERED. A
mismatch (or a failed extension fetch) closes and prunes nothing, for the
app-scan reconcile and the MSRC package reconcile alike; detection still runs,
since a product Intune reports really is installed — only retracting needs the
host's own, whole inventory. The Wazuh client now separates a missing IT
Hygiene index (404 → [], as before, for < 4.14) from an unreachable indexer,
which raises.
Test: tests/test_partial_inventory_no_autoclose.py — the field case, the
extension case, and a control that a healthy inventory still closes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
vulncheck
|
ba57975ce0 |
fix(msrc): a scan started by hand still answered from the previous night's index
Follow-up to
|
||
|
vulncheck
|
10c4b86c71 |
fix(msrc): an Edge CVE reached the host two nights after MSRC published it
Field report 06.09.: CVE-2026-84324 / CVE-2026-84354 — Chromium CVEs that
MSRC files under "Microsoft Edge (Chromium-based)", fixed build
152.0.4191.62. The app scan had the Chrome half since 02.09.; the host also
ran Edge 152.0.4191.51, and the morning after MSRC published (03.09. ~17:00)
the finding still showed no MSRC source and no Edge product.
Not a parse or compare defect: replayed against the live 2026-Sep CVRF, the
index carries both CVEs under 'edge' and flags .51 against the .62 fix (now
locked down by the new test). The defect is WHEN the index is built:
03:20 app-CVE scan reads msrc_product_index_v2 as stored (allow_stale)
03:50 MSRC nightly rebuilds it
The package pass that creates the Edge findings always decided from the
previous night's index, so a CVE MSRC published on day D reached the host on
D+2 — and a user checking on D+1 saw "not detected".
|
||
|
vulncheck
|
51a69a6e8a |
fix(scans): a sync whose login phase died was COMPLETED because the indexer half still ran
The Wazuh manager API (55000) refused every login with 500 for a day. The hourly scheduled scan noticed — the asset sync raised at authentication — and filed it as "COMPLETED · 1 ERR": the per-agent vulnerability sync reads the indexer (9200), went through for all 64 agents, and the only failure rule was "0 agents synced". No red badge, no banner, no mail, until a manual sync six hours later hit the same 500 and mailed within a second. Hypothesis that held: two services behind one source. A phase that cannot log in is a failed run whatever the other phase did. fail_if_source_broken() replaces the 0-agents rule: a phase failure fails the run; so does a source-level error among the agents (login refused, 5xx, connection refused/reset, DNS, SSL) even with 40 agents through. Other per-agent errors stay completed, but Sync Health now shows them amber as "N ERR" with the first error, not green OK. The nightly app CVE scan, SCA refresh and EOL check log in to the same API per asset and used to warn per asset and finish. Each now logs in once up front (probe_wazuh_api): refused = a failed Wazuh run in the ledger with the phase, mailed under the usual 24h cooldown; the API dying mid-run is caught the same way from the fetch errors. A probe that works writes nothing. The app scan continues without Wazuh inventory (empty inventory keeps findings, Intune assets scanned as usual). The failure mail names phase, counters and the error list, so the reader sees what still went through. Regression: a scheduler-seam test replays the incident (asset sync refuses, two agents pass over the indexer, run failed, agents_synced=2, one mail). |
||
|
vulncheck
|
35c7a858c2 |
fix(rbac): Groups, Policies and Auth Providers were hidden from readonly only in the sidebar
Same gap as Scan Jobs (
|
||
|
vulncheck
|
6a1e6f5814 |
fix(rbac): Scan Jobs was hidden from readonly only in the sidebar
A readonly user saw the dashboard's "coverage at risk" banner and its
"Scan Jobs →" link, and could read the whole page: run ledger, sync
health, error messages, schedules.
Cause: the sidebar commit (
|
||
|
vulncheck
|
29649c169b |
feat(gui): one pagination bar everywhere, with a page you can type into
Three lists paginated three different ways: Assets had « ‹ Page n / N › », Vulnerabilities had a row of numbered buttons with an ellipsis, the audit log a third copy of the Assets bar. None of them let you type a page number — on 357 pages of assets the only way to page 200 was clicking Next 181 times or guessing with the per-page selector. The notification log had no paging at all: the backend already accepted limit/offset, the GUI fetched the first 50 and stopped. One shared Pagination component now renders every list bar: range and total, per-page select, first/prev, a "Page [ ] / N" field that commits on Enter or blur and clamps to 1..N, next/last. Assets, Vulnerabilities, Audit Logs and Notification History all use it; the notification-log endpoint sets X-Total-Count (same pattern as /audit/logs) so that page shows "x / y" and the header counter shows the real total instead of the size of the first fetch. |
||
|
vulncheck
|
9ca0be24f0 |
feat(scans): a sync that dies at login is now a failed run, on screen and by mail
A Wazuh API that refused every login for a day was visible only in the container log. Every scan-jobs row is per asset, and a sync that fails at authentication never reaches an asset — so /scans showed a clean history of COMPLETED runs, the manual button said "Sync Failed — check the logs", and nobody was told. Ledger: every sync execution (Wazuh, Nessus, Intune, vCenter, IGEL; button or scheduler) is one sync_runs row with start, end, status, stats and the error that stopped it, written from its own session so the record never depends on the job's transaction. A run where every agent failed the same way counts as failed, not as "0 triggered". Rows left running by a restart are closed at startup. Visible: Scan Jobs gets a Sync Health strip (per source: state, last run, last success, error) and a Sync Runs table; the dashboard shows a banner while a source is failed or stale (stale follows the schedule interval, a weekly Nessus is not stale after six days); the Sync Failed modal shows the real reason, and the sync endpoints return it instead of "check server logs". Mail: a failed run mails the sync-alert recipients (own setting, else the notification defaults) with the error and the last successful sync, i.e. how long the coverage gap already is — one mail per source per 24h while it keeps failing, logged as SYNC_FAILURE in the notification log. |
||
|
vulncheck
|
ece21b9a00 |
fix(scheduler): the Intune sync scanned against yesterday's catalogue every night
Asked: is every vulnerability-catalogue refresh guaranteed to run BEFORE the nightly Intune/Defender sync, which on a large estate runs for hours? It was not. The Intune sync at 02:10 was the first job of the night, and it runs the app-CVE scan for each of its devices (plus the Defender TVM pull) — reading the cvelistV5 index and the GitHub-advisory, TeamViewer and IGEL-ISN indexes as stored. Those were rebuilt inside the app-CVE job at 03:20, i.e. after the Intune, vCenter and IGEL syncs had already decided from them. So every Intune-only device was matched against the previous day's catalogue, and only the 03:20 pass over all assets caught up — hours later on a large estate. vuln_index_refresh_nightly at 01:30 now rebuilds all four (cvelistV5 with the MFSA merge, force-fresh ZIP; GitHub advisories; TeamViewer; IGEL ISN) as the first job of the night, 40 minutes ahead of the Intune sync, and logs its elapsed time so the gap can be checked. The 03:20 scan reads the same stored index and no longer walks the 557 MB ZIP a second time. A failed rebuild keeps the cached index, as before. tests/test_nightly_index_order.py now asserts the refresh is scheduled before every sync that reads it, with room for the ZIP walk. |
||
|
vulncheck
|
2921278f5b |
feat(igel): the vendor's own notices, for the flaws that never get a CVE
Many IGEL flaws are published only as an ISN — ISN 2026-09 (UMS information
disclosure, 8.6), ISN 2025-31 (stored XSS in UMS, 8.0), ISN 2025-24 (command
execution in IGEL OS, 8.8) carry no CVE id at all, so neither the CPE path nor
the cvelistV5 path could ever see them. 21 of the 149 ISNs with a stated fix
are like that.
igel_isn_service reads kb.igel.com the way teamviewer_bulletin_service reads
the TeamViewer bulletins: the overview links every notice, each page states
the CVSS at the top and the fixed version per release line under "Update
Instructions" ("OS 12: Update to IGEL OS 12.7.1. OS 11: … 11.10.410"). That
per-line fix is the bound; the ISN id stands in for the CVE where there is
none. App versions on an OS line ("update the Chromium app to 151.x") are not
firmware bounds and are dropped; a UMS line told to move to a newer major
affects the whole old line.
Runs for both the endpoints and the UMS server, in the IGEL sync and in the
nightly app scan, between the CPE pass and the cvelistV5 pass so the shared
touched-set keeps every reconcile honest. The UMS server never had a reconcile
at all; it has one now. The index is rebuilt with the other vendor indexes.
Verified against all 198 live notices (parser and prototype agree on every
page) and by tests/test_igel_isn.py.
|
||
|
vulncheck
|
6c8cf7dd21 |
fix(igel): this UMS answers serverstatus blank, so the version can be told
The probe settled it: `/serverstatus` on this UMS returns HTTP 200 with EVERY field empty — rmGuiServerVersion, activeMQVersion, derbyVersion, serverUUID and server all "" — anonymously and logged in, on v1, v2 and v3 alike. Not a renamed key, not a missing login, and the earlier guess that the component versions were populated was wrong: the log only ever printed key names. The endpoint is broken, not forbidden. IMI answers an account without object permissions with an empty body and HTTP 200 rather than a 401, which looks the same from outside — so the probe now reads the device and firmware tables on the same session as a control. Full tables next to a blank serverstatus mean the account is fine and only that one endpoint is dead, which the IGEL community has reported and PSIGEL worked around by deleting its status call. So the operator, who knows which UMS they installed, gets to say. New optional ums_version / ums_build in the IGEL settings, used ONLY when IMI reported none — a UMS that answers keeps answering for itself, and the Test button says which of the two it is showing. Without this the one server that manages the whole thin-client estate stays the only asset with no version to compare a CVE range against. |
||
|
vulncheck
|
d92c686d80 |
tools(igel): probe for where this UMS keeps its own version
The login retry did not fill rmGuiServerVersion on the UMS in the field, so the question is no longer "did we authenticate" but "does this UMS publish its version at all, and where". Guessing another key name into the client would be the third guess in a row. Prints the raw serverstatus body before and after the login (so "the login did not happen" and "the login changed nothing" stop looking alike), then every neighbouring IMI route and web surface on the same port with any version-shaped string found in it. Read-only. |
||
|
vulncheck
|
c93da7787e |
fix(igel): the UMS kept its own version until it was asked logged in
/serverstatus is the one IMI endpoint that answers without a login, which is what makes it a reachability probe that can tell "cannot reach the UMS" from "reached it, credentials rejected". Asked that way, UMS 12 answers 200 with the whole envelope and its OWN version blank: activeMQVersion and derbyVersion populated, rmGuiServerVersion "", no buildNumber at all. The key was never renamed — the value simply is not handed to an anonymous caller. So the UMS asset, the one server that manages the whole thin-client estate, landed with no os_version and a description reading "IGEL UMS", and nothing ever compared it against a CVE range. Ask once anonymously, and if the version came back blank, log in and ask the same question again. A login that fails stays silent here on purpose: test_connection() logs in itself right afterwards and reports a rejected password as its own step, so raising here would relabel bad credentials as an unreachable server. The warning now also names which known version keys were present but empty, and whether it fired before or after the login. That is the difference between "UMS renamed the field" and "something did not authenticate" — the previous log line listed rmGuiServerVersion among the keys while saying no version was carried, which cost a round trip to the customer to resolve. |
||
|
vulncheck
|
b802f3a518 |
fix(scans): three more indexes were a night behind the scan that read them
The MFSA fix (
|
||
|
vulncheckandClaude Opus 5
|
271043a206 |
fix(igel): a trailing slash cost the version, and no version costs everything
Four findings from one estate, and three of them are the same shape: the scan
had nothing to compare, so it said nothing, and nothing reads as clean.
* IMI GET /firmwares/ answers HTTP 404 on UMS 12 ("No endpoint GET
/umsapi/v3/firmwares/"). The documented URL has no trailing slash. The
firmware table is the ONLY place a device's version string lives, so the
slash cost every version in the estate at once.
* IGEL OS 12 states its base-system build inline — 12.6.0+2 — and
_clean_version's dotted-numeric rule threw the whole string away. No
version, no scan: eleven devices on 12.6.0+2 showed zero CVEs while
sitting inside the range of both current ISNs. Semver excludes build
metadata from precedence and every IGEL bound is written without it
(12.7.6, 12.8.3), so the suffix is dropped, not rejected. 12.9.0+3 stays
clean, which is the correct answer and not a miss — 12.9.0 IS the fix.
* The UMS server's own version came back empty and its build not at all,
so the server asset carried no version and Test read "UMS (build ?)".
Nothing failed: serverstatus answers 200 either way. The documented IMI v3
keys are tried first, then the spellings UMS 12 has been seen to use, and
a payload that carries none of them now logs the keys it did carry — the
next rename should cost one log line, not an estate.
The fourth is not a bug but the question the CVEs are a footnote to.
IGEL OS 11 stops receiving security fixes on 2026-06-30. No CVE feed will ever
state that, because "unpatchable from here on" is not a CVE, and
endoflife.date carries no IGEL product at all — so the dates are transcribed
from IGEL's own Knowledge Base.
The mapping is the part that needed care, because IGEL's two terms are not the
two this codebase already has, and taken the obvious way round they invert:
EOL - End of Life no further ENHANCEMENTS; security fixes still ship.
OS 11 hit this in April 2023 when OS 12 launched,
and stayed patched for three more years. -> eoasFrom,
informational, LOW.
EOM - End of Maintenance "no updates, no security and bug fixes." -> eolFrom,
a real finding.
The 2025-12-31 that circulates for OS 11 is IGEL's original date; the vendor
page now states 30th June, 2026. Third-party migration write-ups still carry
the old one. The vendor's page wins.
OS 12 gets an entry with no EOM, because IGEL has published none and an
invented date would be the only unsourced one on the page. It raises nothing.
UMS 6 (EOM 2023-10-31) does — that one is 1037 days past.
A migrated device has no other way out of its old finding: a thin client has
no software inventory, so the EOL sweep's own reconcile never reaches it. Both
slugs are single-release, and the pass supersedes explicitly when the line it
now runs is one that raises nothing.
Findings say "IGEL product lifecycle", not endoflife.date. A row that named a
source which has never heard of the product sends an operator to a page that
cannot confirm or refute it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
vulncheck
|
978d4f3cc7 |
fix(firefox): the MFSA index was always a day behind the scan that used it
The nightly Firefox ranges were decided from yesterday's advisories, every night, because the MFSA index refreshed itself ~10 minutes too late. _merge_mozilla_mfsa asked get_index(), which honours its own 24h TTL. In the nightly job the first caller to hit an expired cache is not the merge (03:20) but the enrichment step that follows it (~03:30) — so the cache timestamp drifted permanently to just after the build, and the merge read a ~23h50m old index forever. Self-perpetuating: every night it re-stamped the same offset. Measured on 02.09.2026, reproduced exactly offline against the advisory repo: 03:21 cvelistv5-scan: MFSA decided 551 Firefox CVEs <- 01.09. cache 03:31 MFSA index built: 644 CVEs <- today's advisories 551 is the index as of mfsa2026-81; the truth that morning was 580 mainline CVEs. The 29 in mfsa2026-82..85 (CVE-2026-84117..84145, published 01.09. 12:19 UTC) were not scannable for another full day. force_fresh — which the nightly job already passes to re-download the cvelistV5 ZIP — now also rebuilds the MFSA index before the merge. A rebuild that fails still falls back to the cached index, so an offline or rate-limited night is no worse than before, and the on-demand paths stay cache-only. While there: a build cut short by the GitHub rate limit produced a PARTIAL index and stored it, caching "Firefox has fewer CVEs than it does" for 24h. It is now discarded in favour of the last complete one. |
||
|
vulncheck
|
784caebd7c |
fix(assets): "seen again by a source sync" named the one thing nobody could look up
Three iPhones flipped inactive → active every day and the audit log's only word on it was "(seen again by a source sync)" — the one line that cannot be told apart from an Intune revive, a Defender TVM revive, or anything else. Two defects behind the one symptom. The nameless message came from the nightly TIME-based reconcile, which reacts to `last_scan`/`last_seen` rather than to a sync run, and those stamps carried no source, so no message could ever name one. Every sync that stamps them now records itself in `last_seen_source` (migration 049) and the reactivation entry quotes it: "seen again by the intune sync — time-based reconcile: last_scan=…, last_seen=… is inside the 42d window". Rows stamped before the migration say "unknown source (stamp predates source tracking)" — `assets.source` is the source that CREATED the asset, not the one that last saw it, and a confident wrong name in a revisionssicher log is worse than an honest gap. The event-driven revives (Wazuh, Nessus, Intune, vCenter, IGEL) already named themselves and are unchanged. The flap itself: the phones were deleted in Intune, so the Intune reconcile deactivated them on every sync, and hours later the nightly reconcile revived them on the stamp the sync BEFORE the deletion had written. That stamp was already there when the asset was deactivated, so it is not evidence of anything — the reconcile now requires a stamp newer than the most recent ASSET_DEACTIVATED entry, the same rule reconcile_missing_from_sync already follows in the other direction. Fail-open: if that lookup errors the reconcile behaves as before. Also surfaced, read-only, in the asset edit dialog next to the VMware build: Entra device ID, Intune device ID, Defender machine ID, Wazuh agent ID. The Entra ID is the identifier that survives an Intune deletion while Defender TVM keeps reporting the same device under another name — it was in the database and in the CSV export all along, just nowhere on screen, which is exactly where an operator needs it to exclude the right machine in Defender. Not done: writing the ID into the Description field. Description is free-form operator text and a sync overwriting it would clobber what someone typed there. |
||
|
vulncheck
|
54ec6144cd |
feat(igel): thin clients were an inventory nobody was looking at
IGEL UMS as a fifth inventory source, configurable under Settings next to
vCenter. It registers the UMS server and every endpoint device it manages as
assets, then detects IGEL OS CVEs on each.
An IGEL thin client is the one endpoint class nothing here could see. It runs
no Wazuh agent — IGEL OS is a locked-down appliance, you do not install one —
Intune does not enrol it, and a Nessus scan gets an open port and no version.
An estate of several thousand devices showed up as zero assets and zero
findings, which reads as clean and only means unlooked-at.
UMS already holds what is needed, but it needs a join: the device record
carries a firmwareID ("21"), and the version lives in a separate firmware
table. One extra request answers for the whole estate — the alternative, two
calls per device, would be 6000 requests for 3000 thin clients.
CVE detection needs BOTH sources, and neither is redundant:
* cvelistV5 carries IGEL's own CNA records. CVE-2026-82017 and -82018 (the
DEF CON 34 thin-client research, ISN 2026-19 / 2026-20) sit at NVD with no
configuration at all, so this is the only structured source for them.
* NVD's CPE carries CVE-2025-47827, which MITRE filed with vendor "n/a" —
there is no CNA data for cvelistV5 to index. It is also where the UMS
server's own four CVEs live (CVE-2022-25804..25807: hardcoded DES keys,
cleartext LDAP binds).
Two guards decide a finding. OS 11 and OS 12 are separate products with
separate fixes for the same flaw — CVE-2026-82017 is 11.11.150 on one line and
12.7.6 on the other — and taken naively an 11.11.149 device is also "less than
12.7.6". The installed major picks the line, and the product name ("IGEL OS
12") has to agree when the record states one.
The fix version survives an inclusive bound. CVE-2026-82018 says "affected up
to 12.8.2" and names 12.8.3 only in its `unaffected` entries — which is exactly
ISN 2026-20's Update Instructions, and the reason the finding exists. Without
recovering it the finding would call a device vulnerable and stay silent on
what fixes it.
Findings auto-close: an endpoint has no software inventory, so the app scan's
own reconcile never reaches it — the same hole the vSphere path had. The
CPE pass runs first and its hits are folded in, so the one CVE the cvelistV5
index structurally cannot confirm is not closed and reopened every night.
Address matching is deliberately off for devices. vCenter matches on it
because an ESXi host holds a static management address; a thin client takes a
DHCP lease, and a recycled lease would bind one device to another device's
finding history. The MAC-derived unit ID is the pin instead.
No EOL check: endoflife.date carries no IGEL product, and inventing lifecycle
dates for an estate whose real question is "OS 11 is end-of-maintenance" would
be worse than saying nothing.
The vendor security-bulletin page is planned, not built (docs/). The check
found the reason to wait: most ISNs are bundled-component notices — Chromium,
Firefox ESR — whose fix is stated per APP, and IMI v3 exposes no installed-app
resource, so those findings could not be attributed to a device.
Migration 048 (IGEL source + igel_unit_id). The cvelistV5 index key is bumped
to v31 so the cached index rebuilds with the new product.
|
||
|
vulncheck
|
2f742a7c4c |
fix(advisories): the KEV legend never made it to the feeds page
The dashboard widget explains its lock icon; the Security Advisory
Feeds header listed the same three catalogs but no legend, so 🔒 on
a row had nothing to decode it. Same source line, same suffix.
Also capitalised "Ransomware" in every user-visible string (legend
plus the three tooltips) — it was lowercase everywhere.
|
||
|
vulncheck
|
fa5351a703 |
fix(kev): the alert mail was still a two-catalog feature
VulnCheck KEV shipped as a third exploited-catalog source in
|
||
|
vulncheck
|
447e723eab |
fix(exchange): only Subscription Edition was on the CVE scanner's map
CVE-2026-62911 (auth bypass -> EoP, CVSS 8.0) was reported by Wazuh alone on a host running "Microsoft Exchange Server 2016 Cumulative Update 23" 15.1.2507.61. Not a false positive: the record bounds 2016 CU23 at 15.01.0.0 .. < 15.01.2507.072, and .61 is below .72. The app scan stayed quiet because the curated cvelistV5 registry knew exactly one Exchange product — Subscription Edition. The CU row resolved to nothing, so it was never compared against anything. The NVD-CPE path cannot cover these at all: microsoft:exchange_server carries version "2016" and update "cumulative_update_23", with no build to range-check (SE has its own CPE product with real builds, which is why that one works there). One key PER CU, not a shared "exchange" key: the record floors every CU at a generic 15.0x.0.0, so a 2019 CU14 host (15.2.1544.x) would be compared against the CU15 bound (1748.049) and reported affected while fully patched. The set is closed — CU23 was the last 2016 CU, CU15 the last for 2019. Anchored like the SE row, for the same reason: the same host also lists a plain "Microsoft Exchange Server" frozen at the CU's RTM build (.6 against the CU row's .61), plus language packs and KB hotfix rows with stub versions — each would sit below every fix build forever. Index setting bumped to v30 so the product index rebuilds. |
||
|
vulncheck
|
7707a05bac |
fix(teamviewer): a 15.80.6.0 client reported clean against a 15.81.5 fix
CVE-2026-16444 (TV-2026-1008, CVSS 7.5) was invisible on every TeamViewer
install. NVD carries no configuration for it — the record sits at "Received"
with zero cpeMatch entries — so the CPE path was blind by construction, and
cvelistV5 was the only structured source left. There the record is filed under
ONE compound product string:
vendor "TeamViewer" product "Full Client, Host, QuickSupport & Portable"
versions 15.0 lessThan 15.81.5
The curated pair list held ("teamviewer", "full client") and four siblings,
none of which equals that string, so the record never entered the index and
15.80.6.0 was never compared against 15.81.5. Across the 54 TeamViewer records
the same client appears under 25 spellings; the compound form is the one the
vendor has used since 2026, which is why coverage looked fine until now.
Replaced by a _PRODUCT_PATTERNS entry, the same mechanism Windows and Apple
releases use. The regex is anchored, enumerates the client component words and
excludes the mobile apps by name: DEX (32 records, versioned 9.x/24.x/25.x),
ONE, Frontline, IoT, Engage, Meeting and Patch & Asset Management all ship
their own version lines and must never be compared against a 15.x client.
CVE-2026-19042 is the control and is deliberately NOT a finding on Windows:
the record and the bulletin both scope it to Linux.
Also here, from the same audit:
- NVD files the client under a SECOND CPE name since the 2023 rename —
28 records say teamviewer:teamviewer, 2 say teamviewer:remote. The registry
queried one, so it lost the other's; added via `also`, the way Adobe's two
Reader names already are.
- New source teamviewer_bulletin_service: the vendor's own security bulletins,
for the same reason Firefox has MFSA and Notepad++ has repo advisories.
5 of the 30 published bulletins carry NO CVE id at all — TV-2026-1006 is a
real Full Client flaw (15.78–15.79.3) that no CVE-keyed source can see. The
bulletin id stands in as the identifier, as GHSA- and NESSUS-PLUGIN- do.
Rows are scoped per platform and per release line; bulletins that state no
version ("All", "Server-side hot fix") are skipped rather than guessed at.
- _upsert learns `refs`, so a finding whose id has no public catalogue page
carries the advisory URL as its only reference.
- An index that parses to empty is never stored: it would be stamped fresh for
24h, leave every TeamViewer finding untouched, and the app-scan reconcile
reads untouched as "no longer detected" → patched.
Verified against the live feeds: 30 bulletins, 17 with client version tables,
and on a Windows host at 15.80.6.0 exactly one finding — CVE-2026-16444,
fix 15.81.5.
|
||
|
vulncheck
|
ed728cb593 |
fix(dashboard): the KEV widget called every VulnCheck row "CISA"
The advisories panel learned the third catalog; the dashboard widget did not. Its badge cell was a two-way ternary — euvd or else CISA — so every row that only VulnCheck listed got painted with CISA's name and CISA's red, and the header underneath still read "CISA KEV + ENISA EUVD". Wrong on the facts, and wrong on the licence: VulnCheck KEV is free to use only where it is named. Cause was the duplicate definition. The advisories page carried its own badge map and its own source line; the dashboard carried a copy that predated VulnCheck. Both now read from frontend/lib/kevBadge.ts, and the widget takes its attribution from the same response that carries the rows — so a fourth catalog names itself in both places instead of silently borrowing CISA's. Unknown sources now fall back to their own id, never to another catalog. The lead-time badge (−6d) rides along, since that is the reason VulnCheck is carried at all. Per-vulnerability data is untouched: kev_listed is still CISA alone, so the vulnerability tables show no VulnCheck column — there is no such field yet, and adding one moves every URS score in the fleet. |
||
|
vulncheck
|
f77c7413b3 |
feat(kev): VulnCheck KEV as a third exploited-catalog source
The KEV panel knew CISA (~1400 CVEs) and ENISA EUVD. VulnCheck KEV carries
~5200 and typically lists them days before CISA does — every record ships
CISA's own date, so the lead time is measurable, not a claim, and each row
now shows it.
Opt-in and silent by default: without VULNCHECK_API_TOKEN the source returns
{} and nothing about the install changes. Alerting is deliberately NOT opted
in either — kev_alert_sources stays "cisa,euvd", because ~4x the CVEs is the
operator's decision, not a side effect of updating.
No SDK: two GETs against a documented JSON API. The backup endpoint hands out
the whole index as one signed ZIP; the paginated index is only the fallback
and is capped at 600 documents on the community tier, which the log says out
loud so a partial catalog is never mistaken for the full one.
Attribution is a licence term, not decoration: "VulnCheck KEV" is named in the
KEV panel header and badges every row the source contributed to. Noted in
LICENSING.md so nobody strips it later.
Per-vulnerability scoring is untouched — kev_listed still comes from CISA
alone. Feeding 5200 CVEs into the URS bonus would move every score in the
fleet and belongs in its own decision.
|
||
|
vulncheck
|
9e38554787 |
perf(dashboard): cut the load to a fifth of its queries
The dashboard fires fourteen requests and renders nothing until the slowest returns. Measured against a seeded fleet (300 assets, 80k findings), the burst took 0.76s — and the server runs them strictly one after another: every vulnerabilities endpoint is `async def` holding a blocking Session, so six parallel requests take exactly as long as six sequential ones (measured speedup 0.90x). Wall clock is therefore the SUM of the endpoints, which makes every wasted query on the page a direct hit on time-to-render. Three sources of waste, all removed: - /reports/dashboard ran eighteen COUNTs over the same scan — four severities, exploitable, avg, distinct assets, oldest row, seven one-day history counts, two totals, two asset counts. Now three statements: one aggregate with FILTER clauses, one grouped history query, one asset count. Response is byte-identical. - The list endpoint lazily loaded asset, asset.groups and packages per row, so a twelve-row widget spent 36 round trips after its one real query. Eager-loaded: 39 statements to 5 for that call, and the dashboard fires seven such widgets. - With distinct_cve the unused `total` re-ran the whole window-function pass (80ms of a 160ms call) for a number no widget renders. New `with_total=false`, which the dashboard's seven widget calls now pass; default stays on, so the Vulnerabilities page is untouched. Dashboard burst 0.76s → 0.48s locally. The N+1 removal counts for more than that on a real deployment, where every round trip crosses the network. Remaining top cost is /compliance/urs (185ms, ~40% of what is left): it pulls every open finding into Python to compute CPR per row. The materialised cpr_score column could aggregate that in SQL, but that changes URS numbers wherever the column is stale, so it stays a separate decision. |
||
|
vulncheck
|
b14e83be92 |
fix(dashboard): link URS highest-risk assets to their compliance detail
The URS widget listed the five highest-risk assets as plain text — the only list on the dashboard that was not clickable. KEV rows push to the vulnerability view, compliance "worst offenders" linked out, only URS was a dead end: the user read a hostname, then searched for it by hand on the compliance page. Each entry now links to /compliance?asset=<id>, and the compliance page reads that parameter once its tables have loaded and opens the asset's policy modal — the same modal a click on the URS table row opens. That makes it a direct link to the affected asset, not just to the section. Same fix for the compliance widget's "worst offenders", which linked to the bare /compliance page and dropped the asset it named. useSearchParams forces the page dynamic unless it sits under a Suspense boundary, so CompliancePage is split into an inner component and a Suspense wrapper, matching the vulnerabilities page. /compliance stays statically prerendered. The "Open >" link to the compliance page reported as missing from the URS widget is present and unchanged (page.tsx:557). |
||
|
vulncheck
|
e7ad196d0e |
perf(urs): score the fleet in one pass instead of once per asset
Feldmeldung: Dashboard und Compliance-Seite brauchen seit dem Einspielen der Mittwochs-Commits acht Sekunden statt drei. Die Logs zeigen, woran es liegt, und es sind nicht die Mittwochs-Commits: von allen Calls beider Seiten ist genau einer langsam, /api/v1/compliance/urs braucht 4,9 bis 6,0 Sekunden, alles andere zusammen unter 300 ms. Beide Seiten haengen ihr gesamtes Promise.all daran, also wartet die ganze Seite mit. list_urs hat pro Asset gescort: eine Asset-Abfrage, eine Vulnerability- Abfrage, eine Result-Abfrage, dann pro Policy ein Lazy-Load der Checks plus eine Impact-Abfrage. Nachgemessen mit einer 120-Host-Flotte, drei Policies, 120 Checks: 961 Statements fuer einen Aufruf. Auf SQLite im selben Prozess sind das 600 ms und faellt niemandem auf; gegen ein Postgres ueber einen Socket sind es bei 3 ms Round-Trip 5,3 Sekunden — exakt der gemessene Wert. Deshalb war es vorher schnell und ist es jetzt nicht: der teure Zweig zaehlt erst, seit SCA-Daten und Impact-Bewertungen geladen sind. Ohne gecachte Checks kehrt _weighted_score_for_policy sofort zum gespeicherten Score zurueck und die zwei Abfragen pro Policy entfallen. Wer URS und Compliance anbindet, schaltet den Pfad scharf. compute_urs_bulk() macht denselben Score in fuenf Abfragen, unabhaengig von der Flottengroesse: Assets, offene Vulnerabilities als Spaltenabfrage, Results, deren Checks, die Impact-Tabelle. Der Lesepfad schreibt dabei nicht mehr — bisher hat compute_ass weighted_score auf den geladenen Zeilen gesetzt, was ein GET per Autoflush zu UPDATEs gebracht hat. Persistiert wird nur noch, wo es gewollt ist (recompute-all und der naechtliche Job). compute_avs/compute_ass/compute_urs bleiben als duenne Wrapper ueber denselben Code, damit Einzel- und Massenpfad nicht auseinanderlaufen koennen. Die CPR-Formel steht jetzt als cpr_score() auf Modulebene, sodass der Massenpfad sie ueber eine Spaltenabfrage laufen lassen kann, statt pro Finding ein ORM-Objekt zu bauen — eine Quelle, keine zweite Kopie. Dabei aufgefallen: /compliance/assets hat get_compliance_summary() aufgerufen, das Ergebnis weggeworfen und dieselbe Aggregation nochmal inline gemacht — beide Kopien mit einer Hostname-Abfrage pro Asset in der Schleife. Zwei N+1-Schleifen fuer eine Liste. Jetzt eine gemeinsame _asset_rollups(), zwei Abfragen. Messung 265 Assets, 3 ms Round-Trip: 2121 Statements / 11,7 s → 6 Statements / 0,18 s, Ergebnis Zeile fuer Zeile identisch. - tests/test_urs_bulk_scoring.py pinnt Statement-Zahl unabhaengig von der Flottengroesse, Gleichheit mit dem Einzelpfad in allen drei avs_modes, und dass ein Lesen nichts schreibt - tests/test_compliance_rollup_queries.py pinnt dasselbe fuer das Rollup |
||
|
vulncheck
|
0a61b33770 |
feat(assets): manual decommission — the state "Show decommissioned" filtered for
The "Show decommissioned" checkbox sent include_inactive=true and the backend
filter honoured it correctly, but no code path ever wrote status=DECOMMISSIONED:
the syncs only set INACTIVE/ACTIVE, the edit modal had no status field, and
Delete hard-removes the asset with its findings (CASCADE) instead of retiring
it. The filter had no state to filter for, so the checkbox looked dead.
The PUT endpoint did accept `status`, but wrote it with a bare setattr — the
transition reached the audit log as a generic ASSET_UPDATED instead of the
ASSET_DEACTIVATED / ASSET_REACTIVATED entry every sync-driven transition gets.
- Lifecycle Status select in the asset edit modal (edit only, editor+)
- PUT /assets/{id} routes status through apply_status() so the trail names the
transition, with force=True: the operator-final guard is there to stop a sync
from reviving a retired asset, not the operator who retired it
- tests/test_asset_decommission.py pins audit event, default filter and undo
No UI button for the lifecycle reconcile — it stays the nightly 04:15 job plus
POST /assets/reconcile-lifecycle (editor+). The tester text listing a
"Lifecycle abgleichen" button described a control that never existed.
|
||
|
vulncheck
|
643fee40a6 |
fix(policies): gate Create/Delete behind admin, Edit behind editor
Same class as
|
||
|
vulncheck
|
2e1b8e8024 |
fix(assets): hide Exposure button from read-only users
The "⚡ Exposure" toolbar button posts to /assets/refresh-exposure,
which is guarded by RequireEditor. Every other mutating control on the
page (Add Asset, rescan, edit, delete) is wrapped in `canEdit`; this one
was not, so a read-only user saw it, clicked it, and got
"Access denied. Required role: editor" as a failure alert.
Wrap it in the same `canEdit` gate. No backend change — the 403 was
correct, the button should never have been reachable.
|
||
|
vulncheck
|
9c84cf2939 |
fix(security): validate token purpose, verify Wazuh TLS, gate two asset routes
Aus dem Security-Review dieser Branch. Vier Findings, alle mit einem
gemeinsamen Muster: eine Kontrolle existiert, greift aber nicht.
MFA war mit dem Passwort allein umgehbar. _issue_mfa_challenge hat das
Challenge-Token mit create_access_token gebaut — ein regulaerer,
signierter Access-JWT. get_current_user prueft Signatur, Ablauf, JTI,
sub und is_active, aber nie den mfa_pending-Claim; den liest nur
/auth/mfa/verify. Wer das Passwort hat, ruft /auth/login, nimmt das
mfa_token aus der Antwort und schickt es als Bearer an jeden geschuetzten
Endpoint — mit der vollen Rolle aus der DB-Zeile, weil PermissionChecker
die Rolle nicht aus dem Token liest. Dasselbe galt fuer das
Forced-Setup-Token, das in den SSO-Pfaden zusaetzlich als URL-Parameter
uebergeben wird, und fuer Refresh-Tokens: /auth/refresh prueft
type == "refresh", die Gegenrichtung war offen, also war ein
Refresh-Token ein 7-Tage-Bearer und die Rotation umgehbar.
Alle Tokens tragen jetzt einen type-Claim, und get_current_user laesst
nur "access" durch — positiv allowlisten, damit ein neuer Token-Typ per
Default abgelehnt statt per Default gueltig ist. Nebenwirkung: bestehende
Access-Tokens ohne type-Claim werden ungueltig. Refresh-Tokens tragen den
Claim schon, Clients holen sich also im Hintergrund ein neues
Access-Token; wer keins hat, loggt sich einmal neu ein.
Wazuh lief durchgaengig mit verify=False. 15 Call-Sites bauten den
Client mit cfg.get("verify_ssl", False), und das war kein Edge Case: der
wazuhConfig-State im Frontend hatte gar kein verify_ssl-Feld, der Save
schrieb den Key also nie, und der Settings-PUT ersetzt den ganzen Wert.
Der Fallback war der einzig erreichbare Zustand. Ueber diese Verbindung
gehen Manager- und Indexer-Credentials als HTTP Basic. Jetzt
bool(cfg.get("verify_ssl", True)) wie bei Nessus/vCenter/Intune, plus
eine Verify-SSL-Checkbox im Wazuh-Formular, damit ein self-signed Zert
bewusst statt stillschweigend akzeptiert wird.
setup.sh hat einen JWT-Key generiert und ihn nirgends hingeschrieben:
das sed suchte einen Platzhalter, den .env.example seit Laengerem nicht
mehr enthaelt, traf nichts, exit 0, und die naechste Zeile meldete
Erfolg. Die Instanz signierte also mit dem oeffentlich bekannten
CHANGE-ME-String — offline faelschbare Admin-Tokens. Das sed ersetzt
jetzt die ganze Zeile und verifiziert danach; wichtiger ist der
App-seitige Guard in jwt_handler, der Platzhalter und Keys unter 32
Zeichen beim Start ablehnt, so wie totp.py es fuer
AUTH_PROVIDER_CRYPTO_KEY schon tut. Damit ist auch der Operator
abgefangen, der .env.example kopiert und Schritt 2 vergisst.
Beide Setup-Skripte legten ausserdem einen Admin mit hardcodiertem
"changeme" an und umgingen damit die Staerke-Pruefung in db_init. Der
Block ist raus, create_initial_data ist der einzige Bootstrap-Pfad.
Dazu RequireEditor auf /assets/reconcile-lifecycle und
/assets/refresh-exposure — beide hatten nur get_current_user, waehrend
jede andere mutierende Route derselben Datei RequireEditor verlangt.
Nicht gefixt, bewusst: JIT-Provisioning verlinkt eine SSO-Identitaet per
unverifizierter E-Mail auf ein bestehendes lokales Konto
(jit_provisioner.py:60). Kein Privilege Gain, weil _refresh_role die
Rolle neu berechnet, aber ein Lockout des legitimen Admins ist moeglich.
Braucht eine Design-Entscheidung, kein Einzeiler.
tests/test_token_purpose.py deckt die Typ-Logik ab. 92 Tests gruen.
|
||
|
vulncheck
|
74c0312b5c |
docs(readme): document AUTH_PROVIDER_CRYPTO_KEY in first-time setup
The setup steps never mentioned it, so a fresh install keeps the shipped
CHANGE-ME-FERNET-KEY placeholder and the first MFA enrolment fails with a
bare HTTP 500 ("AUTH_PROVIDER_CRYPTO_KEY is not a valid Fernet key").
Nothing else is affected, which is exactly why it stays hidden until
someone turns on MFA.
Also corrects the reverse-proxy section, which still named the compose
fallback ports 3000/8000 instead of the 3003/8022 that .env.example ships.
Docs only — nothing to re-test.
|
||
|
vulncheck
|
21f85e4b89 |
fix(alembic): unbreak fresh installs at migration 028
A fresh `docker compose up` never came up. Migration 028 imported the
live ORM (`from app.models.asset import Asset`) and ran `db.query(Asset)`
against a database that is only at revision 028, so the SELECT asked for
`assets.intune_device_id` — a column revision 033 adds. Alembic aborted
with UndefinedColumn, the whole migration chain rolled back (one
transaction for all revisions), and the backend crash-looped against an
empty database.
028 is now raw SQL: one CTE that flips the legacy Nessus rows and writes
the audit entries, comparing `source::text` / `status::text` so it no
longer depends on today's enum labels either.
env.py switches to transaction_per_migration. 027 adds the
ASSET_DEACTIVATED enum label that 028 inserts, and PostgreSQL refuses to
use a new enum value in the transaction that added it ("unsafe use of new
value"). Per-migration transactions also make a failed upgrade resumable
instead of all-or-nothing.
Verified end to end from a clean `git archive` checkout: migrations run
027 -> 046, default admin is created, backend reports healthy, login
through the frontend proxy returns a session cookie.
tests/test_migrations_no_orm_imports.py locks the bug class down: no
migration may import app code, because the ORM mapping is always newer
than the schema of the revision it runs at.
|
||
|
vulncheck
|
ab6d4c6152 |
fix(kev-alert): separate source badges with a real space
Badges were emitted back-to-back (`</span><span>`) and relied only on
`.src { margin-right: 3px }` for the gap. Mail clients that drop margins on
inline elements rendered them merged: "CISA KEVENISA EUVD",
"CISA KEVENISA EUVDRANSOMWARE".
Join the labels with a literal space and add `white-space: nowrap` so a badge
never wraps mid-label. Regression test covers both.
|
||
|
vulncheck
|
36ecf7edaf |
docs(readme): stop listing AI models the app never hardcoded
The provider table named specific models — GPT-4.1 and o3, Claude Opus 4.5 and Sonnet 4.5, Gemini 3 Pro and 2.5 Pro, DeepSeek V3 and R1. Every one of those is now a generation or more behind, and two are already retired upstream: OpenAI sunsets o3 today, and Gemini 2.0 shut down on 1 June. The list was wrong in a way it could not stay right, because the app never read it. get_ai_models() in app/routers/settings.py queries each provider's own /models endpoint when the key is entered, so the dropdown already shows whatever that key can reach — a model released tomorrow appears without a code change. Documenting a snapshot of that alongside it only created something to go stale. Replaced with the provider list, their default endpoints, and the note that discovery is live. Same six providers as before; nothing in their support changed. Documentation only. Nothing to test. |
||
|
vulncheck
|
0b71453c48 |
chore(release): drop personal attribution from comments and docstrings
Comments across the codebase credited one individual by role and, in places, described that person's own machines: which SQL Server versions a host ran, which devices were enrolled, what a particular dashboard showed, how many findings sat open on which server. In a public repository that reads as a profile of someone's unpatched estate. The observations are why the code looks the way it does, so they stay. Every CVE id, version, build number, count and date is preserved, as are the verbatim quotes that motivated specific sort and filter rules — only the attribution changes, to "field report", "observed", "a host". A local variable in tests/test_autodesk_year.py was renamed for the same reason; its value and every assertion around it are byte-identical. PROJECT_OVERVIEW.md additionally loses a subtitle naming the kind of organisation this was built for, and a support section pointing at an internal team, both replaced with neutral wording. Comments, docstrings and markdown prose only: 74 files, 200 lines, one-for-one swaps. detect_changes reports 104 touched symbols and zero affected execution flows, and all 55 test scripts pass. Nothing here needs re-testing. |
||
|
vulncheck
|
262cd46652 |
chore(release): use neutral placeholders in examples and fixtures
Ahead of the public release, example values now use generic placeholders instead of values carried over from a live environment: the connection placeholders in the settings form, the sample data behind the mail-template preview, the hostnames in the EOL fixtures, and the device identifiers in the Intune re-enrolment fixtures. The README points at GitHub rather than the internal Git host. Comments, docstrings, HTML placeholder attributes and fixture strings only. No logic changed and the assertions pin the same behaviour as before, so there is nothing here to re-test. .gitignore additionally covers every .env variant (only literal .env and .env.local matched before, so a .env.production would have been picked up by git add .), the SAML and LDAPS key material .env.example tells operators to generate in the repo root, AI-tooling state, root-level node artifacts, generated report exports, and the untracked third-party checkout sitting in the working tree, which git add . would otherwise commit as a broken gitlink. Also untracks the local editor-assistant config and an empty root package-lock.json stub that had no package.json beside it. |