Katalog podatności CVE

GitLab EE w wersjach od 17.8 przed 19.3.6, od 19.4 przed 19.4.3 oraz od 19.5 przed 19.5.1 zawiera błąd, który w pewnych warunkach mógł pozwolić uwierzytelnionemu użytkownikowi na dostęp do płatnych funkcji AI bez ważnej subskrypcji z powodu niewystarczającej walidacji po stronie serwera w kontrolach uprawnień do rozliczeń.

GitLab EE zawiera błąd w logice czyszczenia, która nie odróżnia istniejących rekordów podatności od nowo utworzonych podczas obsługi błędów. W pewnych warunkach uwierzytelniony użytkownik z uprawnieniami tylko do odczytu może trwale usunąć istniejące rekordy podatności. Podatność dotyczy wersji od 17.8 przed 19.3.6, 19.4 przed 19.4.3 oraz 19.5 przed 19.5.1.

GitLab CE/EE we wszystkich wersjach od 18.3 przed 19.3.6, 19.4 przed 19.4.3 i 19.5 przed 19.5.1 zawiera podatność, w której nieuwierzytelniony użytkownik mógł zatruć współdzielony dokument odkrywania OAuth/OIDC w pamięci podręcznej, aby przekierować niektóre przepływy do zewnętrznie kontrolowanego serwera, z powodu niewłaściwego zaufania do wartości dostarczonych przez użytkownika podczas konstruowania adresów URL punktów końcowych w odpowiedziach odkrywania w pamięci podręcznej.

W GitLab CE/EE w wielu wersjach wykryto błąd przepełnienia liczb całkowitych podczas kompilacji spreparowanego wyrażenia regularnego. W określonych warunkach może to pozwolić nieuwierzytelnionemu użytkownikowi na wykonanie dowolnego kodu na serwerze GitLab.

GitLab CE/EE w wersjach od 17.6.5 przed 19.3.6, 19.4 przed 19.4.3 oraz 19.5 przed 19.5.1 zawiera lukę, która w pewnych warunkach pozwalała nieuwierzytelnionemu użytkownikowi pobrać wrażliwe wewnętrzne poświadczenia serwera z powodu niewłaściwego filtrowania wewnętrznych nagłówków odpowiedzi.

GitLab CE/EE naprawił problem w wersjach od 15.0 przed 19.3.6, 19.4 przed 19.4.3 oraz 19.5 przed 19.5.1, gdzie gdy merge request w publicznym projekcie odwoływał się do poufnego zgłoszenia z prywatnego projektu, uwierzytelniony użytkownik bez członkostwa w projekcie mógł odczytać tytuł poufnego zgłoszenia. Przyczyną był niezależny od przeglądającego klucz pamięci podręcznej fragmentów, który nieprawidłowo udostępniał wyrenderowaną treść z redakcją per użytkownik wszystkim użytkownikom.

GitLab EE naprawił problem w wersjach od 19.2 przed 19.3.6, 19.4 przed 19.4.3 oraz 19.5 przed 19.5.1, gdzie po zablokowaniu przez administratora instancji dostępności Duo dla grupy uwierzytelniony użytkownik z uprawnieniami Owner grupy mógł ponownie włączyć wysyłkę danych do usługi zewnętrznej opartej na AI dla tej grupy i jej projektów potomnych. Przyczyną była niewystarczająca szczegółowość mechanizmów egzekwowania blokady administratora.

W Archer C6 występuje podatność polegająca na zarządzaniu kluczem kryptograficznym na stałe (hardcoded) — używany jest uniwersalny klucz współdzielony między urządzeniami. Atakujący, który zdobędzie zaszyfrowany plik konfiguracyjny lub inne chronione dane uwierzytelniające, może odzyskać poświadczenia w postaci jawnej.

Cisco w ramach wewnętrznego przeglądu bezpieczeństwa wykrył wiele podatności związanych z plikami lub katalogami dostępnymi dla stron zewnętrznych (CWE-552). Poprawki zostały wydane w ramach aktualizacji utwardzającej oprogramowanie.

Cisco przeprowadził wewnętrzny przegląd bezpieczeństwa, którego wynikiem jest wydanie utwardzające poprawiające wiele wewnętrznie wykrytych luk. Luki objęte CVE-2026-76530 dotyczą używania niekanonicznych ścieżek URL w decyzjach autoryzacyjnych (CWE-647).

Cisco przeprowadził wewnętrzny przegląd bezpieczeństwa, w wyniku którego wydano aktualizację hardeningową naprawiającą wiele wykrytych wewnętrznie podatności. CVE-2026-76529 dotyczy niewłaściwej ochrony ścieżki alternatywnej (CWE-424).

Cisco przeprowadziło wewnętrzny przegląd bezpieczeństwa, który zaowocował wydaniem utwardzającym oprogramowanie, adresującym wiele wewnętrznie odkrytych podatności. Podatności objęte CVE-2026-76528 dotyczą awarii mechanizmu ochrony i są sklasyfikowane jako CWE-693.

Cisco przeprowadziło wewnętrzny przegląd bezpieczeństwa, który zaowocował wydaniem utwardzającym oprogramowanie, adresującym wiele wewnętrznie odkrytych podatności. Podatności objęte CVE-2026-76527 dotyczą nieprawidłowego sprawdzania lub obsługi warunków wyjątkowych i są sklasyfikowane jako CWE-703.

Cisco przeprowadził wewnętrzny przegląd bezpieczeństwa, w wyniku którego wydano aktualizację hardeningową naprawiającą wiele wykrytych wewnętrznie podatności. CVE-2026-76526 dotyczy niewłaściwej neutralizacji (CWE-707).

Cisco przeprowadził wewnętrzny przegląd bezpieczeństwa, w wyniku którego wydano aktualizację hardeningową naprawiającą wiele wykrytych wewnętrznie podatności. CVE-2026-76408 dotyczy niewłaściwej kontroli zasobu przez cały cykl jego życia (CWE-664).

Cisco przeprowadziło wewnętrzny przegląd bezpieczeństwa, który zaowocował wydaniem utwardzającym oprogramowanie, adresującym wiele wewnętrznie odkrytych podatności. Podatności objęte CVE-2026-76407 dotyczą nieprawidłowej kontroli dostępu i są sklasyfikowane jako CWE-284.

W Splunk SOAR w wersjach poniżej 8.7.0 nieuwierzytelniony użytkownik mający dostęp do zaszyfrowanych danych poświadczeń może przesłać dane uwierzytelniania Basic do API REST, aby ujawnić i odszyfrować te dane. Podatność wynika z tego, że Splunk SOAR odszyfrowuje zaszyfrowane wartości Basic przed zakończeniem kontroli uwierzytelniania. Atak wymaga posiadania zaszyfrowanych danych poświadczeń z podatnej instancji.

W Splunk SOAR w wersjach poniżej 8.7.0 uwierzytelniony użytkownik może zmienić edycję Enterprise Security poprzez REST API, powodując zastosowanie zmiany licencji. Podatność wynika z braku autoryzacji wywołującego przed zastosowaniem zmiany licencji.

W Splunk SOAR w wersjach poniżej 8.7.0 użytkownik posiadający rolę z uprawnieniem widoku Users and Roles może za pomocą API REST wywnioskować wartości tokenów uwierzytelniających innych użytkowników. Jeśli wywnioskowany token zapewnia dostęp administracyjny, użytkownik może uzyskać dostęp administracyjny do instancji Splunk SOAR. Podatność wynika z faktu, że API REST akceptuje kontrolowane przez wywołującego filtry zapytań na wrażliwych polach rekordów użytkowników.

W wersjach Splunk SOAR poniżej 8.7.0 użytkownik z rolą "Observer" może użyć filtrów zapytań w API REST do wywnioskowania hashy haseł i tokenów autoryzacyjnych innych użytkowników. Ujawnienie informacji jest możliwe, ponieważ filtry zapytań API REST są stosowane do rekordów użytkowników przed ochroną pól wrażliwych.