Patch zamknął CVE, ale nie cały attack primitive — Wazuh i „patched" ≠ „fixed"

W VM lubimy moment zamknięcia: scanner wykrywa podatność, powstaje ticket, owner aktualizuje system, kolejny skan nie pokazuje już starego CVE, status zmienia się na Closed. Problem zaczyna się, gdy zakładamy, że skoro CVE zostało naprawione, to cała klasa problemu również została usunięta.

CVE-2026-61800 w Wazuh to dobry przykład, dlaczego takie założenie bywa błędne. Nową podatność opisano jako incomplete fix for CVE-2026-30893. Pierwsza poprawka rzeczywiście zamknęła określoną ścieżkę path traversal, ale nie wyeliminowała całego mechanizmu pozwalającego zaufanemu peerowi przekierować synchronizowany plik do niebezpiecznego miejsca. Organizacja mogła więc poprawnie wdrożyć fix dla CVE-2026-30893, mieć wersję uznawaną za naprawioną, zamknąć finding — a mimo to nadal posiadać pokrewny attack primitive prowadzący do zapisu plików i potencjalnego RCE. To nie znaczy, że pierwszy patch „nic nie zrobił". Oznacza coś ciekawszego:

Remediation może być poprawna względem konkretnego CVE, ale niepełna względem rzeczywistego mechanizmu ataku.

I właśnie tu kończy się zwykłe patch management, a zaczyna Vulnerability Engineering.

Dwie luki, jeden subsystem

CVE-2026-30893 dotyczyło mechanizmu synchronizacji klastra Wazuh (wg NVD wersje >= 4.4.0 < 4.14.4): path traversal w procedurze synchronizacji, uwierzytelniony cluster peer mógł zapisać pliki poza katalogiem ekstrakcji, z możliwą eskalacją do wykonania kodu przez nadpisanie modułów Pythona ładowanych przez komponenty Wazuh. Naprawione w 4.14.4. Klasyczny VM: CVE → affected → fixed → upgrade → rescan → close. Tyle że historia się nie kończy.

CVE-2026-61800 obejmuje Wazuh 4.4.0–4.14.6 i jest naprawione w 4.14.7. Strona z cluster key może podczas synchronizacji na worker node zapisywać, nadpisywać lub usuwać pliki w dowolnych lokalizacjach pod /var/ossec — co może prowadzić do wykonania kodu jako root, jeśli attacker umieści zawartość w ścieżce wykonywanej przez uprzywilejowane komponenty. Pierwsza poprawka ograniczyła wyjście poza /var/ossec, ale nie sprawdzała wystarczająco, czy plik ląduje we właściwym katalogu wewnątrz tego drzewa:

path stays inside allowed root ≠ file is authorized to land at this exact destination

Path confinement to nie authorization

Wyobraźmy sobie aplikację piszącą wyłącznie do /app/data/, z kontrolą „final_path must stay inside /app/data/". Dobry początek. Ale jeśli wewnątrz są /uploads/, /cache/, /hooks/, /scripts/, a użytkownik, który powinien pisać tylko do uploads, może przekierować plik do scripts — path confinement działa, a granica bezpieczeństwa nadal jest złamana. Potrzebujemy dwóch pytań: (1) czy ścieżka pozostaje w dozwolonym root? (2) czy plik trafia do dozwolonego miejsca w ramach tego root? Druga warstwa jest sednem CVE-2026-61800.

Dlaczego to ważne dla VM

Typowy system zobaczy dwa osobne rekordy: CVE-2026-30893 (Closed, fixed 4.14.4) i CVE-2026-61800 (Open, fixed 4.14.7). Technicznie to dwa CVE. Inżyniersko — jedna historia słabości w tym samym subsystemie: cluster file synchronization → path trust → arbitrary file placement → execution path. Dlatego system VM powinien umieć przechowywać relację:

relationship: type: incomplete_fix_of parent: CVE-2026-30893 child: CVE-2026-61800

To nie kosmetyka — taka relacja mówi, że wszystkie assety wcześniej dotknięte CVE-2026-30893 powinny zostać ponownie ocenione. Formalnie CVE-2026-30893 zostało naprawione (nie twierdzimy fałszywie, że „nadal jest otwarte"), ale pojawienie się incomplete fix powinno uruchomić re-evaluate previous remediation population. Jeśli 500 assetów miało CVE-2026-30893, zaktualizowano je i zamknięto — po CVE-2026-61800 nie czekamy, aż scanner kiedyś je znajdzie. Pytamy: gdzie są te 500 dzisiaj, które nadal mają 4.14.4–4.14.6, które pełnią rolę workerów, czy są nieskanowane node'y i jak chroniony jest cluster key. Historia remediation staje się źródłem nowych zadań.

Czy wcześniejszy rescan był bezwartościowy? Nie — jeśli po 4.14.4 scanner nie wykrywał CVE-2026-30893, działał poprawnie. Jego pytanie brzmiało „czy CVE-2026-30893 nadal występuje?" i odpowiedź „nie" mogła być prawidłowa. Scanner nie musiał znać nieujawnionego wariantu. Dlatego trzeba rozdzielić verification of known CVE remediation od proof that the whole weakness family is gone — to drugie jest znacznie trudniejsze.

Trzy poziomy walidacji remediation

1 · Version verification: fixed version installed.

2 · Vulnerability verification: known exploit path no longer works.

3 · Primitive verification: dangerous capability itself was removed.

Nie da się analizować source diffu i testować wariantów dla dziesiątek tysięcy CVE — ale warto robić głębszą walidację dla Critical RCE, auth bypass, sandbox escape, arbitrary file write, deserializacji, podatności aktywnie wykorzystywanych oraz systemów bezpieczeństwa i infrastruktury uprzywilejowanej. Incomplete fix powinien być osobnym sygnałem: system może przechowywać fix_quality: { incomplete_fix_history: true } i jeśli nowa podatność jest bypassem albo incomplete fixem — automatycznie podnieść priorytet, otworzyć ponowną walidację, znaleźć historyczne findings, skrócić SLA i zażądać technicznego potwierdzenia po wdrożeniu. Nie chodzi o „karanie vendora" (niepełne poprawki zdarzają się wszędzie), tylko o reagowanie na nową jakość informacji.

Patch lineage zamiast płaskiej listy CVE

Dashboard „CVE-2026-30893 CLOSED / CVE-2026-61800 OPEN" jest poprawny, ale ubogi. Lepszy model pokazuje historię słabości:

Cluster file sync path validation │ ├── CVE-2026-30893 │ ├── problem: traversal outside /var/ossec │ ├── fix: 4.14.4 │ └── later incomplete-fix relationship │ └── CVE-2026-61800 ├── problem: unsafe placement inside /var/ossec ├── fix: 4.14.7 └── current remediation

Cluster key, CVSS 9.1 i asset context

CVE-2026-61800 ma CVSS 9.1, ale wymaga cluster key. Można pochopnie uznać „skoro trzeba mieć klucz, ryzyko jest małe". Nie zawsze — cluster key to element zaufania między node'ami. Jeśli zostanie wykradziony z hosta, ujawniony przez złe uprawnienia, pozyskany z konfiguracji albo przejęty po wcześniejszym footholdzie, może umożliwić atak na kolejne systemy w zaufanym klastrze. Nie wystarczy więc wiedzieć Privileges Required = High — trzeba wiedzieć: jakie uprawnienie, jaki credential, jaką granicę zaufania otwiera. Dodatkowo Wazuh to platforma bezpieczeństwa — komponent o wysokiej wartości (telemetria, active response, szeroka widoczność, wysokie uprawnienia). Kompromitacja narzędzia ochronnego może wpłynąć na telemetrykę, ograniczyć detekcję, zmienić active response i stworzyć ścieżkę lateral movement. Kolejny powód, dla którego sam CVSS nie wystarcza.

Jak powinien wyglądać workflow i ticket?

Po publikacji CVE-2026-61800:

ingest new CVE,
detect incomplete_fix_of CVE-2026-30893,
query historical affected assets,
identify current versions,
identify clustered deployments,
upgrade all nodes to 4.14.7+,
verify version consistency across cluster,
assess cluster key exposure,
rotate key if compromise is suspected,
rescan / validate.

Kluczowy jest krok trzeci — nie zaczynamy od zera, korzystamy z wiedzy z poprzedniej podatności. Ticket to nie tylko „upgrade Wazuh to 4.14.7", lecz:

Finding: CVE-2026-61800 Relationship: incomplete fix for CVE-2026-30893 Affected: Wazuh 4.4.0 - 4.14.6 Fixed: 4.14.7 Precondition: cluster key Impact: arbitrary write/overwrite/delete under /var/ossec, potential root RCE Required: - upgrade every manager/worker node - verify cluster-wide version consistency - assess cluster key exposure - validate remediation

Kiedy „patched" naprawdę oznacza „fixed"?

Najbezpieczniej: „patched" oznacza, że wdrożyliśmy poprawkę dla znanej wersji problemu — nie zawsze „cała klasa ataku została definitywnie wyeliminowana". Nie istnieje patch gwarantujący brak przyszłych błędów, ale system VM może być przygotowany na zmianę wiedzy. Gdy pojawia się incomplete fix, powinniśmy rozumieć, że our previous remediation assumptions changed — i uruchomić ponowną ocenę. CVE jest świetnym identyfikatorem, ale rzeczywistość techniczna nie jest zorganizowana według numerów: jedna słabość może dostać kilka CVE, zostać poprawiona etapami, mieć bypass, mieć incomplete fix, wrócić w innym miejscu. Dlatego VE patrzy też na root cause, attack path, subsystem, trust boundary i fix lineage.

Wniosek

CVE-2026-61800 pokazuje, że remediation nie jest jednorazowym wydarzeniem. W kwietniu prawidłowe było „CVE-2026-30893 fixed in 4.14.4"; w sierpniu — „fix zatrzymał traversal poza /var/ossec, ale została inna niebezpieczna ścieżka umieszczenia pliku". Obie mogą być prawdziwe. Dlatego dojrzały system nie pyta wyłącznie „czy CVE jest zamknięte?", lecz również: czy pojawiły się nowe fakty, które zmieniają naszą ocenę wcześniejszej remediation? To różnica między ticket management a Vulnerability Engineering.

Źródła

NVD — CVE-2026-30893 (29.04.2026) — nvd.nist.gov
Wazuh / GitHub — GHSA-m8rw-v4f6-8787 — github.com/wazuh/wazuh
Wazuh / GitHub — GHSA-chmg-89pf-2q82 (incomplete fix) — github.com/wazuh/wazuh
CVE-2026-61800 (ujawnione 28.08.2026) — cve.org · nvd.nist.gov
Wazuh Security Policy — github.com/wazuh/wazuh/security

Nota redakcyjna: stan informacji 28 sierpnia 2026, 22:01 CEST. CVE-2026-61800 opisano jako incomplete fix dla CVE-2026-30893; naprawione w Wazuh 4.14.7. Pojęcie „attack primitive" jest tu kategorią analityczną VMRT, a nie formalnym polem standardu CVE.