Craft CMS CVE-2026-78416: JSON warunku wyszukiwania prowadził do RCE
Uwierzytelniony użytkownik panelu mógł przemycić konfigurację behavior/event przez condition.config. Analiza Yii, wersji 4.18.2 i 5.10.6 oraz reakcji.
- AUTOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLIKACJA
- 24 sierpnia 2026
- CZAS CZYTANIA
- 18 min czytania
- TEMAT
- Podatności i CVE
CVE-2026-78416 zostało opublikowane 24 sierpnia i dotyczy obsługi warunków wyszukiwania elementów w panelu Craft CMS. Uwierzytelniony użytkownik mógł przesłać przygotowaną strukturę JSON w condition.config. Obejście oczyszczania pozwalało, by po dekodowaniu framework Yii potraktował specjalne klucze jako konfigurację behavior lub zdarzenia, co prowadziło do wykonania polecenia w kontekście procesu PHP/web.
Podatne są wersje od 4.0.0-RC1 do wydań wcześniejszych niż 4.18.2 oraz od 5.0.0-RC1 do wydań wcześniejszych niż 5.10.6. CVE otrzymało CVSS 4.0: 8,7 (High) z wektorem AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Wymaga konta i osiągalnej funkcji panelu, ale nie potrzebuje działania innego użytkownika.
Od danych JSON do konfiguracji wykonywalnego obiektu
JSON zwykle wygląda jak pasywny format danych. Bezpieczeństwo zależy jednak od miejsca, do którego trafia po dekodowaniu. Craft CMS korzysta z Yii, gdzie tablica konfiguracyjna może opisywać nie tylko zwykłe właściwości, ale też sposób utworzenia obiektu, dołączenia behaviorów i obsługi zdarzeń. W takim kontekście granica między „danymi” a „instrukcją konstrukcji” jest realną granicą wykonania.
Mechanizm luki obejmował oczyszczanie konfiguracji warunku. Jeżeli filtr usuwa niebezpieczne klucze tylko na jednym poziomie, przed finalnym dekodowaniem lub w innej reprezentacji niż ta używana przez fabrykę obiektów, specjalna struktura może przetrwać. Kiedy framework później interpretuje wynik jako konfigurację, napastnik nie musi wstrzykiwać surowego PHP. Wykorzystuje legalną semantykę kontenera i systemu zdarzeń do zbudowania niebezpiecznego grafu obiektów.
To różni się od prostego command injection, w którym fragment tekstu trafia do powłoki. Tutaj problemem jest nadmiernie ekspresyjna deserializacja konfiguracji. Walidacja wartości biznesowych — operatora, pola, zakresu dat — nie wystarczy, jeżeli obok nich przejdą meta-klucze rozumiane przez framework.
Warunki niezbędne do ataku
Rekord klasyfikuje wymagane uprawnienia jako niskie, ale nie oznacza anonimowego Internetu. Napastnik musi być uwierzytelniony w panelu i mieć dostęp do objętej ścieżki wyszukiwania elementów. W praktyce należy zinwentaryzować role, które mogą używać wyszukiwania, zapisanych warunków lub ekranów generujących condition.config, a nie patrzeć wyłącznie na konta pełnych administratorów.
Źródłem dostępu może być przejęte konto redaktora, wspólne konto agencji, stary użytkownik wykonawcy albo token sesji. MFA i ograniczenie panelu do VPN zmniejszają prawdopodobieństwo wejścia, ale nie eliminują błędu po uzyskaniu sesji. Wektor PR:L powinien skłonić do przeglądu najmniej uprzywilejowanych kont, które zachowują dostęp do control panelu.
Udane polecenie działa jako użytkownik procesu web/PHP, nie automatycznie jako root. Wpływ zależy więc od uprawnień systemowych, zawartości zmiennych środowiskowych, dostępu do bazy, możliwości zapisu w webroot i połączeń sieciowych. W typowym CMS ten kontekst wystarcza jednak do odczytu konfiguracji aplikacji, zmiany treści, kodu lub kont oraz dotarcia do usług wewnętrznych.
Poprawione wersje i opóźnione ujawnienie
Pierwsze poprawione wydania to Craft CMS 4.18.2 i 5.10.6. Oba zostały opublikowane 16 czerwca, a informacje o wydaniach wskazywały poprawki luk RCE o wysokiej wadze. Publiczny rekord z technicznym zakresem pojawił się później, zgodnie z polityką projektu, która przewiduje opóźnienie szczegółów po dostarczeniu poprawki.
Ten model ma dać operatorom czas na aktualizację przed pełnym opisem. Jednocześnie tworzy pułapkę dla zespołów, które ignorują wydania bezpieczeństwa do czasu nadania CVE. Jeżeli organizacja aktualizuje CMS wyłącznie na podstawie feedu NVD, przez tygodnie może pozostawać na wersji, którą producent już określił jako wymagającą poprawki.
Aktualizuj do najnowszego wspieranego patcha w linii 4.x lub 5.x, a nie tylko do minimalnego 4.18.2/5.10.6. Przed rolloutem sprawdź wymagania PHP, pluginów i migracji. Po zmianie potwierdź wersję z procesu obsługującego ruch, działanie panelu, wyszukiwania elementów, kolejek i zadań, a następnie usuń stare obrazy z aktywnych slotów wdrożeniowych.
Detekcja: od żądania do procesu potomnego
Najmocniejsza analiza łączy trzy warstwy. W logach HTTP i aplikacji szukaj nietypowych żądań do funkcji wyszukiwania panelu, błędów dekodowania warunku, wyjątków tworzenia obiektu oraz struktur znacznie bardziej złożonych niż normalny filtr. W audycie tożsamości sprawdź, kto logował się do panelu, z jakiego adresu, kiedy zmieniono rolę i czy sesja działała poza zwykłym harmonogramem.
Na hoście szukaj procesów potomnych PHP-FPM lub serwera web, uruchomień narzędzi systemowych, modyfikacji plików projektu, nowych plików w webroot i uploadach, zmian konfiguracji oraz nietypowego ruchu wychodzącego. Jedno polecenie może być krótkie i nie zostawić pliku, dlatego EDR i telemetria procesów są ważniejsze niż samo porównanie sum kontrolnych.
Nie publikuj ani nie uruchamiaj testowego payloadu na cudzej stronie. Do potwierdzenia wersji wystarcza inwentaryzacja pakietu i kontrolowany test regresji w odizolowanym środowisku należącym do organizacji. Produkcyjna próba RCE może zmienić dane, uruchomić hooki lub stworzyć artefakty, a tym samym sama stać się incydentem.
Reagowanie po podejrzeniu wykonania kodu
Odizoluj węzeł od ruchu, lecz zachowaj pamięć, logi, obraz dysku lub snapshot zależnie od możliwości. Ustal proces nadrzędny, czas i konto panelu powiązane z żądaniem. Sprawdź webroot, katalogi konfiguracyjne, pluginy, moduły, zadania kolejki, cron, klucze SSH i konta Craft. Przejrzyj historię zmian treści, szablonów oraz konfiguracji projektu.
Zmapuj sekrety dostępne procesowi web: poświadczenia bazy, storage’u, poczty, CDN, API oraz klucze środowiskowe. Rotuj je po odcięciu trwałości, zaczynając od tych dających dalszy dostęp. Jeśli potwierdzono wykonanie kodu, odbuduj instancję z czystego artefaktu i zweryfikowanej bazy; sama aktualizacja pakietu zamyka wektor, ale nie usuwa zmian wykonanych wcześniej.
W środowisku wielowęzłowym sprawdź współdzielone storage, cache, kolejki i wszystkie repliki. Napastnik mógł użyć jednego procesu do zmiany zasobu ładowanego przez pozostałe. Wdrożenie nowego kontenera nie pomaga, jeśli złośliwa modyfikacja pozostaje w wolumenie, bazie albo szablonie przechowywanym poza obrazem.
Bezpieczny projekt konfiguracji warunków
Najsilniejszą kontrolą jest pozytywny schemat. Parser powinien akceptować wyłącznie zdefiniowane typy warunków, pola i operatory, odrzucać nieznane klucze na każdym poziomie oraz budować obiekty przez jawne mapowanie. Dane klienta nie powinny trafiać bezpośrednio do ogólnej fabryki frameworka.
Oczyszczanie musi działać po finalnym dekodowaniu i rekurencyjnie, ale sama denylista meta-kluczy jest krucha. Framework może dodać nową składnię, alias albo inny punkt konstrukcji. Allowlista kontraktu biznesowego pozostaje stabilniejsza: filtr ceny może zawierać pole, operator i liczbę, lecz nie nazwę klasy, behavior, handler zdarzenia ani callable.
Dodaj testy dla zagnieżdżonych obiektów, tablic, powtarzanego kodowania, nieznanych pól i różnych typów JSON. Test powinien też potwierdzić, że błędna konfiguracja jest odrzucona przed utworzeniem obiektu i nie uruchamia setterów, zdarzeń ani autoloadingu. Monitoring może mierzyć złożoność i rozmiar condition JSON, ale limit nie zastępuje semantycznego schematu.
Fakty źródłowe i wnioski Breachroad
Zakres wersji, uwierzytelniona ścieżka, obejście oczyszczania condition.config, interpretacja konfiguracji behavior/event oraz wynik CVSS pochodzą z rekordu CVE i ujawnienia badacza. Daty poprawek i wersje 4.18.2/5.10.6 pochodzą z oficjalnych wydań Craft CMS. Źródła użyte w artykule nie stwierdzają aktywnej eksploatacji.
Model detekcji, zakres analizy sekretów, rekomendacja allowlisty i testy grafu obiektów są wnioskami Breachroad. Szkolenia AppSec i secure coding pomagają odróżniać dane od wykonywalnej konfiguracji, a testy penetracyjne aplikacji mogą ocenić kontrolę panelu, deserializację i izolację procesu.
