CVE-2026-81927

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 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 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.