Katalog podatności CVE
Przetłumaczone opisy podatności z bazy NVD NIST - w języku polskim
Katalog CISA KEV zaktualizowany: (v2026.07.10)
Gogs przed wersją 0.14.3 umożliwia uwierzytelnionym użytkownikom zdalne wykonanie kodu (RCE) na serwerze poprzez utworzenie pull requesta z odpowiednio spreparowaną nazwą gałęzi, która wstrzykuje flagę --exec do polecenia git rebase podczas operacji scalania 'Rebase before merging'.
W Gogs przed wersją 0.14.3 wykryto podatność SSRF w funkcji migracji repozytorium. Aplikacja waliduje tylko początkowy host URL-a, ale operacja git clone --mirror podąża za przekierowaniami HTTP. Uwierzytelniony użytkownik może przesłać publiczny URL, który przekierowuje do wewnętrznego punktu końcowego (np. 127.0.0.1), importując zawartość wewnętrznego repozytorium do repozytorium kontrolowanego przez atakującego.
Gogs to otwartoźródłowy, samodzielnie hostowany serwis Git. Przed wersją 0.14.3, administrator repozytorium z uprawnieniami współpracownika może eskalować swoje uprawnienia do poziomu właściciela, wykorzystując błąd off-by-one w funkcji ChangeCollaborationAccessMode. Luka została naprawiona w wersji 0.14.3.
Gogs to otwartoźródłowa usługa Git, która przed wersją 0.14.3 zawierała podatność na otwarte przekierowania. Parametry redirect_to kontrolowane przez atakującego mogły omijać walidację, co pozwalało na przekierowanie do dowolnych zewnętrznych stron.
Gogs to otwartoźródłowa usługa Git, która przed wersją 0.14.3 miała lukę w funkcjonalności ustawień lustrzanych, umożliwiającą uwierzytelnionym użytkownikom import lokalnych repozytoriów bez odpowiedniej ochrony. Problem wynikał z braku walidacji funkcji SaveAddress.
Gogs przed wersją 0.14.3 umożliwia zarządzanie członkami zespołów organizacji za pomocą żądań GET bez ochrony CSRF. Atakujący może wykorzystać tę podatność, nakłaniając zalogowanego właściciela organizacji do odwiedzenia spreparowanego linku, co skutkuje dodaniem kontrolowanego przez atakującego użytkownika do zespołu Owners i uzyskaniem uprawnień właściciela organizacji.
Gogs to otwartoźródłowa usługa Git, która przed wersją 0.14.3 umożliwiała pobieranie załączników bez weryfikacji uprawnień użytkownika. Użytkownicy nieautoryzowani mogli pobierać załączniki z prywatnych repozytoriów.
Gogs to otwartoźródłowa usługa Git, która przed wersją 0.14.3 miała lukę umożliwiającą wykonanie złośliwego kodu JavaScript. Mimo że podglądy plików .ipynb były sanitizowane po stronie serwera, ich zawartość była ponownie renderowana po stronie klienta bez odpowiedniej sanitizacji, co prowadziło do możliwości wykonania ataku XSS.
Gogs to otwartoźródłowa usługa Git, która przed wersją 0.14.0 pozwalała autoryzowanym użytkownikom na manipulowanie wartością przekazywaną do polecenia git diff. Dzięki temu, użytkownik mógł ominąć filtrację wartości i zapisać wynik porównania w dowolnej lokalizacji.
Gogs przed wersją 0.14.3 zawiera podatność na atak DoS polegającą na panicznym zakończeniu działania podczas renderowania specjalnie spreparowanego wzorca indeksu zgłoszenia. Brak domknięcia nawiasu klamrowego w konfiguracji powoduje błąd w funkcji RenderIssueIndexPattern, co uniemożliwia dostęp do stron zawierających odwołania do zgłoszeń.
Gogs to otwartoźródłowa usługa Git, która w wersji 0.14.3 i wcześniejszych pozwala uwierzytelnionym użytkownikom na obserwowanie prywatnych repozytoriów, do których nie mają dostępu. Problem wynika z błędnie zaimplementowanej kontroli dostępu w API Watch, co umożliwia atakującym dostęp do informacji z prywatnych repozytoriów.
Mastodon przed wersjami 4.5.11, 4.4.18 i 4.3.24 zawiera podatność typu DoS spowodowaną brakiem obsługi wyjątków w sanitarze matematycznym. Złośliwe węzły <math> mogą prowadzić do awarii całego serwera lub usług użytkowników, w zależności od interakcji z tymi węzłami.
Mastodon, serwer społecznościowy oparty na ActivityPub, ma lukę w wersjach od 4.3.0 do 4.5.11 oraz 4.4.18, która pozwala na modyfikację wartości attributionDomains w podpisanych aktywnościach. Błąd w definicji tego terminu uniemożliwia skuteczne weryfikowanie podpisów Linked Data.
W punkcie końcowym visitors.info w Rocket.Chat zwracany jest token uwierzytelniający w odpowiedzi API. Nie ma uzasadnionego przypadku użycia dla obecności tego tokena w odpowiedzi, a jego wyciek stanowi zagrożenie bezpieczeństwa. Podatność została załatana w wersjach 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8 oraz 7.10.12.
Podatność w Rocket.Chat przed wersjami 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8 i 7.10.12 polega na braku unieważnienia tokenów OAuth (zarówno access, jak i refresh) po dezaktywacji użytkownika. Dezaktywowany użytkownik może nadal używać istniejącego tokena dostępu lub wygenerować nowy token na podstawie posiadanego tokena odświeżania.
W wersjach przed 8.5.0 komponent ImageElement w Rocket.Chat renderuje wartości src kontrolowane przez użytkownika bez sanitizacji protokołów. Umożliwia to wstawienie złośliwego URL z protokołem javascript:, co może prowadzić do wykonania dowolnego kodu JavaScript w sesji użytkownika.
Gogs to otwartoźródłowa usługa Git hostowana samodzielnie. W wersjach przed 0.14.3, poprawka dla CVE-2022-1285 uniemożliwiała dodawanie webhooków lub uruchamianie ich z adresami URL, których nazwa hosta rozwiązuje się w localCIDRs. Niemniej jednak, webhooki nadal podążają za przekierowaniami, co pozwala na dostęp do nazw hostów wewnątrz localCIDRs.
Podatność w Rocket.Chat przed wersjami 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7 i 7.10.11 powoduje, że implementacja dostawcy usług SAML pomija walidację podpisów odpowiedzi i asercji SAML, gdy pole certyfikatu IdP jest puste. Funkcja verifySignatures wykonuje wczesny powrót, gdy serviceProviderOptions.cert jest fałszywe, co jest domyślnym stanem ustawienia.
Podatność w Rocket.Chat umożliwia dezaktywowanym użytkownikom (przez funkcję users.deactivateIdle) dalsze korzystanie z już wydanych tokenów logowania. Oznacza to, że użytkownik oznaczony przez administratora jako nieaktywny z powodu bezczynności może nadal uzyskiwać dostęp do uwierzytelnionych punktów końcowych REST przy użyciu starego tokena.
Nieuwierzytelniony atakujący może uzyskać ważny token OAuth dla dowolnego użytkownika Rocket.Chat, wysyłając pojedyncze żądanie HTTP POST z operatorami zapytań MongoDB do endpointu /oauth/token. Serwer OAuth2 nie sprawdza, czy parametry grantu są ciągami znaków, co pozwala na podstawienie wartości takich jak {"$ne": null} i otrzymanie tokena dostępu dla pierwszego dopasowanego użytkownika.

