Katalog podatności CVE

Renovate to narzędzie do automatyzacji aktualizacji zależności. Podczas listowania tagów/digestów dla obrazu kontenera Renovate podąża za linkami paginacji dostarczonymi przez zdalny rejestr w nagłówku HTTP Link i dołącza poświadczenia rejestru do żądania follow-up bez weryfikacji, czy URL paginacji ma to samo pochodzenie co oryginalny rejestr. Złośliwy lub przejęty rejestr kontenerów może zatem wskazać nagłówek Link na host kontrolowany przez atakującego i otrzymać poświadczenia Renovate używane dla tego rejestru. Wykorzystanie wymaga, aby cel miał zależności kontenerowe (Docker) i już wchodził w interakcję ze złośliwym lub przejętym rejestrem. Naprawiono w Renovate 44.11.2 (obrazy npm i renovate/renovate), Mend Renovate CE/EE 15.4.0 oraz mend-renovate-enterprise-edition Helm chart 10.4.0; sprawdzenie tego samego pochodzenia można wyłączyć za pomocą RENOVATE_X_DOCKER_PAGINATION_ALLOW_CROSS_ORIGIN.

Renovate to narzędzie do automatyzacji aktualizacji zależności. W wersjach przed 44.14.7 (oraz w dystrybucjach Mend Renovate CE/EE przed 15.4.0 i mend-renovate-enterprise-edition Helm chart przed 10.4.0) moduł manager/gradle-wrapper nie escapuje wartości distributionUrl odczytanej z pliku gradle/wrapper/gradle-wrapper.properties repozytorium przed wywołaniem CLI Gradle Wrapper. W instalacjach self-hosted skonfigurowanych z binarySource=docker i allowedUnsafeExecutions=['gradleWrapper', ...], repozytorium dostarczające spreparowany distributionUrl (na przykład dodające metaznak powłoki i polecenie) może spowodować wykonanie dowolnych poleceń jako użytkownik Renovate, gdy Renovate przetwarza aktualizację Gradle Wrapper. Problem naprawiono w Renovate 44.14.7; jako obejście należy usunąć 'gradleWrapper' z allowedUnsafeExecutions.

Renovate przed wersją 44.14.7 zawiera podatność command injection w menedżerze gomod podczas przetwarzania nieescapowanych parametrów depName w poleceniach aktualizacji ścieżki importu w trybie binarySource=docker. Atakujący mogą wstrzyknąć metaznaki powłoki poprzez złośliwe nazwy zależności, aby wykonać dowolne polecenia jako użytkownik Renovate podczas aktualizacji głównych wersji modułów Go z włączoną opcją postUpdateOptions gomodUpdateImportPaths.

Renovate w wersjach przed 44.3.1 (oraz obrazy Mend Renovate CE/EE przed 15.4.0, helm chart mend-renovate-ce przed 15.4.0 i mend-renovate-enterprise-edition przed 10.4.0) nie stosuje wewnętrznego sprawdzania minimalnego wieku wydania (minimumReleaseAge) do aktualizacji typu digest. Gdy repozytorium ma skonfigurowane minimumReleaseAge i zależności z updateType=digest (np. GitHub Actions przypięte do SHA, obrazy Docker, moduły Go, pakiety NuGet), Renovate nadal otwiera pull request dla nowo opublikowanego digestu, oznaczając go jedynie statusem renovate/stability-days.

Renovate to narzędzie do automatycznej aktualizacji zależności. W wersjach przed 44.14.4 (oraz obrazach Mend Renovate CE/EE przed 15.4.0 i mend-renovate-enterprise-edition Helm chart przed 10.4.0) sanityzacja logów dla kluczy prywatnych TLS używanych do Mutual TLS była niekompletna. Chociaż wartość hostRules[].httpsPrivateKey była redagowana w samym polu, ta sama wartość klucza prywatnego nie była redagowana, jeśli pojawiła się gdzie indziej — na przykład w innej opcji konfiguracyjnej lub w komunikacie logu pod kluczem innym niż httpsPrivateKey — powodując zapisanie pełnego klucza prywatnego do logów Renovate w postaci jawnej. Dotyczy to wdrożeń konfigurujących Mutual TLS przez hostRules[].httpsPrivateKey bez przekazywania wartości przez udokumentowaną konfigurację `secrets`. Każdy, kto może odczytać wynikowe logi, może odzyskać klucz prywatny. Problem naprawiono w Renovate 44.14.4, który redaguje każdą wartość dostarczoną jako hostRules[].httpsPrivateKey wszędzie tam, gdzie pojawia się w logach; jako obejście należy dostarczyć klucz przez konfigurację `secrets`.

Renovate to narzędzie do automatyzacji aktualizacji zależności. W wersjach przed 44.11.2 (oraz obrazach i chartach Mend Renovate CE/EE przed 15.4.0 i mend-renovate-enterprise-edition helm chart przed 10.4.0), podczas listowania nowych wersji pakietów z rejestru NuGet Renovate podąża za URL-ami paginacji dostarczonymi przez rejestr w nagłówku HTTP `Link` bez weryfikacji, czy cel ma to samo pochodzenie co skonfigurowany rejestr. Poświadczenia rejestru są dołączane do żądania dla strony 'next', więc złośliwy lub przejęty rejestr NuGet może zwrócić nagłówek `Link` wskazujący na serwer kontrolowany przez atakującego i spowodować wysłanie poświadczeń rejestru do tego serwera. Wykorzystanie wymaga, aby zdalny rejestr był złośliwy lub przejęty; taki rejestr normalnie już otrzymałby poświadczenia w początkowym żądaniu, więc problem głównie pozwala na dostarczenie poświadczeń do dodatkowego, wybranego przez atakującego hosta. Poprawka ogranicza paginację do tego samego pochodzenia; poprzednie zachowanie można ponownie włączyć opcją RENOVATE_X_NUGET_PAGINATION_ALLOW_CROSS_ORIGIN.

Renovate, narzędzie do aktualizacji zależności, podąża za linkami paginacji dostarczonymi przez serwer GitHub w nagłówku HTTP `Link` podczas interakcji z GitHub.com, GitHub Enterprise Cloud lub GitHub Enterprise Server i wysyła poświadczenia skonfigurowane dla tego hosta do URL-a podanego jako strona 'next'. Ponieważ URL paginacji nie jest walidowany względem hosta, z którym początkowo nawiązano kontakt, złośliwy lub przejęty serwer GitHub może zwrócić nagłówek `Link` wskazujący na host kontrolowany przez atakującego i spowodować ujawnienie mu tych poświadczeń. Wykorzystanie wymaga, aby serwer GitHub, z którym rozmawia Renovate (jako host repozytorium lub źródło danych takie jak github-releases, github-tags lub git-refs), był już złośliwy lub przejęty. Problem naprawiono w renovate 44.11.3 (obrazy npm i renovate/renovate), Mend Renovate CE/EE i mend-renovate-ce helm chart 15.4.0 oraz mend-renovate-enterprise-edition helm chart 10.4.0. Nie ma obejścia; istniejąca opcja RENOVATE_X_REBASE_PAGINATION_LINKS wyłącza nowe sprawdzenie hosta i powinna być używana tylko z serwerami, które celowo używają różnych hostów paginacji.

Renovate w wersjach przed 44.11.3 nie weryfikuje miejsc docelowych nagłówka Link podczas podążania za paginacją serwera GitLab. Złośliwy serwer GitLab może wskazać w nagłówku Link adres kontrolowanej przez atakującego infrastruktury, co prowadzi do przekierowania żądań zawierających poświadczenia i ich wycieku.

Traefik w wersjach v1.x, v2.x do v2.11.55 oraz v3.0.0 do v3.7.11 kanonikalizuje nazwy nagłówków tylko po myślnikach, przez co X-Auth-User, X_Auth_User i X.Auth.User są traktowane jako trzy różne nagłówki, podczas gdy backendy (CGI, WSGI, PHP, NGINX i inne) sprowadzają je do jednej zmiennej. Klient może przemycić alias z kropką nagłówka zarządzanego przez Traefik obok kanonicznej wersji, np. X.Authenticated.User obok X-Authenticated-User, powodując, że backend odczyta wartość dostarczoną przez klienta zamiast tożsamości potwierdzonej przez Traefik.

Traefik w wersjach od v2.8.2 do v2.11.55 oraz od v3.0.0 do v3.7.11 nie stosuje ustawień entryPoints.<name>.transport.respondingTimeouts (w szczególności readTimeout, domyślnie 60s) do ścieżki żądań HTTP/3. readTimeout jest egzekwowany jako deadline na połączeniu TCP, czego nie można zastosować do strumienia QUIC, a serwer HTTP/3 w Traefik jest tworzony bez żadnego timeoutu. W efekcie nieuwierzytelniony zdalny klient może przesyłać bajty ciała żądania powoli i utrzymywać żądanie otwarte bezterminowo.

Traefik (HTTP reverse proxy i load balancer) w wersjach >= v3.7.0 i <= v3.7.11 ma błąd w providerze Kubernetes ingress-nginx dotyczący Ingressów z jednocześnie ustawioną adnotacją uwierzytelniania i adnotacją nginx.ingress.kubernetes.io/from-to-www-redirect. Provider tworzy dodatkowy router 'sibling', który dopasowuje tylko host, zawiera wyłącznie middleware RedirectRegex i wskazuje na chroniony backend routera nadrzędnego. Ponieważ RedirectRegex nie jest terminalnym handlerem, żądanie niedopasowane do wzorca jest przekazywane do backendu, a ponieważ wzorzec przekierowania akceptuje tylko port numeryczny, żądanie z portem nienumerycznym lub pustym (np. 'Host: www.example.com:x') wybiera router sibling, omija przekierowanie i jest proxowane do chronionego backendu bez żadnych middleware'ów wynikających z adnotacji Ingress. Powoduje to utratę nie tylko uwierzytelniania (np. BasicAuth), ale także wszystkich middleware'ów z adnotacji, w tym allowlisty źródłowych adresów IP. Wersje Traefik v2 i v3 przed v3.7.0 nie są podatne. Problem naprawiono w v3.7.12.

AVideo do rewizji c3edcc274c389816d434acadac07ee78eaf330c1 zawiera podatność braku autoryzacji w pliku plugin/PlayerSkins/seo.php. Nieuwierzytelniony atakujący może uzyskać dostęp do źródeł wideo chronionych hasłem, wywołując getSources() bez weryfikacji hasła i pobierając bezpośredni adres URL pliku MP4.

AVideo do rewizji c3edcc274c389816d434acadac07ee78eaf330c1 (master, 2026-08-23) niekompletnie oczyszcza wrażliwe pola użytkownika w odpowiedzi APIName=video. Wiersze wideo zawierają kolumny dołączone z rekordu właściciela, a API::get_api_video() wywołuje removeSensitiveUserFields() tylko gdy wywołujący nie jest uwierzytelniony i nie używa ważnego sekretu API; nigdy nie porównuje User::getId() z users_id wiersza. W rezultacie każde konto o niskich uprawnieniach może zażądać wideo innego użytkownika i otrzymać jego adres e-mail, nazwę konta (user) oraz flagi isAdmin, canUpload i canStream.

AVideo do rewizji c3edcc274c389816d434acadac07ee78eaf330c1 nie wymusza sprawdzenia hasła transmisji na żywo w endpoincie statystyk ani w źródle HLS. Funkcja Live::_getStats() zwraca nieuwierzytelnionym wywołującym klucz strumienia RTMP, flagę isPasswordProtected oraz adres URL HLS, a dołączona konfiguracja NGINX udostępnia playlistę .m3u8, klucz AES-128 i segmenty transport-stream bez uwierzytelniania.

WWBN AVideo do commita c3edcc274c389816d434acadac07ee78eaf330c1 zawiera podatność cross-site request forgery w pliku view/logArchive.json.php. Nieuwierzytelnieni atakujący mogą archiwizować logi aplikacji, wysyłając żądania GET bez weryfikacji tokenu CSRF, kopiując wrażliwe logi do publicznie dostępnego pliku ZIP i obcinając bieżący log.

AVideo do commita c3edcc274c389816d434acadac07ee78eaf330c1 zawiera podatność cross-site request forgery w endpoincie setPassword.json.php. Nieuwierzytelnieni atakujący mogą modyfikować hasło kanału dowolnego użytkownika, wysyłając żądanie GET bez weryfikacji tokenu CSRF.

WWBN AVideo do commita c3edcc274c389816d434acadac07ee78eaf330c1 (master, 2026-08-23) zawiera podatność CSRF w punkcie końcowym plugin/CustomizeUser/setSubscribers.json.php wtyczki CustomizeUser. Skrypt odczytuje users_id i ExtraSubscribers z $_REQUEST i wywołuje User::setExtraSubscribers() bez wymogu żądania POST ani ważnego tokenu CSRF; autoCSRFGuard() jest stosowany tylko do żądań POST do *.json.php, a mutacja nie przechodzi przez ObjectYPT::save()/isUntrustedRequest(), więc cross-origin GET kończy się sukcesem. Nieuwierzytelniony zdalny atakujący może nakłonić zalogowanego administratora do wczytania spreparowanej strony (np. tagu <img> wskazującego na endpoint) i sfałszować liczbę ExtraSubscribers wyświetlaną na kanale dowolnego użytkownika.

WWBN AVideo do commita c3edcc274c389816d434acadac07ee78eaf330c1 zawiera podatność cross-site request forgery w endpointach klucza PGP wtyczki LoginControl, które nie weryfikują tokenu CSRF. Atakujący mogą tworzyć złośliwe strony z tagami obrazów wskazującymi na savePublicKey.json.php, aby zastąpić klucz publiczny PGP 2FA zalogowanej ofiary.

AVideo do commita c3edcc274c389816d434acadac07ee78eaf330c1 zawiera podatność stored cross-site scripting (XSS) w endpoincie log.php wtyczki AD_Server, który nie escapuje parametru label przed zapisem. Nieuwierzytelniony atakujący może wstrzyknąć złośliwy HTML przez parametr label, który jest później renderowany bez sanityzacji w raporcie Ad Types w panelu administratora przy użyciu jQuery .html(), co pozwala na wykonanie dowolnego JavaScriptu w sesji przeglądarki administratora.

AVideo do commita c3edcc274c389816d434acadac07ee78eaf330c1 zawiera podatność stored cross-site scripting we wtyczce LiveLinks, gdzie pola title i description są przechowywane bez sanityzacji. Użytkownik z uprawnieniem canStream może wstrzyknąć złośliwe skrypty, które wykonują się w przeglądarce każdego odwiedzającego stronę live-link, w tym administratorów.