Stormshield SNS CVE-2026-111090 i 113469: vendor sam przelicza 7.8 na 6.0 „medium”. Environmental score vendora to hipoteza o Twoim środowisku

16 października 2026 Stormshield opublikował dwa advisories dla firewalli Stormshield Network Security (SNS). W obu chodzi o błąd logiczny w weryfikacji podpisu: SNS przyjmował nieuwierzytelnione pliki aktualizacji firmware i licencji (CVE-2026-111090) oraz nieuwierzytelnione dane dynamiczne pobierane przez Autoupdate (CVE-2026-113469). W NVD oba mają CVSS 3.1 7.8 i 7.5, czyli High. Na stronie vendora oba są „medium”, bo Stormshield sam policzył wynik środowiskowy: 6.0 i 6.7. To rzadki przypadek, w którym vendor pokazuje cały wektor environmental, więc da się sprawdzić, co dokładnie założył. Przy pierwszym CVE założenie brzmi „plik wgrywa administrator”. Przy drugim, gdzie dane przychodzą automatycznie, vendor żadnej obniżki środowiskowej nie zrobił, a „medium” bierze się z czego innego.

Dwa advisories, dwa różne „medium”

Wektory, wyniki i opisy poniżej pochodzą wprost z advisories Stormshield. Wektory bazowe są identyczne z tymi, które CNA Airbus wpisało do NVD.

Przy pierwszym czytaniu oba wiersze wyglądają podobnie: vendor bierze High, dostaje medium. Rozkład wektorów pokazuje jednak dwa różne mechanizmy. W 111090 wynik spada, bo vendor zmienił model atakującego. W 113469 metryki środowiskowe są przepisane z bazowych 1:1, a spadek z 7.5 na 6.7 wynika wyłącznie z metryk temporal: E:P (jest PoC) i RL:O (jest oficjalna poprawka).

CVE-2026-111090: skąd 6.0

Wektor bazowy opisuje atakującego bez uprawnień (PR:N), który potrzebuje interakcji użytkownika (UI:R). W praktyce: ktoś podsuwa spreparowany plik aktualizacji albo licencji, a administrator go wgrywa. Wektor środowiskowy vendora zamienia to na MPR:H/MUI:N, czyli na atakującego, który sam ma uprawnienia administratora i niczyjej pomocy nie potrzebuje. Vendor nie uzasadnia tej zmiany w advisory. Moja interpretacja: Stormshield przyjmuje, że plik do urządzenia trafia tylko ręką administratora, więc skoro admin już jest „w środku”, błąd niewiele mu dodaje.

Policzyłem warianty wzorami CVSS 3.1, żeby zobaczyć, która metryka ile waży. To moje obliczenia, nie dane vendora.

Z tabeli wynikają trzy rzeczy. Po pierwsze, całe przejście z 7.0 na 6.0 robi MPR:H. MUI:N działa w przeciwną stronę, a CR/IR/AR:H vendor ustawił na maksimum, co jest uczciwe dla firewalla. Po drugie, „6.0” zawiera już rabat za istniejącą poprawkę (RL:O). Na gałęzi 4.3, dla której poprawki nie ma, ten rabat się nie należy. Po trzecie, jeśli w Twoim środowisku plik może trafić do firewalla bez świadomej decyzji administratora, wynik wraca do 7.6.

Tu leży sedno. Model „admin wgrywa plik, więc atakujący musi być adminem” myli dwa scenariusze. Administrator, który wgrywa plik firmware pobrany z forum, otrzymany mailem od „wsparcia” albo skopiowany z udziału sieciowego, nie jest atakującym. Jest ofiarą, a to dokładnie scenariusz z wektora bazowego (PR:N/UI:R). Sam vendor w obejściu każe sprawdzać SHA-256 każdego pliku względem portalu MyStormshield i pobierać pliki tylko z MyStormshield. Gdyby jedynym realnym scenariuszem był złośliwy admin, takie zalecenie nie miałoby sensu, bo złośliwy admin nie będzie sprawdzał hashy. Advisory podaje też alternatywę: „or to use automatic verification via SNS”. Co dokładnie oznacza ta automatyczna weryfikacja i czy obejmuje pliki wgrywane ręcznie, advisory nie wyjaśnia: niepotwierdzone.

Jest jeszcze jedna rozbieżność. Release notes wersji 5.0.10, 5.1.4 EA i 4.8.20 LTSB opisują poprawkę dla 2026-031 jako „Vulnerabilities have been fixed in the firmware update, license installation, and configuration restoration modules”. Advisory mówi tylko o plikach aktualizacji i licencji. Czy przywracanie kopii konfiguracji było podatne w ten sam sposób, ze źródeł nie wynika: niepotwierdzone. Jeśli tak, to kolejny typ pliku, który administrator wgrywa z zewnętrznego źródła, np. z archiwum backupów.

CVE-2026-113469: kanał automatyczny bez obniżki

Drugie advisory dotyczy danych, które SNS pobiera sam, w procedurze Autoupdate (moduł Active Update). Tutaj nikt niczego nie wgrywa ręcznie, więc vendor nie miał podstaw do MPR:H i rzeczywiście go nie użył. Wektor bazowy AV:A/AC:H/PR:N/UI:N opisuje atakującego, który jest w sąsiedniej sieci i musi spełnić trudne warunki. Moja interpretacja: chodzi o pozycję między firewallem a serwerem aktualizacji, czyli o podmianę odpowiedzi w drodze. Vendor tego wprost nie pisze.

Co obejmują „dynamic data”? Advisory tego nie wylicza. Dokumentacja Stormshield (SMC, „Customizing Active Update settings”) podaje kategorie baz Active Update: sygnatury antywirusowe (ClamAV, Advanced Antivirus), sygnatury IPS (contextual protection signatures), wbudowaną bazę URL, czarne listy antyspamowe, główne urzędy certyfikacji (Root Certification Authorities), geolokalizację i reputację IP, dane modułu zarządzania podatnościami oraz ikony aplikacji. Których z tych kategorii dotyczy błąd weryfikacji podpisu, nie potwierdziłem. Jeśli dotyczy listy root CA albo sygnatur IPS, skutek nie ogranicza się do „złych danych”: podmieniona lista zaufanych CA wpływa na wszystko, co firewall weryfikuje przez TLS, a podmienione sygnatury mogą wyłączyć detekcję. To moje wnioski z opisu modułów, nie ustalenia vendora.

Obejście z advisory: używać tylko oficjalnych serwerów aktualizacji Stormshield albo mirrorów SMC, z włączonym HTTPS. Przy własnych serwerach aktualizacji: HTTPS i porównanie SHA-256 plików z serwerami oficjalnymi. Dokumentacja SNS przewiduje takie własne serwery („internal mirror sites”) w module Active Update, w sekcji „Server configuration”, a komenda CLI CONFIG AUTOUPDATE SERVER przyjmuje do ośmiu URL-i, także http://. Pierwszy przykład w referencji CLI to wręcz url="http://www.stormshield.eu/autoupdate". Dla VM oznacza to, że ekspozycja zależy od konfiguracji, której skaner wersji nie widzi:

• Serwery oficjalne po HTTPS. Atakujący musi przejąć ruch TLS do Stormshield. Wektor vendora (AV:A/AC:H) pasuje.
• Własny mirror albo serwer z sygnaturami po HTTP. Podmiana w drodze nie wymaga łamania TLS. AC:H przestaje być oczywiste.
• Własny mirror, do którego ktoś ma zapis. Atakujący nie musi być w drodze, wystarczy, że podmieni plik na serwerze. Podpis był jedyną kontrolą, która chroniła przed przejętym mirrorem, i to właśnie ona zawiodła.

Paradoks tej pary advisories: niższy wynik dostało CVE, w którym vendor założył kontrolę administratora, a wyższy to, w którym dane przychodzą automatycznie. Kolejność jest poprawna. Tyle że dla organizacji z własnym mirrorem aktualizacji to 113469, a nie 111090, może być ważniejsze, mimo że oba mają ten sam napis „medium”.

Jak VM ma czytać environmental score od vendora

Environmental score z definicji opisuje Twoje środowisko. Kiedy liczy go vendor, opisuje środowisko, które vendor uważa za typowe. To jest użyteczne, bo pokazuje model zagrożenia producenta, ale nie jest faktem o Twojej sieci. Zasady, które stosuję:

1. Zapisuj trzy liczby osobno: base z NVD (7.8 / 7.5), environmental vendora (6.0 / 6.7) i własną ocenę. Automat, który bierze tylko „severity: medium” ze strony vendora albo tylko „HIGH” z NVD, gubi informację.
2. Sprawdź każdą metrykę z przedrostkiem M. Pytanie nie brzmi „czy 6.0 to dużo”, tylko „czy u nas plik do firewalla trafia wyłącznie ręką admina, który zawsze sprawdza hash”. Jeśli odpowiedź brzmi „nie zawsze”, MPR:H nie jest Twoje.
3. Oddziel temporal od environmental. W 113469 cały spadek to E:P i RL:O. RL:O jest prawdziwe tylko tam, gdzie poprawka istnieje. Dla 4.3 nie istnieje.
4. Przelicz, jeśli założenia nie pasują, i zapisz uzasadnienie przy findingu. To samo podejście opisywałem przy FreeRDP, gdzie dwa źródła miały dwa modele zagrożenia dla tego samego błędu, i przy Craft CMS, gdzie vendor i CNA różnili się o kilka punktów.

Na plus dla Stormshield: vendor publikuje pełne wektory zamiast samego słowa „medium”. Dzięki temu da się sprawdzić jego rozumowanie. Większość vendorów podaje tylko severity i trzeba zgadywać.

Gałąź 4.3: podatna do 4.3.44, bez poprawki

Oba advisories wymieniają SNS 4.3.0–4.3.44 jako podatne i nie podają wersji naprawionej dla tej gałęzi. Kontekst z dokumentacji cyklu życia Stormshield (tabela „Firmware versions”):

• 4.3 LTSB: koniec utrzymania 31.12.2025, koniec życia 31.03.2026. Etykieta LTSB została zdjęta z 4.3 31 marca 2026.
• 4.3 QS (Qualification Standard): daty końca utrzymania i życia „ND”. Według release notes etykieta oznacza, że gałąź jest utrzymywana w zakresie technicznym kwalifikacji standardowej ANSSI. Najnowsza wersja to 4.3.44 QS z release notes z 16.07.2026, czyli ostatnia wersja z listy podatnych.
• Kwalifikacje: 4.3.x (x≥12) ma kwalifikację standardową ANSSI, jest w katalogach NATO Restricted i EU Restricted (zmiana w dokumentacji z 17.09.2026), a 4.3 ma też kwalifikację hiszpańskiego CCN. Wersja 4.3.12.2 ma certyfikat EAL4+.
• 4.8 LTSB: koniec utrzymania 31.12.2029, koniec życia 31.03.2030.

Wniosek: brak poprawki dotyczy dokładnie tej gałęzi, którą wybierają organizacje z wymogiem kwalifikacji, czyli administracja i sektor obronny. Dla nich „zaktualizuj do 4.8.20 LTSB” może oznaczać wyjście poza kwalifikowaną wersję. Czy Stormshield planuje 4.3.45 QS z poprawką, ani advisory, ani dokumentacja tego nie mówią: niepotwierdzone. Advisory nie mówi też wprost, że 4.3 poprawki nie dostanie. To ten sam wzorzec, który opisywałem przy OpenVPN 2.6: gałąź jest wspierana, ale aktualny CVE nie ma w niej fixu.

Dla VM finding na 4.3 to „no fix available”, a nie „patch overdue”. Potrzebna jest decyzja z właścicielem: albo migracja do 4.8.20 LTSB i świadoma rezygnacja z kwalifikowanej wersji, albo wyjątek z datą przeglądu i obejściami z advisory jako kontrolą kompensującą. W wyjątku trzeba zapisać dowód, a nie deklarację: procedurę sprawdzania SHA-256 plików firmware i licencji, listę serwerów Active Update z potwierdzeniem HTTPS i warunek zamknięcia „wydanie poprawki dla 4.3 QS”.

Mapowanie na wersje: dwie pułapki

• Advisory 032 nie zawiera numeru CVE. Na stronie advisories.stormshield.eu/2026-032/ pole „CVE Number” jest puste (stan na 20.10.2026). Powiązanie CVE-2026-113469 z tym advisory wynika z rekordu NVD, który wskazuje 2026-032 jako referencję. Narzędzie, które mapuje CVE po treści advisory vendora, może tego CVE nie znaleźć.
• Release notes wersji naprawionych nie wymieniają 2026-032. Sekcje „Resolved vulnerabilities” dla 5.0.10, 5.1.4 EA i 4.8.20 LTSB wskazują 2026-031 i kilka innych advisories z tej serii, ale nie 2026-032. Poprawkę dla CVE-2026-113469 w tych wersjach potwierdza tylko advisory 032 i rekord NVD. Release notes 5.1.4 EA i 4.8.20 LTSB mają datę 15.10.2026. Daty wydania 5.0.10 nie potwierdziłem.

Co powinien zrobić VE

(1) Zinwentaryzuj firewalle SNS z wersją i gałęzią (5.1 EA, 5.0, 4.8 LTSB, 4.3 QS). Rekordy NVD nie mają CPE, więc dopasowanie po CPE nic nie da. (2) Na 5.x i 4.8 zaplanuj aktualizację do 5.1.4 EA, 5.0.10 albo 4.8.20 LTSB. Plik aktualizacji pobierz z MyStormshield i przed wgraniem porównaj SHA-256 z wartością z portalu. Przy tym CVE weryfikacja podpisu w starej wersji nie jest zabezpieczeniem. (3) Sprawdź konfigurację Active Update: czy serwery to oficjalne serwery Stormshield albo mirror SMC, czy URL-e zaczynają się od https:// i mają wskazany CA, kto ma zapis na własnym mirrorze. Własny mirror po HTTP podnieś w priorytecie. (4) Na 4.3 QS otwórz wyjątek z właścicielem i datą przeglądu, opisany wyżej, i śledź advisories 031 i 032 pod kątem nowej rewizji. (5) W rejestrze zapisz base, environmental vendora i własną ocenę z uzasadnieniem, np. „mirror HTTP, MPR:N, 7.6”. (6) Przy podejrzeniu, że ktoś wgrał plik spoza MyStormshield przed poprawką, sama aktualizacja nie wystarczy. Trzeba ustalić, skąd pochodziły wgrane pliki. Jak zweryfikować integralność już zainstalowanego firmware, źródła nie podają.

Ta sama rodzina problemów co AOMEI i UNC7017 albo oc-mirror i podpis PGP: integralność kanału aktualizacji. Tym razem na urządzeniu, które samo jest kontrolą bezpieczeństwa.

Powiązane na blogu

• FreeRDP: CVE.org mówi „bez uprawnień”, Red Hat „low privileges” — dwa modele zagrożenia dla jednego błędu
• Craft CMS CVE-2026-112776 — „Moderate” u vendora, 9.3 od CNA. Czyje CVSS jest Twoje?
• OpenVPN 2.6 bez fixu — kiedy „supported” nie znaczy „currently fixed”
• OpenShift oc-mirror CVE-2026-75939 — podpis sprawdzany za wcześnie
• AOMEI i UNC7017 — złośliwy kanał aktualizacji przez kilka minut
• Apache Tika: Local 5.9 czy Network 8.7 — ten sam błąd, różne wektory ataku

Źródła

• Stormshield — STORM-2026-031, Improper Signature Verification of Firmware Update Files (CVE-2026-111090; wektory base, temporal, environmental, wersje, obejście) — advisories.stormshield.eu
• Stormshield — STORM-2026-032, Improper Signature Verification of Active Update Files (wektory, wersje, obejście; bez numeru CVE na stronie) — advisories.stormshield.eu
• NVD — CVE-2026-111090 — nvd.nist.gov
• NVD — CVE-2026-113469 — nvd.nist.gov
• Stormshield — Product life cycle, Firmware versions (4.3 LTSB, 4.3 QS, 4.8 LTSB, kwalifikacje ANSSI, NATO, EU) — documentation.stormshield.eu
• Stormshield — Product life cycle, Getting started (historia zmian: koniec etykiety LTSB dla 4.3, katalogi NATO i EU) — documentation.stormshield.eu
• Stormshield — SNS 4.3.44 QS release notes, Getting started (etykieta QS, data 16.07.2026) — documentation.stormshield.eu
• Stormshield — Resolved vulnerabilities in SNS 5.0.10 — documentation.stormshield.eu
• Stormshield — Resolved vulnerabilities in SNS 5.1.4 EA — documentation.stormshield.eu
• Stormshield — Resolved vulnerabilities in SNS 4.8.20 LTSB — documentation.stormshield.eu
• Stormshield — SNS v5 User Manual, Active Update — documentation.stormshield.eu
• Stormshield — CLI Serverd reference, CONFIG AUTOUPDATE SERVER — documentation.stormshield.eu
• Stormshield — SMC v3, Customizing Active Update settings (kategorie baz Active Update) — documentation.stormshield.eu
• FIRST — CVSS v3.1 Specification (wzory base, temporal, environmental) — first.org
• CISA Known Exploited Vulnerabilities Catalog (żadnego z dwóch CVE w wersji 2026.10.16) — cisa.gov

Nota redakcyjna: stan informacji 20 października 2026, na podstawie advisories advisories.stormshield.eu/2026-031/ i /2026-032/ (rewizja v1 z 16.10.2026: opisy, wektory CVSS 3.1 base, temporal i environmental, wersje podatne i naprawione, obejścia; na stronie 2026-032 pole CVE jest puste), rekordów NVD dla CVE-2026-111090 i CVE-2026-113469 (status „Received”, CNA Airbus, CWE-287, bez oceny NVD i bez CPE), dokumentacji Stormshield (cykl życia wersji, release notes 4.3.44 QS, sekcje „Resolved vulnerabilities” dla 5.0.10, 5.1.4 EA i 4.8.20 LTSB, podręcznik Active Update, referencja CLI CONFIG AUTOUPDATE SERVER, kategorie baz w SMC) oraz katalogu CISA KEV w wersji 2026.10.16, w którym żadnego z tych CVE nie ma. Warianty wyniku CVSS w tabeli policzył autor wzorami ze specyfikacji CVSS 3.1. Nie potwierdziłem: czy Stormshield planuje poprawkę dla 4.3 QS, daty wydania 5.0.10, których kategorii Active Update dotyczy CVE-2026-113469, co oznacza „automatic verification via SNS” w obejściu 031, czy przywracanie konfiguracji (wymienione w release notes) było podatne, kto zgłosił błędy, czy istnieje publiczny PoC ani czy ktokolwiek je wykorzystał. Datę „Date discovered” 08/03/2026 podaję w formacie strony vendora. Interpretacja MPR:H jako założenia „plik wgrywa administrator”, interpretacja AV:A/AC:H jako pozycji w drodze do serwera aktualizacji, wnioski o skutkach podmiany root CA i sygnatur IPS, ocena ekspozycji własnych mirrorów oraz lista „Co powinien zrobić VE” to oceny autora, nie ustalenia Stormshield.