Podatności Concrete CMS

Concrete CMS poniżej 9.5.4 nie walidowało wartości strefy czasowej użytkownika (uTimezone) przy zapisie i renderowało ją bez kodowania wyjściowego na stronie zarządzania użytkownikami w Dashboard. Złośliwy ładunek XSS zapisany w tym polu wykonywał się w przeglądarce administratora, gdy ten wyświetlił danego użytkownika.

Concrete CMS poniżej wersji 9.5.3 nie sanityzował niestandardowych wartości stylów w oknie Block Design przed zapisaniem ich do CSS strony przez sink DOM, co umożliwia trwałe (stored) cross-site scripting. Użytkownik na poziomie edytora mógł wykonać skrypt w sesji administratora i eskalować uprawnienia.

Concrete CMS przed wersją 9.5.4 autoryzowało żądania OAuth REST API wyłącznie na podstawie tokenu bearer, bez ponownego sprawdzania stanu konta, dla którego token został wydany. Dezaktywacja, usunięcie lub zablokowanie użytkownika nie unieważniało jego istniejących tokenów, więc taki użytkownik zachowywał pełny dostęp do /ccm/api/1.0/* do czasu wygaśnięcia tokenu.

Concrete CMS przed wersją 9.5.3 ujawniał starszy punkt końcowy wyszukiwania wpisów Express, który zwracał wyniki w formacie JSON bez wywoływania sprawdzenia uprawnień canViewExpressEntries() stosowanego w normalnym przepływie pulpitu i eksportu CSV. Nieuwierzytelniony odwiedzający, który znał lub odkrył identyfikator encji Express, mógł wyliczyć wyniki wyszukiwania wpisów tej encji, ujawniając wartości atrybutów przeznaczone tylko dla uprzywilejowanych użytkowników.

W Concrete CMS w wersjach od 9.2.0 do 9.5.3 endpoint REST API do tworzenia użytkowników (POST /ccm/api/1.0/users, metoda add() w concrete/src/Api/Controller/Users.php) nie przeprowadzał sprawdzenia uprawnień przed utworzeniem konta. W rezultacie dowolny ważny token OAuth z zakresem users:add, w tym token client_credentials bez kontekstu użytkownika, mógł tworzyć aktywne, zweryfikowane konta użytkowników z pominięciem weryfikacji e-mail i zatwierdzenia administratora. Przy domyślnych ustawieniach rejestracji utworzone konta mogły edytować treść stron, co dawało ścieżkę do trwałego cross-site scripting.

Concrete CMS w wersjach od 9 do 9.5.3 nie weryfikował, czy element InstanceItem przesłany do endpointu podglądu custom-slot należy do instancji tablicy, do edycji której użytkownik był upoważniony, ani nie egzekwował uprawnienia do przeglądania strony przed wygenerowaniem treści podsumowania opartej na stronie. W rezultacie uwierzytelniony użytkownik posiadający uprawnienie edit-board-contents w jednej instancji tablicy mógł przesłać identyfikator elementu należącego do innej instancji i otrzymać pola podsumowania, w tym tytuł i opis strony, do której normalnie nie miał dostępu. Zespół bezpieczeństwa Concrete CMS nadał tej podatności ocenę CVSS v4.0 wynoszącą 5.3.

Concrete CMS przed wersją 9.5.4 nie sanityzowało dokumentów XML i XSLT przesyłanych przez publiczne pytanie o upload pliku w Form Block. Nieuwierzytelniony odwiedzający mógł zapisać dokument XML z instrukcją xml-stylesheet wskazującą na złośliwy arkusz XSLT, co prowadziło do przechowywanego XSS w domenie Concrete CMS.

Concrete CMS przed wersją 9.5.3 zawiera podatność typu stored XSS w obsłudze plików SVG. W trybie odrzucania plików z potencjalnie szkodliwymi elementami (nie domyślnym) przesłane pliki SVG były sprawdzane tylko względem małej wbudowanej listy blokad, a wynik szerszej sanityzacji był odrzucany, co pozwalało na zapisanie i wykonanie złośliwego kodu JavaScript.

Concrete CMS w wersjach 9.4.0 do 9.5.2 nie escapowało kolidujących ścieżek stron przed wyświetleniem ich w oknie potwierdzenia duplikatu ścieżki w panelu lokalizacji. Punkt końcowy zwracał przesłaną ścieżkę bez modyfikacji, a JavaScript po stronie klienta wstawiał ją jako surowy HTML, co pozwalało na wykonanie skryptu w sesji edytora.

Concrete CMS w wersjach 9.0.0 do 9.5.2 nie egzekwowało kontroli uprawnień edycji na poziomie bloku dla akcji zarządzania kontrolkami bloku Express Form, opierając się wyłącznie na walidacji tokenu CSRF. Token powiązany z użytkownikiem i akcją, a nie z konkretnym blokiem, stroną czy formularzem, pozwalał uwierzytelnionemu użytkownikowi na modyfikację kontrolek w formularzach, do których nie miał uprawnień, w tym na wstrzyknięcie kontrolki renderowanej później jako HTML (stored XSS).

Concrete CMS przed wersją 9.5.3 nieprawidłowo neutralizował dostarczony przez użytkownika niestandardowy format daty podczas renderowania wiadomości konwersacji, co prowadziło do odbitego cross-site scripting (XSS). Atakujący mógł wykonać dowolny JavaScript w przeglądarce użytkownika, który został nakłoniony do wysłania spreparowanego żądania POST do punktu końcowego widoku konwersacji. Brak tokena CSRF ułatwiał dostarczenie ładunku przez automatycznie wysyłane żądanie POST z innej domeny bez uwierzytelnienia.

Concrete CMS 9 przed wersją 9.5.3 autoryzował akcję zmiany kolejności w mapie witryny (SitemapUpdate) tylko na podstawie globalnego uprawnienia access_sitemap, bez sprawdzania uprawnień do edycji poszczególnych stron. Uwierzytelniony użytkownik z dostępem do mapy witryny mógł zmieniać kolejność wyświetlania stron, do których nie miał praw edycji, wpływając na nawigację, breadcrumbs i listy stron. Dodatkowo brak tokena CSRF umożliwiał wywołanie tej akcji przez spreparowane żądanie.

Concrete CMS 9.0.0 do 9.5.2 jest podatny na Server-Side Request Forgery (SSRF) podczas zdalnego importu plików z powodu ponownego użycia zweryfikowanego pinu DNS dla tego samego hosta. Uwierzytelniony użytkownik z niskimi uprawnieniami, mający możliwość importowania plików, mógł dostarczyć host DNS-rebinding, który podczas walidacji wskazywał publiczny adres, a podczas pobierania adres prywatny lub loopback, co pozwalało na pobranie wewnętrznych zasobów, takich jak usługi loopback, wewnętrzne panele administracyjne czy endpointy metadanych chmury, i zapisanie ich w menedżerze plików.

Concrete CMS 9.0.0 do 9.5.2 jest podatny na Insecure Direct Object Reference (IDOR) w oknach dialogowych usuwania i edycji zapisanych presetów wyszukiwania Express. Uwierzytelniony użytkownik z uprawnieniami tylko do podglądu pojedynczej encji Express mógł trwale usunąć lub zmienić nazwę presetów należących do encji, do których nie miał uprawnień, a zmieniona nazwa była wyświetlana innym użytkownikom, co umożliwiało defacement lub social engineering.

Concrete CMS przed wersją 9.5.3 nie egzekwował autoryzacji po stronie docelowej i nie walidował tokena CSRF w akcji przypisywania stron wielojęzycznych (Backend\Page\Multilingual::assign). Uwierzytelniony użytkownik z uprawnieniem Edit Page Multilingual Settings na jednej stronie mógł przypisać dowolną stronę w innym języku jako tłumaczenie strony źródłowej oraz usuwać prawidłowe pary tłumaczeń, zmieniając publiczne routowanie językowe w całej witrynie.

Concrete CMS przed wersją 9.5.3 jest podatny na Cross-Site Request Forgery (CSRF) w funkcji aktywacji szablonów stron motywu. Akcja activate_files() w kontrolerze Dashboard theme Inspect tworzyła rekordy PageTemplate z wartości pageTemplates[] dostarczonych przez atakującego bez walidacji tokena anty-CSRF. Zdalny atakujący mógł umieścić stronę, która automatycznie wysyłała sfałszowane żądanie POST; gdy zalogowany administrator ją odwiedził, żądanie wykonywało się w sesji administratora, zmieniając konfigurację witryny bez jego zgody.

W Concrete CMS przed wersją 9.5.3 edytor masowej aktualizacji meta tagów SEO nie sprawdzał uprawnień do edycji poszczególnych stron przed zapisem. Akcja saveRecord() walidowała token CSRF per-strona, ale nie wywoływała canEditPageProperties() dla docelowej strony, więc użytkownik z dostępem do narzędzia SEO i możliwością podglądu (ale nie edycji) strony mógł zmienić jej meta tytuł, meta opis i URL handle, naruszając prezentację i żywe adresy URL chronionych treści.

Concrete CMS przed wersją 9.5.3 nie egzekwował autoryzacji per-strona podczas zmiany kolejności stron z mapy witryny. W kontrolerze sitemap Explore, zadania send_to_top i send_to_bottom wykonywane były po tylko ogólnym sprawdzeniu dostępu do mapy; kontroler ładował stronę wskazaną przez parametr cNodeID i zmieniał jej kolejność bez weryfikacji uprawnień do przenoszenia lub układania na tej konkretnej stronie. Uwierzytelniony użytkownik z dostępem do mapy, ale bez uprawnień do edycji lub układania, mógł przenieść stronę i zmienić globalną kolejność nawigacji.

Concrete CMS 8.5.3 do 9.5.2 umożliwiał grant odświeżania tokena OAuth 2.0 przy użyciu niezmodyfikowanego grantu League, który wydawał nowe tokeny dostępu z ważnego tokena odświeżania bez ponownego sprawdzania statusu aktywnego konta. Użytkownik, który uzyskał token odświeżania, gdy był aktywny, mógł kontynuować generowanie ważnych tokenów dostępu po dezaktywacji lub zawieszeniu (uIsActive=0), więc dezaktywacja konta nie odwoływała jego dostępu API.

Concrete CMS w wersjach poniżej 9.5.3 zawiera podatność Cross-Site Request Forgery w akcji reset() na stronie SEO Excluded Words w panelu administracyjnym. Akcja czyściła listę zastrzeżonych słów skonfigurowaną przez administratora, nie weryfikując tokenu anty-CSRF ani nie ograniczając żądania do metody POST. Atakujący mógł nakłonić uwierzytelnionego użytkownika z dostępem do SEO do odwiedzenia spreparowanej strony, co przywracało domyślną listę słów i po cichu zmieniało przyszłe generowanie slugów URL.

Concrete CMS w wersjach poniżej 9.5.3 nie weryfikuje tokenu anty-CSRF na endpointcie backendowym służącym do aranżacji bloków (akcja arrange() w Concrete\Controller\Backend\Page\ArrangeBlocks). Akcja wymuszała uprawnienia do edycji strony, ale nie sprawdzała tokenu, a jej trasa akceptowała dowolną metodę HTTP. Atakujący mógł nakłonić zalogowanego edytora treści do załadowania spreparowanej strony, która automatycznie wysyłała żądanie cross-site i zmieniała kolejność lub przenosiła bloki w wersji roboczej strony.

Concrete CMS w wersjach przed 9.5.3 renderuje etykiety wpisów Express jako surowy HTML podczas wyświetlania powiązanych wpisów, co prowadzi do przechowywanego cross-site scripting. Nieuwierzytelniony atakujący może przesłać payload przez publiczny formularz Express, który następnie wykonuje się w sesji panelu administratora lub w przeglądarce odwiedzającego stronę z blokiem Express Entry List.

Concrete CMS w wersjach poniżej 9.5.3 importuje pliki do menedżera plików przed sprawdzeniem uprawnienia "Add Message Attachments" na endpointcie przesyłania załączników konwersacji. Uprawnienie było weryfikowane dopiero po zapisaniu pliku. Użytkownik pozbawiony tego uprawnienia lub nieuwierzytelniony gość w konfiguracji gościnnego publikowania mógł zaimportować zatwierdzone pliki dozwolonych typów do menedżera plików.

Concrete CMS w wersjach od 9.0.0 do 9.5.2 nie weryfikuje tokenu CSRF w akcji delete kontrolera typu grupy w panelu administracyjnym, co prowadzi do cross-site request forgery. Zdalny nieuwierzytelniony atakujący może spowodować, że uwierzytelniony użytkownik z uprawnieniem do zarządzania typami grup usunie niestandardowy typ grupy.

Concrete CMS w wersjach od 9 do 9.5.2 nie escapuje znaków wieloznacznych SQL LIKE w filtrach wyszukiwania słów kluczowych używanych przez menedżer plików, foldery plików i listę stron. Uwierzytelniony użytkownik z uprawnieniami edytora lub wyższymi może przesłać spreparowane wyszukiwanie zawierające wiele znaków wieloznacznych, co zmusza bazę danych do pełnego skanowania tabeli i może obniżyć wydajność systemu.

Concrete CMS w wersjach od 9 do 9.5.2 nie wykonuje sprawdzenia autoryzacji w kilku akcjach dotyczących instancji tablic w obszarze Boards panelu administracyjnego. Kontroler szczegółów instancji rozwiązuje instancję tablicy bezpośrednio z identyfikatora dostarczonego przez atakującego i wykonuje operacje wyświetlenia, odświeżenia, regeneracji lub usunięcia bez weryfikacji uprawnienia edit_board_settings na tablicy nadrzędnej. Użytkownik z uprawnieniami do edycji jednej tablicy może uzyskać dostęp do instancji dowolnej innej tablicy.

Concrete CMS w wersjach od 9.0.0 do 9.5.2 nie posiada sprawdzenia autoryzacji w akcji zaawansowanego wyszukiwania wpisów Express w panelu administracyjnym. Metoda advanced_search() rozwiązuje encję Express bezpośrednio z identyfikatora dostarczonego przez użytkownika i renderuje jej wpisy bez wywołania canViewExpressEntries(), co pozwala uwierzytelnionemu użytkownikowi z uprawnieniem view_express_entries na jednej encji odczytać wpisy dowolnej innej encji, w tym wartości poufnych atrybutów.

Concrete CMS w wersjach od 9 do 9.5.2 nie wykonuje sprawdzenia autoryzacji w trzech akcjach kontrolera źródła danych Boards (update, update_data_source, delete_data_source), które rozwiązują ConfiguredDataSource bezpośrednio z identyfikatora dostarczonego przez atakującego bez potwierdzenia uprawnień edycji na tablicy nadrzędnej. Użytkownik z uprawnieniami edit_board_settings na jednej tablicy może modyfikować lub trwale usuwać źródła danych dowolnej innej tablicy.

Concrete CMS w wersjach od 9.0.0 do 9.5.2 przechowywał nazwy folderów grup bez sanityzacji i wyświetlał je bez escapowania na stronie Members > Groups dashboard, co prowadzi do przechowywanego XSS. Uwierzytelniony użytkownik posiadający uprawnienie Add Group Folder mógł zapisać ładunek skryptu jako nazwę folderu, który wykonywał się w sesji administratora przeglądającego dashboard grup, umożliwiając kradzież sesji i tokenów oraz dowolne działania w kontekście administratora.

W Concrete CMS w wersjach poniżej 9.5.3 formater tekstu atrybutu Address bez kraju pomijał escapowanie HTML, umożliwiając przechowywany XSS w widokach powiązań Express. Użytkownik mogący przesłać atrybut Address mógł wykonać skrypt w sesji dowolnego użytkownika dashboardu, który otworzył dotknięty wpis.

Concrete CMS w wersjach od 9.2.0 do 9.5.2 nie egzekwował uprawnień edit_user_properties na endpointach REST API zapisu użytkowników (PUT /ccm/api/1.0/users/{uID} oraz POST /ccm/api/1.0/users/{uID}/change_password). Użytkownik z tokenem OAuth o zakresie aktualizacji i uprawnieniem do edycji tylko jednego pola mógł zmienić hasło, nazwę użytkownika, e-mail i atrybuty innego użytkownika, przejmując jego konto.

W Concrete CMS w wersjach od 9.0 do 9.5.2 blok Top Navigation Bar nie escapował nazw stron podrzędnych w rozwijanym menu przed zapisaniem ich na stronie. Użytkownik mogący tworzyć lub zmieniać nazwy stron mógł zapisać skrypt poprzez nazwę strony podrzędnej, który następnie wykonywał się w przeglądarce każdego odwiedzającego, edytora lub administratora.

W Concrete CMS w wersjach przed 9.5.3 akcja save_control w kontrolerze formularzy encji Express nie weryfikowała tokenu anty-CSRF. Atakujący bez poświadczeń mógł nakłonić uwierzytelnionego administratora do wysłania sfałszowanego żądania i zapisać kontrolowane przez siebie wartości w kontrolce Text formularza Express. Wartości były emitowane bez kodowania wyjściowego, co prowadziło do trwałego XSS.

Concrete CMS w wersjach przed 9.5.3 nie stosuje kodowania encji HTML do etykiet pytań bloku Formularz zdefiniowanych przez użytkownika podczas renderowania ich jako nagłówki kolumn w raporcie zgłoszeń formularzy w panelu administracyjnym. Złośliwy edytor może zapisać znaczniki lub skrypt w etykiecie, który następnie wykonuje się w przeglądarce administratora otwierającego raport, powodując trwały XSS.

W Concrete CMS przed 9.5.3 blok Document Library przechowywał identyfikatory zestawów plików przesłane przez fsID[] bez walidacji jako liczby całkowite. Gdy blok był skonfigurowany z setMode ustawionym na any, każdy identyfikator był konkatenowany bezpośrednio do zapytania filtra zestawów plików. Uwierzytelniony użytkownik mógł zapisać składnię SQL w konfiguracji bloku, co prowadziło do trwałego, czasowego ślepego wstrzyknięcia SQL.

Concrete CMS 9.5.2 i wcześniejsze są podatne na trwały DOM-based XSS poprzez pole Caption dla poszczególnych obrazów w bloku Gallery. Dołączony skrypt Magnific Popup ponownie parsuje zdekodowany atrybut caption jako HTML przez jQuery .append() w titleSrc zamiast wstawiać go jako tekst. Użytkownik z uprawnieniami do edycji strony może zapisać caption, który wykona się w przeglądarce każdego odwiedzającego otwierającego lightbox.

Concrete CMS 9 przed wersją 9.5.3 oraz Concrete 8.5.21 zawiera podatność na przechowywany XSS w blokach Feature, Feature Link, Hero Image i Image. Zewnętrzny adres URL linku był niewystarczająco walidowany i renderowany bez escapowania, co pozwalało użytkownikowi z uprawnieniami edycji strony na wstrzyknięcie dowolnego JavaScriptu.

Concrete CMS 9 (od 9.0.0 do 9.5.2) nie przeprowadza kontroli autoryzacji na endpointcie autouzupełniania wyboru użytkownika (/ccm/system/user/autocomplete). Endpoint waliduje tylko token w stylu CSRF, który nie jest powiązany z tożsamością ani uprawnieniami wywołującego, a token jest wydawany anonimowym odwiedzającym.

Concrete CMS przed wersją 9.5.3 stosował tylko funkcję trim() do przechowywanych wartości szerokości i wysokości bloku YouTube, a następnie umieszczał je w atrybutach HTML iframe bez escapowania i rzutowania na liczbę całkowitą, co prowadziło do trwałego XSS. Użytkownik z uprawnieniem edit_block mógł wstrzyknąć procedurę obsługi zdarzeń, która wykonywała skrypt dla odwiedzających stronę, działając z uprawnieniami administratora, jeśli ofiarą był administrator.

Concrete CMS w wersjach od 8.3.0 do 9.5.2 przechowywał nazwy wydarzeń kalendarza bez sanityzacji i renderował je bez escapowania HTML w powiadomieniach o zatwierdzeniu i usunięciu w przepływie pracy, wyświetlanych w bloku "Waiting For Me" w panelu administracyjnym. Zarejestrowany użytkownik z uprawnieniem dodawania wydarzeń do kalendarza objętego przepływem zatwierdzania mógł przesłać wydarzenie, którego nazwa zawierała ładunek skryptu, który następnie wykonywał się w przeglądarce administratora podczas wyświetlania oczekującego żądania i mógł zostać użyty do utworzenia nowego konta administratora.

Concrete CMS w wersjach od 9.0.0 do 9.5.3 jest podatny na trwały XSS przez niestandardową nazwę aliasu strony (customAliasName), ponieważ okno dialogowe Edytuj alias stosowało tylko funkcję trim() do przesłanej wartości i nie przeprowadzało neutralizacji danych wejściowych. Uwierzytelniony użytkownik z uprawnieniem canWrite (edytor) na stronie mógł zapisać złośliwą nazwę aliasu, która później była renderowana bez escapowania w panelu administracyjnym Sitemap, gdzie wykonywała się automatycznie w każdej sesji administratora lub edytora, która otworzyła panel, umożliwiając edytorowi eskalację do administratora przez aktywną sesję ofiary.

Concrete CMS w wersjach 9.0.0 do 9.5.2 przechowywał wartość ikony kontenera strony wprowadzoną przez panel administracyjny bez walidacji względem znanych ikon. Niewalidowana wartość była później łączona w atrybut src tagu img przez pomocnika, który nie kodował danych wyjściowych, i była renderowana w surowej formie w listach i widokach edytora kontenerów. Użytkownik z delegowanym dostępem do panelu kontenerów stron mógł zapisać spreparowaną wartość ikony, która wychodziła poza atrybut src i wykonywała skrypt w sesji innego edytora lub administratora, który przeglądał listę, umożliwiając kradzież tokena sesji i uprzywilejowane działania w panelu. Zespół bezpieczeństwa Concrete CMS przyznał tej podatności wynik CVSS v4.0 7.0 z wektorem CVSS:4.0/AV:A/AC:L/AT:N/PR:H/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Dziękujemy Andrew Gonzalezowi za zgłoszenie.

Concrete CMS w wersjach 9 do 9.5.2 nie walidował tokena CSRF w akcji panelu usuwania osieroconych bloków (removeOrphanedBlocks). Zdalny atakujący mógł przygotować żądanie, które po załadowaniu przez uwierzytelnionego użytkownika z uprawnieniami do edycji na docelowej stronie usuwało wszystkie bloki na bieżącej wersji tej strony; bloki nie będące aliasami do innej strony lub wpisu scrapbooka były również usuwane z globalnej tabeli bloków i ich tabeli danych typu bloku, trwale niszcząc zawartość. Zespół bezpieczeństwa Concrete CMS przyznał tej podatności wynik CVSS v4.0 7.1 z wektorem CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N. Dziękujemy Yonatanowi Drori z Tenzai za zgłoszenie.

W Concrete CMS 9.2.0 do 9.5.2, punkt końcowy API do aktualizacji stron (PUT /ccm/api/1.0/pages/{cID}) nie egzekwował autoryzacji właściwości strony, szablonu strony ani typu strony. Użytkownik z uprawnieniami tylko do edycji treści na stronie mógł zmienić jej właściwości, szablon i typ przez API, a także ustawić atrybut header_extra_content, który jest renderowany bez escapowania w elemencie head każdej strony, aby utrwalić JavaScript wykonujący się w przeglądarce każdego odwiedzającego, w tym recenzentów z wyższymi uprawnieniami, którzy zatwierdzają wersję strony. Zespół bezpieczeństwa Concrete CMS przyznał tej podatności wynik CVSS v4.0 7.2 z wektorem CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. Dziękujemy Yonatanowi Drori z Tenzai za zgłoszenie.

Concrete CMS w wersjach poniżej 9.5.3 jest podatny na trwały XSS poprzez pole Date Format w bloku Page Attribute Display. Użytkownik z uprawnieniem edit_page_contents może zapisać złośliwy kod, który wykona się w przeglądarce każdego odwiedzającego stronę, na której blok wyświetla atrybut typu data.

Concrete CMS w wersjach poniżej 9.5.3 nie stosuje escapowania HTML dla pól opisu pliku i tagów podczas renderowania bloku Document Library. Użytkownik mogący edytować właściwości plików może zapisać złośliwy skrypt, który wykona się w przeglądarce każdego odwiedzającego stronę z włączoną kolumną opisu lub tagów, w tym niezalogowanych.

Concrete CMS w wersjach 9.5.2 i poniżej jest podatny na CSRF w funkcji Express "Clear Entries" (POST /index.php/dashboard/system/express/entities/delete_entries), ponieważ kontroler rejestruje, ale nie egzekwuje nieudanej weryfikacji tokenu CSRF. Zdalny niezalogowany atakujący może zmusić zalogowanego administratora odwiedzającego stronę kontrolowaną przez atakującego do trwałego usunięcia wszystkich wpisów wybranej encji Express.

API bloków Concrete CMS w wersjach 9.2.0 do 9.5.2 nie wywoływało metody validate() kontrolera typu bloku dla przesłanych danych, co dla bloków odwołujących się do plików (np. hero_image, gallery) pozwalało na zapisanie i wyświetlenie odwołania do pliku, który normalnie zostałby odrzucony przez politykę autoryzacji menedżera plików. Ujawnia to URL i podgląd pliku edytorowi oraz odwiedzającym stronę.

Concrete CMS przed wersją 9.5.3 sprawdzał autoryzację dla zgłoszenia wpisu Express względem encji opublikowanego formularza, a nie encji zidentyfikowanej przez trasę dashboardu. Użytkownik uprawniony do dodawania wpisów w jednym obiekcie Express mógł tworzyć wpisy w innym obiekcie Express poza swoim zakresem uprawnień.

Concrete CMS poniżej wersji 9.5.3 nie wykonuje sprawdzenia autoryzacji na poziomie obiektu podczas aktualizacji typu strony. Kontroler Types::submit() ładował i zapisywał typ strony zidentyfikowany przez ptID dostarczony przez użytkownika bez wywołania canEditPageType(), umożliwiając zalogowanemu użytkownikowi dashboardu modyfikację konfiguracji typów stron poza jego granicami uprawnień.