CVE-2023-36466

W Discourse przed wersjami 3.5.4, 2025.11.2, 2025.12.1 i 2026.1.0, przekierowania z linków permalink do zasobów z ograniczonym dostępem (prywatne tematy, kategorie, posty lub ukryte tagi) ujawniały slug zasobu w adresie URL, nawet gdy użytkownik nie miał do niego dostępu. To powodowało wyciek potencjalnie wrażliwych informacji, takich jak tytuły prywatnych tematów, poprzez nagłówek Location oraz pole wyszukiwania na stronie 404.

Discourse, platforma dyskusyjna o otwartym kodzie źródłowym, zawiera podatność w wersjach przed 3.5.4, 2025.11.2, 2025.12.1 i 2026.1.0. Problem dotyczy walidacji nazwy hosta w komponencie FinalDestination, co może umożliwić obejście zabezpieczeń SSRF w określonych warunkach.

Discourse to platforma dyskusyjna o otwartym kodzie źródłowym. W wersjach przed 3.5.4, 2025.11.2, 2025.12.1 i 2026.1.0 niektóre punkty końcowe subskrypcji nie sprawdzają poprawnie własności przed wprowadzeniem zmian. Luka została załatana w wymienionych wersjach.

Przed wersjami 2026.1.6, 2026.5.2, 2026.6.1 i 2026.7.0 w Discourse, nieuwierzytelniony atakujący mógł wysłać pojedyncze żądanie z spreparowanym ciasteczkiem color_scheme_id (lub dark_scheme_id), aby wstrzyknąć dowolny HTML na stronę Discourse. Ponieważ wartość ciasteczka była renderowana w tagu schematu kolorów bez escapowania, atakujący mógł wydostać się z atrybutu i wstrzyknąć tag, który omijał politykę bezpieczeństwa treści opartą na nonce, co prowadziło do wykonania dowolnego JavaScriptu w przeglądarkach odwiedzających.

Discourse przed wersjami 2026.1.8, 2026.6.3, 2026.7.2 i 2026.8.0 renderował kontrolowane przez atakującego nazwy plików przesyłanych w fragmentach wiadomości czatu jako niesanityzowany HTML. Użytkownik mogący przesłać plik i wysłać treść czatu mógł umieścić znaczniki w nazwie pliku, które były interpretowane przez listy kanałów czatu, e-maile z podsumowaniem czatu, przypięte paski wiadomości, podglądy odpowiedzi i inne renderery fragmentów. Podatność umożliwiała wstrzyknięcie zaufanego HTML, ale nie wykazano wykonania JavaScript przy domyślnych ustawieniach CSP.

Discourse przed wersjami 2026.1.8, 2026.6.3, 2026.7.2 i 2026.8.0 mógł ponownie parsować kontrolowane przez dostawcę tytuły filmów w leniwych osadzeniach wideo jako HTML podczas generowania e-maili powiadomień lub podsumowań czatu. Użytkownik z podstawowymi uprawnieniami do publikowania mógł utworzyć post dla włączonego dostawcy YouTube, Vimeo lub TikTok, którego tytuł zawierał znaczniki, a ścieżka renderowania e-maili i podsumowań czatu umieszczała te znaczniki w wyniku zamiast traktować je wyłącznie jako tekst. Odbiorcy używający klientów poczty obsługujących HTML mogli zobaczyć wstrzykniętą treść, potencjalnie w tym procedury obsługi zdarzeń, ale podatność nie ujawniała bezpośrednio sesji przeglądarki Discourse ani nie wpływała na samą stronę forum.

Discourse przed wersjami 2026.1.8, 2026.6.3, 2026.7.2 i 2026.8.0 interpolował wolną wartość action_code_who do atrybutów href linków wzmianek bez kodowania URL. Nazwa wyświetlana zawierająca cudzysłów mogła zakończyć zamierzony atrybut URL i wstrzyknąć kontrolowane przez atakującego elementy do zaufanego renderowanego znacznika. Chociaż widoczny tekst wzmianki był escapowany, niezakodowany komponent ścieżki umożliwiał trwałe wstrzyknięcie HTML, gdy inny użytkownik wyświetlił dotkniętą akcję tematu lub dziennik aktywności.

Discourse przed wskazanymi wersjami pozwalał na przechowywany atak typu cross-origin iframe, który omijał politykę allowed_iframes dzięki zakodowanemu userinfo w atrybucie src. Uwierzytelniony użytkownik z uprawnieniami do pisania mógł umieścić iframe w poście, co prowadziło do renderowania treści z kontrolowanej przez atakującego domeny.

Discourse przed wskazanymi wersjami umożliwiał uwierzytelnionym użytkownikom wstrzyknięcie niezabezpieczonych znaków wildcard SQL (takich jak % i _) we wzorcach rozpoznawania uploadów, co powodowało wybieranie niepowiązanych rekordów. Dostęp do niedozwolonych metadanych, w tym nazw plików i ścieżek secure-upload, był możliwy bez modyfikacji rekordów.

Discourse przed wskazanymi wersjami, gdy używano wzorców wildcard w ustawieniu allowed_iframes, mógł akceptować spreparowany adres URL iframe, którego zezwolony sufiks pojawiał się po separatorze authority. Kontrola pochodzenia omijała listę, a przeglądarka wybierała inny atakowany origin, co pozwalało na renderowanie kontrolowanego iframe.