Na blogu vmrt.pl opublikowano dotąd 22 rozbiory konkretnych podatności. Każdy stał osobno: inny vendor, inne CVE, inny mechanizm. LAB dostał jedno zadanie: przeczytać wszystkie 22 jako jeden zbiór i sprawdzić, czy powtarza się w nich mechanizm — czyli to samo miejsce, w którym proces zarządzania podatnościami przestaje działać. Nie „jakie CVE są groźne", tylko gdzie dokładnie pęka proces.
Poniżej: pięć powtarzalnych punktów awarii, dla każdego krótka debata agentów, a na końcu wspólny Finding Council, mapa sporu i pytania, na które LAB nie zna odpowiedzi. Wszystko wygenerowane przez AI — traktuj jak hipotezy do sprawdzenia, nie jak werdykt. Aktualizacja: zbiór wejściowy rozszerzono z pierwszych 10 przypadków do 22 — nowa partia (sierpień 2026) dołożyła piąty powtarzalny wzorzec: deklarowane uprawnienie ≠ efektywne uprawnienie.
Materiał wejściowy — 22 przypadki
- Log4j2 i FOIS — obecność biblioteki ≠ podatność (reachability, gadget chain).
- Dwa Critical RCE w Next.js — podatna wersja ≠ podatny system; zależność transytywna.
- Citrix: „DoS" vs pre-auth RCE — spór o severity między vendorem, badaczami i NVD.
- JFrog: Medium 5.3, ale KEV — severity ≠ priorytet.
- KEV vs EPSS — dwa wskaźniki, dwa różne pytania.
- PaperCut: aktywne ataki bez CVE i patcha — CVE nie jest kluczem głównym VM.
- WatchGuard: wiele CVE, jedna remediation — finding ≠ działanie naprawcze.
- Wazuh: incomplete fix — „patched" ≠ „fixed".
- JetBrains Cadence: remediation failure — patch był, a i tak przejęto serwer.
- Uptrain: EOL jako finding — brak utrzymania sam jest ryzykiem.
- AWS SSM: ograniczone IAM do root — least privilege to własność całego chainu.
- Budibase: admin aplikacji ≠ root — PR:H opisuje warunek wejścia, nie przekraczaną granicę.
- Cosmos EVM: not reproduced — brak reprodukcji ≠ dowód niepodatności.
- Rancher: topology-aware VM — affected by version ≠ attack path exists.
- Ceph: read-only do root — credential transitivity zamiast klasycznej eskalacji.
- MCP: 12 CVE i jakość danych — provenance, aktualność i konflikty pól, nie sam import.
- Pimcore: content editor do RCE — „low privilege", które generuje PHP na serwerze.
- WooCommerce: „SSRF" do payment bypass — CWE ukrywa realny biznesowy impact.
- Linux perf: granularność produktu — kod w userspace, choć CVE mówi „kernel".
- rust-iot: dwa CVE, jeden łańcuch — capabilities się składają, choć CVSS nie.
- Sigma Forms: vulnerable by default — precondition dostarczona przez producenta.
- Skyvern: drugi render bez sandboxa — control ginie między etapami pipeline.
Teza 1 — Największa luka procesu leży między REMEDIATED a VERIFIED
Trzy przypadki mówią to samo z różnych stron: samo „wykonaliśmy naprawę" nie jest jeszcze dowodem, że ryzyko zniknęło.
W Wazuh patch był poprawny względem CVE, ale niepełny względem mechanizmu (incomplete fix). W JetBrains patch istniał i był znany, a jeden serwer i tak został przejęty — bo nie wdrożono i nie zweryfikowano. W WatchGuard zliczono 800 findings, ale realnym krokiem była jedna aktualizacja. Wspólny mianownik: proces kończył się deklaracją, nie dowodem.
To dokładnie luka VERIFIED. „Ticket Closed" opisuje stan biletu, nie stan ryzyka. Weryfikacja ma trzy poziomy: wersja zainstalowana, znana ścieżka ataku nie działa, sam groźny prymityw został usunięty. Wazuh pokazuje, że można przejść poziom 1 i 2, a oblać 3.
Ostrożnie z uogólnianiem trzech przypadków w prawo procesu. Może po prostu wybrano do publikacji historie, w których weryfikacja zawiodła? To selection bias. Nie wiemy, w ilu tysiącach zamknięć weryfikacja zadziałała i nic o nich nie napisano.
Słuszne. Teza nie brzmi „weryfikacja zawsze zawodzi", tylko „gdy proces pęka, pęka najczęściej właśnie tu". To hipoteza o rozkładzie miejsc awarii, nie o częstości. Do potwierdzenia potrzeba danych z realnego programu VM, których nie mamy.
Nowa partia wzmacnia ten wzorzec z innej strony: bywa, że sam patch nie wystarcza do zamknięcia ryzyka. W Ceph upgrade usuwa możliwość ponownego wycieku, ale nie unieważnia sekretów, które już mogły wyciec — potrzebna jest rotacja kluczy. W rust-iot naprawa kodu nie zmienia haseł, które ktoś mógł już zebrać. To rozdzielenie vulnerability remediation od compromise remediation — a klasyczny „ticket closed" nie ma nawet pola na to drugie.
To już nie jest ta sama teza. „Naprawa nie zawsze zamyka ryzyko" (Ceph, rust-iot) różni się od „naprawy nie zweryfikowano" (JetBrains). Mieszanie ich w jeden worek zawyża wrażenie, że wszystko sprowadza się do weryfikacji. Część z tych przypadków to raczej niepełna definicja naprawy, nie brak dowodu.
REMEDIATED (zrobiliśmy naprawę) ≠ VERIFIED (mamy dowód, że ryzyko zniknęło)
Teza 2 — „Obecność" komponentu to nie „osiągalność", a już na pewno nie „exploitowalność"
W Log4j2 da się zbudować łańcuch do RCE, a mimo to obecność biblioteki nie oznacza podatności — liczy się, czy vulnerable code path jest osiągalny i czy istnieje odbiornik. W Next.js jeden Critical zależy od OS/architektury/cache, drugi to zależność transytywna (sharp → libheif → AVIF). Skaner widzi „wersję", nie „system".
I tu wchodzi VEX. Status not_affected z justyfikacją vulnerable_code_not_in_execute_path to nie wykręt — to jest właśnie ta warstwa, której skaner nie ma. Bez reachability lista podatności jest listą komponentów, nie ryzyk.
Uwaga na drugą stronę tego ostrza. „Not affected, bo nieosiągalne" bywa wygodną wymówką, gdy nikt realnie nie sprawdził call-grafu. Reachability zniżający ryzyko wymaga równie twardego dowodu jak reachability je podnoszący. Inaczej to tylko ładniej brzmiący false negative.
Nowe przypadki pokazują, że „osiągalność" ma kilka warstw. Linux perf: CVE mówi „kernel Critical", a podatny kod siedzi w userspace i wymaga przetworzenia niezaufanego pliku. Rancher: ten sam advisory jest lub nie jest exploitable zależnie od topologii (HA, SAML, multi-cluster). Sigma Forms: precondition istnieje, bo dostarcza ją szablon producenta. Skyvern: dane stają się osiągalne dla interpretera dopiero na drugim etapie pipeline. Wspólne: między „affected by version" a „exploitable here" jest cała przestrzeń kontekstu.
I ostrzeżenie z Cosmos EVM: „nie udało się odtworzyć" zamieniono na „produkcja bezpieczna" — i zaatakowano sześć sieci. not_reproduced to wynik testu, nie not_affected. Ta sama warstwa oceny, która słusznie zniża ryzyko, potrafi też wygenerować false negative, jeśli status myli brak dowodu z dowodem braku.
component present → reachable → exploitable → relevant to this asset — każda strzałka wymaga osobnego dowodu.
Teza 3 — Severity opisuje podatność, priorytet opisuje Twoją decyzję. To nie to samo pole
JFrog: CVSS 5.3 Medium, a jednak CISA KEV — potwierdzona eksploatacja na elemencie supply chain. KEV vs EPSS: EPSS ~0,356%, a KEV = tak. Te wskaźniki nie przeczą sobie — odpowiadają na różne pytania. KEV to dowód, EPSS to predykcja.
Citrix dokłada trzeci wymiar: sam opis podatności bywa sporny. Vendor pisał „DoS", badacze pokazali pre-auth RCE, NVD dał 9.8. Jeśli severity potrafi się różnić o kilka punktów zależnie od źródła, to budowanie priorytetu na jednej liczbie jest kruche.
Stąd SSVC zamiast pojedynczego score'u: exploitation, automatable, exposure, asset criticality → decyzja Track/Attend/Act. Medium 5.3 i „Act" mogą istnieć jednocześnie. To nie niekonsekwencja — to rozdzielenie opisu problemu od decyzji o działaniu.
Nowa partia pokazuje, że nawet pojedyncze pole CVSS bywa mylące. Budibase: PR:H brzmi „mało pilne", a exploit przekracza granicę aplikacja→root. Pimcore: PR:L ukrywa, że „content editor" generuje PHP na serwerze (i spór Scope 9.9 vs 8.8). WooCommerce: CWE-918 „SSRF" nie mówi, że realnym skutkiem jest darmowe zamówienie i wyciek credentiali gatewaya. Etykieta opisuje mechanizm, nie decyzję.
To rozsądne, ale grozi eskalacją każdego findingu do „a może jednak Critical". Jeśli po każdym polu CVSS dokładamy „ale w kontekście…", tracimy porównywalność. MCP dokłada odwrotny problem: różne CVSS v3.1 i v4.0 to nie sprzeczność, a mimo to bywają czytane jako „konflikt danych". Kontekst ma uzupełniać score, nie zastępować go narracją.
Teza 4 — CVE jest świetnym identyfikatorem, ale nie kluczem głównym VM
PaperCut: aktywna eksploatacja bez publicznego CVE i bez patcha — ale z mitygacją. Jeśli proces VM działa tylko wtedy, gdy istnieje numer CVE, to w tym momencie stoi.
Uptrain: cztery CVE składają się w zero-click RCE, a upstream praktycznie nie żyje. Tu findingiem nie jest pojedyncze CVE, tylko brak bezpiecznej przyszłości tego komponentu. Formularz „CVE → fixed version" nie ma nawet pola na tę sytuację.
Czyli proponujecie findingi bez CVE. To ryzykowne operacyjnie: jak priorytetyzować i mierzyć coś, czego skaner nie zgłasza? Bez dyscypliny „finding bez CVE" zamienia się w worek na wszystko, czego nie chce się zamknąć.
Zgoda, dlatego potrzebny jest status (MITIGATED, NO FIX AVAILABLE, EOL) i właściciel — tak samo jak dla CVE. CVE to jeden z identyfikatorów, nie warunek istnienia ryzyka.
Nowa partia pokazuje drugą stronę: CVE bywa też niepełnym albo niesynchronizowanym rekordem. MCP: 12 CVE opublikowanych automatycznie w kilka sekund, z polami, które w różnych feedach mówią różne rzeczy — tu problemem nie jest brak CVE, lecz provenance i aktualność. Linux perf: product = Linux kernel jest poprawny, ale mapuje na zły attack surface. Rancher w ogóle działa na GHSA, nie CVE. Klucz główny musi być bogatszy niż numer.
Teza 5 — Deklarowane uprawnienie to nie efektywne uprawnienie. Eskalacja idzie przez zaufanie, nie przez pojedyncze CVE
To wzorzec, który wyłonił się dopiero w nowej partii przypadków — i domyka obraz od strony skutku, nie oceny.
Cztery przypadki opowiadają ten sam ruch. AWS SSM: wąskie ssm:SendCommand → zapis pliku jako root. Ceph: mon allow r → odczyt SSH key → root całego klastra. Budibase: admin aplikacji → kod w procesie Node.js → sekrety. rust-iot: brak auth + hasła w plaintext → przejęcie kont. Deklarowane uprawnienie na wejściu jest niskie; efektywne — po przejściu przez agenta, sekret albo credential — jest wysokie.
Kluczowe pytanie nie brzmi „jaki jest PR?", tylko „co można wyprowadzić z tego dostępu i jaka granica znika po exploicie?". To credential transitivity i boundary crossing — wymiary, których pojedyncze pole CVSS nie widzi. Systemy niosące sekrety (Ceph, agenci zarządzania, CI/CD) powinny mieć z tego powodu wyższy asset criticality.
Ostrożnie — to najmłodszy wzorzec, oparty na czterech przypadkach z jednej fali publikacji. Łatwo tu o pareidolię: „chain do root" brzmi efektownie, ale część z tych eskalacji wymaga realnych preconditions (dostęp do sieci klastra, ważny token). „Efektywne uprawnienie" nie może stać się wytrychem, którym każde PR:L podnosimy do Critical bez dowodu ścieżki.
Zgoda. Teza jest o modelowaniu: trzymać obok siebie „privilege required" i „effective privilege after exploitation", a nie zastępować jednego drugim. Dowód ścieżki obowiązuje tak samo, jak przy reachability z Tezy 2.
DECLARED PRIVILEGE (co formalnie wolno) ≠ EFFECTIVE PRIVILEGE (co realnie da się osiągnąć przez cały chain)
Finding Council — meta-teza
Agenci ocenili niezależnie jedno twierdzenie: „W tych 22 przypadkach dominującym miejscem awarii procesu jest odcinek między wykonaniem naprawy a udowodnieniem skuteczności (REMEDIATED→VERIFIED)." Skala 0–100%, kotwice kalibracyjne jak w metodzie VMRT. To liczby generowane przez AI — ilustrują rozrzut opinii agentów, nie są pomiarem. Po rozszerzeniu zbioru do 22 przypadków oceny lekko spadły — nowa partia dołożyła wzorce (efektywne uprawnienie, jakość danych, granularność), które nie mieszczą się w odcinku remediated→verified.
| Agent | Ocena | Uzasadnienie (skrót) |
|---|---|---|
| Synthesis Analyst | 65% | Wzorzec nadal dominujący, ale rozcieńczony przez nowe klasy awarii. |
| Remediation Verifier | 75% | „closed ≠ verified" wciąż najsilniejszy; Ceph/rust-iot dokładają „naprawa ≠ pełna naprawa". |
| Reachability Analyst | 45% | Coraz więcej awarii leży wcześniej — kontekst, topologia, granularność. |
| Threat Intel Analyst | 45% | Sporo przypadków to spór o severity/etykietę, nie porażka weryfikacji. |
| Privilege Analyst | 40% | Eskalacja przez uprawnienie/credential to osobny wzorzec, nie odcinek verified. |
| Red Team | 30% | Selection bias + coraz szerszy zbiór wzorców osłabia „jedno dominujące miejsce". |
Mediana: 45%. Zakres: 30–75%. Rozszerzenie zbioru z 10 do 22 przypadków obniżyło zgodę wobec pierwotnej tezy — i to jest uczciwy wynik: więcej danych ujawniło, że „gdzie pęka proces" ma nie jedno, lecz co najmniej pięć miejsc. Duży rozrzut nie jest szumem — to sygnał sporu o kluczowe założenie: czy te 22 teksty to reprezentatywna próbka, czy zbiór dobrany pod z góry przyjętą tezę. LAB nie rozstrzyga tego na korzyść żadnej strony.
Mapa sporu
| Spór | Stanowisko A | Stanowisko B | Co by rozstrzygnęło |
|---|---|---|---|
| Gdzie pęka proces? | Głównie REMEDIATED→VERIFIED | Równie często na etapie oceny (reachability, severity) | Dane z realnego programu VM: statystyka etapów, na których zamknięcia okazały się błędne |
| Reprezentatywność | Wzorce są realne i powtarzalne | Próbka dobrana pod tezę (selection bias) | Analiza przypadków, w których proces zadziałał — a takich nie opisano |
| Findingi bez CVE | Konieczne (EOL, 0-day bez CVE) | Trudne do egzekwowania i mierzenia | Model statusów i SLA dla findingów bez CVE, przetestowany w praktyce |
| Effective privilege | Trzeba modelować chain (credential→root) | Grozi eskalacją każdego PR:L do Critical bez dowodu | Dane, jak często pozornie wąskie uprawnienie realnie prowadziło do przejęcia hosta/sekretów |
Red Team — zanim uznasz to za prawdę
- Czy 22 opublikowane teksty to próbka losowa, czy zestaw dobrany pod ciekawe wnioski? Prawie na pewno to drugie — publikuje się to, co pokazuje wzorzec.
- Czy „reachability zniża ryzyko" nie stanie się wygodną wymówką bez twardego dowodu call-grafu?
- Czy rozdmuchane frameworki (SSVC, VEX, patch lineage) da się utrzymać w organizacji, która nie ma nawet wiarygodnego inventory?
- Czy sama ta synteza — napisana przez AI — nie „widzi wzorca" tam, gdzie jest dwadzieścia kilka niezależnych historii? Pareidolia analityczna jest realnym ryzykiem, a im więcej przypadków, tym łatwiej dopasować je do z góry przyjętych pięciu tez.
Czego LAB nie wie
Nie znamy realnych statystyk: na którym etapie procesu VM najczęściej dochodzi do błędnych zamknięć, jak liczne są nieopisane przypadki, w których weryfikacja zadziałała, ani czy proponowane mechanizmy (patch lineage, findingi bez CVE, VEX-owe not_affected) obniżają ryzyko w praktyce, czy tylko dokładają pracy. To są hipotezy do przetestowania na prawdziwych danych, nie ustalenia.
Wniosek
Dwadzieścia dwie niezależne historie z bloga układają się — zdaniem agentów AI — w jeden obraz o pięciu pęknięciach: klasyczny proces VM zna moment „naprawiliśmy", ale słabo zna moment „udowodniliśmy". Pęka na styku obecność/osiągalność, severity/priorytet, CVE/ryzyko, deklarowane/efektywne uprawnienie i — najczęściej, choć już nie tak dominująco jak przy pierwszych dziesięciu — remediated/verified. Co ciekawe, dołożenie kolejnych 12 przypadków obniżyło zgodę agentów wobec pierwotnej tezy: więcej danych pokazało więcej miejsc awarii, nie jedno. Czy to prawda o całym VM, czy tylko o dwudziestu dwóch ciekawie dobranych przypadkach? Tego ta analiza nie rozstrzyga. I właśnie dlatego jej ostatnie zdanie jest pytaniem, nie tezą: jaki masz dowód, że ryzyko naprawdę zniknęło?
Odniesienia (wpisy na tej stronie)
- Blog vmrt.pl — 22 rozbiory przypadków, do których odnosi się ta synteza: vmrt.pl/blog
- Metoda oceny (SSVC — drzewo decyzyjne priorytetu): cisa.gov/ssvc
- Metoda oceny (CISA KEV — potwierdzona eksploatacja): cisa.gov/kev
- Metoda oceny (EPSS — predykcja eksploatacji): first.org/epss
Nota metodyczna: to jest wynik pracy VMRT Lab — wieloagentowego procesu analitycznego realizowanego przez model AI (framework „VMRT Vulnerability Reality Lab"). „Głosy agentów", oceny procentowe i mapa sporu są konstrukcją analityczną wygenerowaną przez AI, mającą pokazać różne perspektywy i niepewność — nie są opiniami realnych, odrębnych osób ani pomiarem empirycznym. Synteza odnosi się do artykułów opublikowanych na blogu vmrt.pl; wszystkie fakty źródłowe (CVE, wersje, advisory) znajdują się w linkowanych wpisach. Materiał edukacyjny — przed wykorzystaniem w decyzjach zweryfikuj u człowieka. Stan: 31 sierpnia 2026 (zbiór wejściowy rozszerzony z 10 do 22 przypadków).