CVE-2026-32258

Winter CMS do wersji 1.2.12 zawiera podatność, która pozwala uwierzytelnionym użytkownikom backendu na ujawnienie dowolnych plików czytelnych przez proces PHP poprzez wstrzyknięcie dyrektyw @import do kodu LESS. Podatność wynika z braku bezpiecznego resolwera importów w parserze LESS. Poprawka jest w wersji 1.2.13.

Winter CMS do wersji 1.2.12 zawiera podatność w widżecie FileUpload formularza backendu, który ufa kontrolowanemu przez atakującego parametrowi file_id podczas rozwiązywania załącznika. Pozwala to uwierzytelnionemu użytkownikowi backendu na odczyt i modyfikację załączników należących do innych użytkowników lub rekordów. Poprawka jest w wersji 1.2.13.

Winter CMS do wersji 1.2.12 włącznie nie egzekwował sprawdzeń uprawnień per typ szablonu w edytorze motywów, co pozwalało użytkownikowi backendu z jednym dowolnym uprawnieniem CMS na manipulowanie innymi typami szablonów. Ponadto widget AssetList umożliwiał nieautoryzowane przesyłanie plików do katalogu aktywnego motywu.

Winter CMS do wersji 1.2.12 włącznie zawiera podatność na wstrzykiwanie SQL w widgecie filtru backendu przez typ zakresu numberrange z kluczem conditions, co pozwala uwierzytelnionemu użytkownikowi backendu na wstrzyknięcie dowolnego SQL. Eksploatacja wymaga, aby wtyczka innej firmy zarejestrowała taki filtr.

Winter CMS to system zarządzania treścią zbudowany na frameworku Laravel PHP. W wersjach przed 1.2.13 backend nie walidował nazwy handlera przesłanej przez pole _handler w formularzu postback, co pozwalało uwierzytelnionemu użytkownikowi backendu na wywoływanie dowolnych metod kontrolera, w tym chronionych, prywatnych i z prefiksem akcji. Chociaż żądania AJAX walidują, że nazwy handlerów pasują do wzorca on[A-Z][\w+]* , ścieżka postback przekazywała przesłaną wartość _handler bezpośrednio do dyspozytora handlerów bez takiego sprawdzenia, więc każdy kontroler, który udostępnia publiczną akcję lub warunkowo zwalnia sprawdzenie $requiredPermissions, mógł być osiągnięty, omijając system ról i uprawnień. Wbudowany kontroler Users był dotknięty, ponieważ ustawiał $requiredPermissions na null dla akcji myaccount, pozwalając każdemu uwierzytelnionemu użytkownikowi backendu na wywoływanie metod zarządzania użytkownikami, takich jak update_onDelete i update_onManualPasswordReset, bez posiadania uprawnienia backend.manage_users. Ten problem został naprawiony w wersji 1.2.13.

Winter to darmowy system zarządzania treścią (CMS) oparty na frameworku Laravel PHP. Przed wersją 1.2.13, niestandardowe CSS dostarczane przez pole Brand Settings Styles przez użytkownika backendu z uprawnieniem backend.manage_branding jest kompilowane przez parser LESS i renderowane bez sanityzacji na każdej stronie backendu, co pozwala na przechowywany cross-site scripting przeciwko użytkownikom backendu. Ten problem został naprawiony w wersji 1.2.13.

Winter CMS w wersjach przed 1.2.13 zawiera niekompletną poprawkę dla podatności ucieczki z sandboxa Twig w System\Twig\SecurityPolicy, która pozwala uwierzytelnionym użytkownikom backendu z uprawnieniami do edycji szablonów na ominięcie ograniczeń sandboxa. Atakujący mogą wykorzystać przekazywanie metod przez modele Eloquent i konstruktory zapytań, używając metod takich jak saveQuietly(), deleteQuietly(), increment(), decrement() i newQuery(), aby odczytywać i modyfikować dowolne rekordy bazy danych, wykonywać dowolne SQL i osiągnąć zdalne wykonanie kodu poprzez wstrzyknięcie PHP do sekcji kodu szablonu.

Winter CMS przed wersją 1.2.13 zawiera podatność na lokalne dołączanie plików w filtrze JavascriptImporter, która pozwala uwierzytelnionym użytkownikom z uprawnieniem cms.manage_assets na ujawnienie dowolnych plików czytelnych dla serwera poprzez umieszczenie dyrektyw =include lub =require w motywowych zasobach JavaScript. Atakujący mogą odwoływać się do plików takich jak .env poza katalogiem motywu, a połączone dane wyjściowe serwowane przez trasę combine stają się czytelne dla nieuwierzytelnionych odwiedzających, ujawniając klucze aplikacji i poświadczenia bazy danych.

W systemie zarządzania treścią Winter, przed wersją 1.2.3, użytkownicy z uprawnieniami `backend.manage_branding` mogli przesyłać pliki SVG jako logo aplikacji bez ich sanitizacji, co mogło prowadzić do ataków XSS. Wersja 1.2.3 wprowadza poprawki, które zapewniają pełne wsparcie dla przesyłania SVG oraz automatyczną sanitizację tych plików.