Strona główna / Blog / Ignition: pusty default permission

Blog · case study

Ignition: pole „Create Project Role(s)” było puste, więc kontrola dokładnie robiła… nic. Kiedy insecure default jest ważniejszy niż błąd w kodzie

CVE-2026-77393 dotyczy Inductive Automation Ignition 8.1.53 i wcześniejszych. Gateway ma ustawienie Create Project Role(s), które ma określać, jakie role mogą tworzyć projekty. Problem: było dostarczane jako puste. W tej semantyce pusta wartość oznaczała brak wymaganej roli, więc każdy authenticated user zdolny do wykonywania gateway scripts mógł tworzyć projekty. CVSS v4.0: 8.7 High.

CVE-2026-77393 (CVSS v4 8.7): puste Create Project Role(s) → brak wymaganej roli → tworzenie projektów przez każdego usera zdolnego do gateway scripts.
Natura: nie auth bypass — permission check egzekwował dokładnie pustą konfigurację (insecure default shipped by vendor).
Fix: 8.1.54 ogranicza project creation do Designer sessions i nie polega na tym ustawieniu; linia 8.3 not affected.

Insecure default, nie błąd w kodzie

To ważne rozróżnienie dla VM: mechanizm działał poprawnie — wykonywał regułę, którą mu podano. Regułą było „pusto”, co znaczyło „bez wymagań”. Klasa problemu to insecure default, a nie logiczny błąd kontroli. Takie przypadki bywają groźniejsze, bo skaner szukający „błędu w kodzie” może ich nie widzieć, a konfiguracja wygląda na „domyślną, więc bezpieczną”.

Konfiguracja może zamknąć ścieżkę bez upgrade

Dla organizacji, która nie może od razu aktualizować 8.1, samo wypełnienie Create Project Role(s) zgodnie z wymaganym Designer Role w pełni zamyka ścieżkę. To rodzi dobry spór terminologiczny:

product remediation: pending environment remediation: complete

Oba stany są prawdziwe jednocześnie — VM powinien umieć je rozróżnić, zamiast trzymać jedną flagę „affected/fixed”.

OT/ICS asset context

W środowiskach OT/ICS lokalny priorytet powinien dodatkowo uwzględniać: kto ma konta, kto może wykonywać gateway scripts i jaki wpływ projekty mają na proces przemysłowy. Ta sama podatność w izolowanym labie i na gatewayu sterującym linią produkcyjną to dwa różne ryzyka — mimo identycznego CVE i wersji.

Wniosek

CVE-2026-77393 pokazuje, że insecure default bywa ważniejszy niż błąd w kodzie: kontrola robiła dokładnie to, co jej podano — czyli nic. Dla VE to sygnał, by oceniać nie tylko „czy jest błąd”, ale „czy dostarczona domyślna konfiguracja realnie egzekwuje zamierzoną granicę”.

Powiązane na blogu

Źródła

Nota redakcyjna: stan informacji 7 września 2026. CVE-2026-77393 (Ignition ≤ 8.1.53, CVSS v4 8.7): puste domyślne Create Project Role(s) pozwalało tworzyć projekty bez wymaganej roli; 8.1.54 ogranicza do Designer sessions, 8.3 not affected, a wypełnienie roli zamyka ścieżkę bez upgrade. Artykuł koncentruje się na insecure default i różnicy product vs environment remediation.

Zapamiętaj jedno

To nie klasyczny auth bypass — permission check egzekwował dokładnie to, co mówiła konfiguracja, a mówiła „nic”. Problemem był insecure default dostarczony przez producenta. Dlatego warto rozdzielać „product remediation: pending” od „environment remediation: complete”.