CVE-2026-19621

W wersjach Mattermost 11.0.x <= 11.0.2, 10.12.x <= 10.12.1, 10.11.x <= 10.11.4 oraz 10.5.x <= 10.5.12 nie jest weryfikowane, czy token użyty podczas wymiany kodu pochodzi z tego samego przepływu uwierzytelniania. Umożliwia to uwierzytelnionemu użytkownikowi przejęcie konta poprzez specjalnie spreparowany adres e-mail przy zmianie metody uwierzytelniania i wysłaniu żądania do endpointu /users/login/sso/code-exchange. Wymagane jest włączenie ExperimentalEnableAuthenticationTransfer (domyślnie włączone) i wyłączenie RequireEmailVerification (domyślnie wyłączone).

W wersjach Mattermost 10.12.x <= 10.12.1, 10.11.x <= 10.11.4, 10.5.x <= 10.5.12 oraz 11.0.x <= 11.0.3 nie jest prawidłowo walidowany token stanu OAuth podczas uwierzytelniania OpenID Connect. Umożliwia to uwierzytelnionemu atakującemu z uprawnieniami do tworzenia zespołów przejęcie konta użytkownika poprzez manipulację danymi uwierzytelniania w przepływie OAuth. Wymagane jest wyłączenie weryfikacji e-mail (domyślnie wyłączone), włączenie OAuth/OpenID Connect oraz kontrola dwóch użytkowników w systemie SSO, z których jeden nigdy nie logował się do Mattermost.

Mattermost w wersjach 11.9.x <= 11.9.1, 11.8.x <= 11.8.5, 11.7.x <= 11.7.10, 11.10.x <= 11.10.1 nie sanityzuje tokenów uwierzytelniających przed zapisaniem ich do logów serwera. Atakujący z dostępem do logów serwera może uzyskać ważne tokeny sesji lub tokeny dostępu OAuth i podszyć się pod uwierzytelnionych użytkowników.

Mattermost w wersjach 11.10.x <= 11.10.0, 11.7.x <= 11.7.9, 11.9.x <= 11.9.1, 11.8.x <= 11.8.5 nie odrzuca sesji aplikacji OAuth w punkcie końcowym zmiany typu konta. Atakujący z ważnym tokenem OAuth dla docelowego użytkownika może trwale przejąć konto tego użytkownika oparte na SSO, ustawiając hasło kontrolowane przez atakującego i odłączając konto od dostawcy tożsamości.

Mattermost w wersjach 11.10.x <= 11.10.0, 11.7.x <= 11.7.9, 11.9.x <= 11.9.1, 11.8.x <= 11.8.5 nie ogranicza wiązania kont przy imporcie z Slacka do importów inicjowanych przez administratora systemu. Uwierzytelniony atakujący z uprawnieniami administratora zespołu może wymusić dodanie istniejących użytkowników Mattermost do swojego zespołu i sfałszować posty przypisane do ich tożsamości.

Mattermost w wersjach 11.10.x <= 11.10.0, 11.7.x <= 11.7.9, 11.9.x <= 11.9.1, 11.8.x <= 11.8.5 nie weryfikuje uprawnień użytkownika przed innymi walidacjami, co pozwala osobom niebędącym recenzentami treści wywnioskować status oflagowania posta poprzez bezpośrednie wywołanie API.

Mattermost w wersjach 11.10.x <= 11.10.0, 11.7.x <= 11.7.9, 11.9.x <= 11.9.1, 11.8.x <= 11.8.5 nie ogranicza prywatnych zespołów przed pojawianiem się w publicznych wynikach wyszukiwania. Uwierzytelniony użytkownik bez uprawnień do listowania prywatnych zespołów może ujawnić ich ID, nazwę i nazwę wyświetlaną poprzez zmodyfikowane żądanie wyszukiwania.

Mattermost w wersjach 11.10.x <= 11.10.0, 11.7.x <= 11.7.9, 11.9.x <= 11.9.1, 11.8.x <= 11.8.5 nie weryfikuje adresu e-mail zaproszonego odbiorcy przy realizacji tokenów zaproszeń do zespołu i gościa. Uwierzytelniony atakujący może dołączyć do zespołu lub uzyskać nieautoryzowany dostęp do prywatnych kanałów poprzez przekazany lub wyciekły link zaproszenia.

W Mattermost w wersjach 11.10.x <= 11.10.0, 11.7.x <= 11.7.9, 11.9.x <= 11.9.1, 11.8.x <= 11.8.5 nie jest weryfikowana integralność parametru SAML RelayState POST. Umożliwia to uwierzytelnionemu użytkownikowi SAML dołączenie do dowolnego zespołu, w tym zespołów tylko na zaproszenie, poprzez sfałszowanie pól team_id lub invite_id w RelayState.

Mattermost w wersjach 11.10.x <= 11.10.0, 11.7.x <= 11.7.9, 11.9.x <= 11.9.1 oraz 11.8.x <= 11.8.5 nie ogranicza rozmiaru odpowiedzi zdalnych obrazów buforowanych w pamięci podczas bezpośredniego pobierania przez lokalny proxy obrazów. Zdalny atakujący może spowodować wyczerpanie pamięci serwera poprzez spreparowaną, zbyt dużą odpowiedź obrazu.