CVE-2026-79669

Ech0 przed wersją 4.4.3 nie egzekwuje autoryzacji opartej na zakresach na dziewięciu endpointach panelu administracyjnego komentarzy, co pozwala tokenom dostępu z minimalnymi zakresami na wykonywanie pełnych operacji moderacji komentarzy. Atakujący z tokenem o ograniczonym zakresie może listować, zatwierdzać, odrzucać, usuwać komentarze oraz modyfikować ustawienia systemu komentarzy, bezpośrednio uzyskując dostęp do niechronionych endpointów panelu.

Ech0 w wersji 4.3.4 i wcześniejszych nie egzekwuje w sposób niezawodny ograniczeń zakresu tokenów dostępu (najmniejszych uprawnień) na kilku uprzywilejowanych trasach administracyjnych. Wiele punktów końcowych (np. /api/inbox, /api/panel/comments, /api/backup/export) pomija sprawdzanie zakresu i autoryzuje tylko na podstawie roli administratora, a moduł eksportu kopii zapasowej całkowicie ignoruje metadane zakresu tokena. Atakujący posiadający celowo ograniczony (niski zakres) token administratora może uzyskać dostęp do szerszej funkcjonalności, w tym do skrzynki odbiorczej i eksportu pełnej kopii bazy danych ZIP. Poprawiono w wersji 4.4.3.

Ech0 przed wersją 4.5.1 zawiera podatność na obejście autoryzacji, gdzie tokeny sesji pomijają walidację zakresu w oprogramowaniu pośrednim RequireScopes, umożliwiając zalogowanym nie-administratorom dostęp do punktów końcowych administratora. Atakujący mogą czytać logi systemowe, statystyki odwiedzin, e-maile użytkowników i subskrybować na żywo logi WebSocket, wysyłając uwierzytelnione tokeny sesji do niechronionych punktów końcowych.

Ech0 przed wersją 4.7.3 nie unieważnia poprawnie tokenów dostępu utworzonych z opcją nigdy nie wygasają, umożliwiając atakującym utrzymanie ciągłego uwierzytelnionego dostępu po kradzieży tokena. Trzy niezależne mechanizmy unieważniania zawodzą: wylogowanie powoduje panikę przy polu ExpiresAt równym nil, RevokeToken pomija, gdy remainTTL wynosi zero, a usunięcie przez administratora nie umieszcza JTI na czarnej liście, pozostawiając skradzione tokeny kryptograficznie ważne aż do rotacji sekretu JWT.

Ech0 do wersji 4.5.6 zawiera podatność w walidacji URI przekierowania OAuth w funkcji parseAndValidateClientRedirect (internal/service/auth/auth.go), która porównuje tylko schemat i host URI redirect_uri dostarczonego przez klienta z listą dozwoloną skonfigurowaną przez administratora, ignorując ścieżkę, zapytanie i fragment. redirect_uri jest osadzane w podpisanym JWT stanu podczas logowania bez walidacji. Atakujący może skonstruować redirect_uri, którego host pasuje do dozwolonego pochodzenia, ale ścieżka jest kontrolowana przez atakującego; po wymianie OAuth ofiara jest przekierowywana na tę ścieżkę z jednorazowym kodem wymiany w ciągu zapytania. Jeśli kod wycieknie (np. przez Referer, analitykę lub otwarte przekierowanie na tym hoście), atakujący może go wymienić na publicznym punkcie końcowym POST /api/auth/exchange na tokeny dostępu i odświeżania ofiary. Poprawiono w wersji 4.7.3.

Wersje Ech0 przed 4.7.3 ujawniają adresy e-mail komentatorów-gości poprzez publiczne endpointy API z powodu nieprawidłowych tagów serializacji JSON w modelu Comment. Nieuwierzytelnieni atakujący mogą zebrać wszystkie e-maile komentatorów, wywołując endpointy /api/comments i /api/comments/public bez uwierzytelnienia.

Ech0 przed wersją 4.7.3 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w funkcji fetchPeerConnectInfo, która używa niezweryfikowanych żądań HTTP zamiast bezpiecznych metod z walidacją URL. Uwierzytelnieni atakujący mogą podać dowolne adresy URL, aby uzyskać dostęp do wewnętrznych usług i punktów końcowych metadanych chmury, wyzwalając kontrole stanu połączenia lub operacje połączenia peer.

Ech0 przed wersją 4.4.3 chroni endpoint PUT /user zakresem profile:read, który jest tylko do odczytu, ale pozwala na operacje zapisu, w tym zmianę hasła. Atakujący z tokenem dostępu profile:read administratora może zmienić hasło administratora i zalogować się, uzyskując nieograniczony token sesji, który omija wszystkie ograniczenia zakresów.

Ech0 przed wersją 4.4.3 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w funkcji validateWebhookURL (webhook_setting_service.go), która waliduje tylko dosłowne adresy IP za pomocą net.ParseIP() i nie odrzuca nazw hostów, które rozwiązują się na prywatne lub wewnętrzne adresy IP (np. 169.254.169.254.nip.io). Atakujący z uprawnieniami administratora może utworzyć webhook z taką nazwą hosta, aby ominąć walidację i spowodować, że serwer będzie wysyłać żądania do wewnętrznych usług, punktów końcowych metadanych chmury i zasobów sieci prywatnej. Problem został naprawiony w wersji 4.4.3.

Ech0 przed wersją 4.4.3 zawiera podatność na trwały cross-site scripting (XSS) w endpointcie przesyłania plików, który waliduje Content-Type tylko na podstawie nagłówków dostarczonych przez klienta, bez inspekcji po stronie serwera. Atakujący z uprawnieniami administratora może przesłać pliki SVG lub HTML zawierające JavaScript, który wykonuje się w kontekście aplikacji, gdy uzyska do nich dostęp dowolny użytkownik, umożliwiając przejęcie sesji i eksfiltrację danych.