CVE-2026-92591

Craft CMS od wersji 5.0.0-RC1 do przed 5.11.0 nieprawidłowo autoryzuje pola GraphQL draftCreator i revisionCreator. Zamiast wymagać zakresu user-data egzekwowanego przez Gql::canQueryUsers(), pola te są ograniczone tylko do zakresów elements.drafts:read / elements.revisions:read, a ich resolver zwraca surowy element User bez autoryzacji poszczególnych pól. Klient z tylko tymi zakresami może uzyskać adresy e-mail, nazwy użytkowników, pełne nazwiska i adresy pocztowe wszystkich twórców wersji roboczych i rewizji. Problem naprawiono w wersji 5.11.0.

Craft CMS w wersjach 5.10.0–5.10.12 zawiera niekompletną poprawkę CVE-2026-55794 — sink Controller::getPostedRedirectUrl() -> View::renderObjectTemplate() pozostał bez sandboxa, a ten sam commit dodał oracle do samodzielnego podpisywania w Cp::elementLabelHtml(). Ponieważ tokeny HMAC Craft/Yii nie są powiązane z nazwą parametru, uwierzytelniony użytkownik panelu o niskich uprawnieniach z prawem edycji jednego typu elementu może wygenerować token dla kontrolowanego przez atakującego szablonu Twig dla parametru returnUrl i odtworzyć go jako parametr POST przekierowania, osiągając niesandboxowany sink i wstrzyknięcie szablonu po stronie serwera, co prowadzi do wykonania dowolnego kodu PHP. Problem naprawiono w wersji 5.10.13.

Craft CMS w wersjach 4.8.0–4.18.5 oraz 5.0.0–5.10.12 podpisuje kontrolowany przez atakującego cookie license-shun uwierzytelnionego użytkownika tym samym kluczem i formatem, których używa do walidacji podpisanych parametrów przekierowania, ponieważ podpis HMAC nie jest powiązany z celem (cookieValidationKey Yii pochodzi z tego samego securityKey Craft używanego dla podpisanych parametrów żądania). Uwierzytelniony użytkownik niebędący administratorem może ustawić cookie przez endpoint license-shun i przenieść podpisaną kopertę do parametru przekierowania; po udanym logowaniu Craft waliduje podpis i renderuje uwierzytelnione bajty jako niesandboxowany szablon Twig, gdzie filtr map akceptuje callback tekstowy i pozwala PHP system() wykonać dowolne polecenia systemu operacyjnego jako użytkownik serwera WWW. Eksploatacja wymaga konta z uwierzytelnianiem hasłem bez aktywnego 2FA, domyślnej konfiguracji żądań i dostępności PHP system(). Problem naprawiono w wersjach 4.18.6 i 5.10.13.

Craft CMS w wersjach od 5.7.0 do 5.10.13 zawiera podatność typu stored XSS w funkcji Generated Fields, która wyłącza automatyczne escapowanie Twig i nie koduje wartości z pamięci podręcznej. Redaktorzy treści mogą wstrzykiwać złośliwy JavaScript przez edytowalne pola, który wykonuje się w sesjach uwierzytelnionych użytkowników Panelu sterowania o wyższych uprawnieniach. Naprawiono w wersji 5.10.13.

Craft CMS 5.0.0 do 5.10.12 zawiera wadę kontroli dostępu w punkcie końcowym zmiany kolejności zagnieżdżonych elementów. Uwierzytelniony użytkownik z uprawnieniami tylko do podglądu może zmienić kolejność bloków Matrix lub pól Address w treści innego autora, do której nie ma uprawnień zapisu.

Craft CMS w wersjach od 5.7.0 do przed 5.10.12 zawiera podatność na ujawnienie informacji w AssetsController::actionMoveInfo, która nie egzekwuje uprawnień do woluminów. Uwierzytelnieni użytkownicy panelu sterowania mogą wysyłać żądania POST do punktu końcowego assets/move-info z dowolnymi folderIds, aby uzyskać liczbę zasobów i całkowity rozmiar przechowywania dla woluminów, do których nie mają dostępu.

Craft CMS przed wersją 5.10.11 nie weryfikuje statusu administratora w punkcie końcowym actionGetPasswordResetUrl, co pozwala użytkownikom niebędącym administratorami z uprawnieniem administrateUsers na generowanie linków resetowania hasła dla kont administratorów. Atakujący może ustawić nowe hasło dla administratora i przejąć panel kontrolny.

Craft CMS w wersjach od 5.0.0-RC1 do 5.10.11 zawiera brak autoryzacji w AssetsController::actionReplaceFile. Gdy żądanie podaje sourceAssetId i targetFilename bez assetId, uprawnienie replacePeerFiles nie jest egzekwowane, co pozwala autoryzowanemu autorowi z uprawnieniem replaceFiles na nadpisanie plików innych użytkowników w tym samym folderze.

Craft CMS w wersjach od 5.0.0-RC1 do 5.10.11 nie wykonuje niezależnej kontroli autoryzacji w ElementsController::actionDeleteForSite. Metoda sprawdza uprawnienia tylko dla własnego szkicu użytkownika, a następnie usuwa kanoniczny element bez ponownej weryfikacji, co pozwala uwierzytelnionemu użytkownikowi bez uprawnienia deleteEntriesForSite na trwałe usunięcie wpisów.

Craft CMS przed wersją 5.10.11 zawiera podatność na obejście autoryzacji w ElementsController::actionDuplicate(), która pozwala uwierzytelnionym użytkownikom z uprawnieniem createEntries na usuwanie cudzych wstępnych wersji roboczych. Atakujący mogą wykorzystać parametr deleteProvisionalDraft, aby usunąć niezapisany szkic innego użytkownika bez odpowiednich kontroli autoryzacji, uzyskując dostęp do treści w trakcie tworzenia.