CVE-2026-66077

RabbitMQ to broker przesyłania wiadomości i przesyłania strumieniowego. Przed wersjami 3.13.15, 4.0.20, 4.1.11 i 4.2.6 interfejs zarządzania korzysta z EJS 1.0, w którym <%= ... %> NIE powoduje ucieczki HTML. połączenie.ejs:135 renderuje <%= połączenie.ssl_details.peer_cert_subject %> (i peer_cert_issuer) bezpośrednio na stronę. Ten sam wzorzec pojawia się w pliku streamConnection.ejs:102,106,110. Wartości pochodzą z królika_ssl:peer_cert_subject/1, który formatuje nazwę wyróżniającą jako ciąg znaków bez zmiany znaczenia kodu HTML. Weryfikator poprawił twierdzenie pierwotnego badacza: jest to osiągalne tylko wtedy, gdy odbiornik jest skonfigurowany z funkcją Verify_peer (więc certyfikat musi zostać podpisany przez urząd certyfikacji w magazynie zaufania brokera, a nie arbitralnie podpisany przez siebie); jednakże we wdrożeniach wykorzystujących mTLS do uwierzytelniania klienta każdy użytkownik, który może zażądać certyfikatu od urzędu certyfikacji organizacji, kontroluje podmiot CN. Osoba atakująca, która może uzyskać certyfikat klienta TLS podpisany przez urząd certyfikacji, któremu ufa broker (z włączoną funkcją weryfikacji_peer), może osadzić JavaScript w nazwie wyróżniającej podmiotu certyfikatu. Gdy dowolny administrator wyświetli to połączenie w interfejsie zarządzania, skrypt zostanie wykonany w sesji przeglądarki administratora, umożliwiając pełne przejęcie konta (tworzenie użytkowników, eksportowanie definicji itp.). CSP interfejsu zarządzania zawiera opcję „unsafe-inline”, więc wykonywanie skryptów wbudowanych nie jest blokowane. Warunki wstępne obejmują odbiornik TLS skonfigurowany z ssl_options.verify = zweryfikować_peer Osoba atakująca może uzyskać podpisany przez urząd certyfikacji certyfikat klienta z wybranym przez osobę atakującą tematem (np. samoobsługowa korporacyjna infrastruktura PKI lub używana wtyczka królika mq_trust_store). Administrator przegląda stronę szczegółów połączenia. Ten problem został rozwiązany w wersjach 3.13.15, 4.0.20, 4.1.11 i 4.2.6.