Katalog podatności CVE

Renovate w wersjach od 35.63.0 do przed 40.33.0 zawiera podatność na wstrzyknięcie poleceń w menedżerze npm, gdzie wartości packageName dostarczane przez użytkownika są dołączane do poleceń npm install bez odpowiedniej sanityzacji. Atakujący z prawem zapisu do repozytorium mogą stworzyć złośliwe pliki konfiguracyjne Renovate, aby wykonać dowolne polecenia na maszynie uruchamiającej Renovate.

Renovate w wersjach od 39.218.0 do przed 40.33.0 zawiera podatność na dowolne wstrzyknięcie poleceń w menedżerze kustomize, gdzie nazwy chartów dostarczane przez użytkownika są dołączane do poleceń helm pull bez odpowiedniej sanityzacji. Atakujący z prawem zapisu do repozytorium mogą stworzyć złośliwe pliki kustomization.yaml ze specjalnie spreparowanymi nazwami chartów, aby wykonać dowolne polecenia na maszynie hostującej Renovate.

Renovate w wersjach >=32.124.0 i przed 42.68.5 (oraz Mend renovate-ce/renovate-ee przed 13.3.0) zawiera podatność na wstrzyknięcie poleceń w obsłudze artefaktów Gradle Wrapper. Podczas przetwarzania aktualizacji Gradle Wrapper, Renovate wywołuje polecenie aktualizacji przez powłokę (np. /bin/sh -c ... ./gradlew :wrapper --gradle-distribution-url <wartość>). Jeśli atakujący dostarczy złośliwy plik gradle-wrapper.properties, którego distributionUrl zawiera składnię podstawiania poleceń, taką jak $(...), powłoka wykonuje ją przed przetworzeniem URL przez Gradle, co prowadzi do wykonania dowolnych poleceń w środowisku Renovate. Eksploatacja wymaga wprowadzenia złośliwego pliku do repozytorium skanowanego przez Renovate; problem występuje nawet gdy allowScripts jest wyłączone.

Renovate w wersjach od 42.68.1 przed 42.96.3 (oraz od 42.68.1 przed 43.4.4), w tym odpowiadające obrazy Docker (renovate/renovate, mend/renovate-ce, renovate-ee-server, renovate-ee-worker >=13.3.0 <13.6.0), nie ograniczają zmiennych środowiskowych do listy dozwolonych podczas uruchamiania procesów potomnych. W rezultacie procesy potomne (np. npm install, postUpgradeTasks, postUpdateOptions) uzyskują pełny dostęp do wszystkich zmiennych środowiskowych procesu Renovate, co pozwala atakującym wewnętrznym lub zewnętrznym na eksfiltrację sekretów dostępnych dla wdrożenia Renovate.

Renovate w wersjach od 43.65.0 przed 43.102.11 zawiera podatność na zdalne wykonanie kodu w menedżerach bazel-module i bazelisk podczas korzystania z lockFileMaintenance. Atakujący mogą wykonać dowolny kod, dostarczając złośliwe zależności, które są przywoływane w wywołaniach bazel mod deps, takich jak wewnątrz instrukcji ctx.execute.

ArcadeDB przed wersją 26.8.1 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w implementacji OpenCypher LOAD CSV, która nie waliduje adresów URL HTTP/HTTPS. Uwierzytelnieni atakujący mogą tworzyć zapytania LOAD CSV wskazujące na wewnętrzne adresy sieciowe lub punkty końcowe metadanych chmury, aby zmusić serwer ArcadeDB do pobrania i zwrócenia wrażliwych danych z ograniczonych usług.

ArcadeDB przed wersją 26.8.1 zawiera podatność zdalnego wykonania kodu w silniku zapytań Gremlin. Mimo że domyślnie używany jest bezpieczny silnik java, ArcadeGremlin.executeStatement() po cichu przełącza się na niebezpieczny silnik Groovy, gdy żądanie zawiera parametry zapytania, a zapytanie nie jest parsowane jako gremlin-lang. Uwierzytelniony użytkownik z dowolną rolą, w tym tylko do odczytu, może wykonać dowolne polecenia systemu operacyjnego jako proces serwera ArcadeDB.

ArcadeDB (com.arcadedb) w wersjach 26.7.3 i wcześniejszych nie egzekwuje sprawdzenia uprawnień UPDATE_SCHEMA, gdy instrukcja DEFINE FUNCTION dotyczy już istniejącej biblioteki funkcji. Użytkownik z samym dostępem do bazy danych może dodawać lub nadpisywać funkcje SQL lub Cypher w istniejącej bibliotece i utrwalić zmianę, co umożliwia manipulowanie logiką funkcji zdefiniowanych przez administratora. Problem został naprawiony w wersji 26.8.1.

GitPython przed wersją 3.1.58 nie waliduje nazw podmodułów z plików .gitmodules, co pozwala atakującym tworzyć repozytoria Git w dowolnych ścieżkach systemu plików poza zamierzonym katalogiem klonowania. Atakujący mogą stworzyć złośliwe repozytoria z sekwencjami przejść w nazwach podmodułów, które GitPython przetwarza podczas inicjalizacji podmodułów, tworząc kontrolowane przez atakującego repozytoria Git w uciekających lokalizacjach.

GitPython przed wersją 3.1.58 zawiera podatność wstrzykiwania nazw konfiguracji w walidatorze nazw opcji, która pozwala atakującym na fałszowanie dowolnych dyrektyw git-config poprzez wstrzykiwanie znaków równości, hashy i białych znaków do nazw opcji. Atakujący mogą wstrzyknąć złośliwe nazwy opcji, takie jak 'sshCommand = touch /tmp/RCE #', aby wykonać dowolne polecenia przez core.sshCommand lub core.hooksPath podczas następnej operacji git.

GitPython przed wersją 3.1.58 zawiera podatność wykonania poleceń w zabezpieczeniu check_unsafe_options, które można obejść, łącząc jednoznakowy argument kwargs z split_single_char_options=False. Atakujący mogą dostarczyć spreparowany słownik kwargs do chronionych metod, takich jak clone_from, aby wyemitować połączony token parsowany jako --upload-pack, umożliwiając wykonanie dowolnych poleceń systemu operacyjnego przy domyślnym allow_unsafe_options=False.

GitPython przed wersją 3.1.58 zawiera podatność dowolnego nadpisywania plików w metodach IndexFile.from_tree, IndexFile.reset i IndexFile.merge_tree, które dołączają ciągi treeish kontrolowane przez wywołującego do git read-tree bez walidacji opcji lub separacji argumentów. Atakujący mogą wstrzyknąć opcję --index-output, aby nadpisać dowolne pliki prawidłowym blobem indeksu git, niszcząc istniejącą zawartość plików w ścieżkach zapisywalnych kontrolowanych przez atakującego.

GitPython przed wersją 3.1.58 zawiera podatność zdalnego wykonania kodu w funkcji Repo.init, która przekazuje niebezpieczne opcje git bez walidacji. Atakujący może dostarczyć parametr template wskazujący na katalog ze złośliwymi hakami git, które wykonują dowolny kod podczas operacji git na zainicjalizowanym repozytorium.

GitPython w wersjach przed 3.1.58 nie waliduje opcji przekazywanych do poleceń git rm i git checkout w metodach IndexFile.remove() i Head.checkout(). Atakujący mogą dostarczyć parametry --pathspec-from-file i --pathspec-file-nul, aby odczytać dowolne pliki dostępne dla procesu, a pełna zawartość plików jest zwracana w GitCommandError.stderr.

Vikunja do wersji 2.4.0 zawiera podatność polegającą na pomyleniu typów podmiotów (principal-type confusion), gdzie podmioty LinkSharing z identyfikatorem N są traktowane jak podmioty użytkowników z users.id == N w trzech kontrolach uprawnień pozbawionych sprawdzenia typu. Atakujący z JWT link-share może usuwać ofiary z zespołów, wyliczać i usuwać boty użytkowników ofiar lub czytać listy zespołów, wykorzystując kolizje identyfikatorów w przestrzeni autoincrement.

phpMyFAQ przed wersją 4.1.7 nie stosuje kontroli widoczności nadrzędnych wpisów FAQ przed zwróceniem zasobów podrzędnych, takich jak komentarze i załączniki. Niezalogowani atakujący mogą pobrać treść ograniczonych komentarzy, adresy e-mail komentujących oraz nazwy plików załączników dla wpisów FAQ, do których nie mają bezpośredniego dostępu, poprzez zapytania do endpointów API komentarzy i załączników.

phpMyFAQ przed wersją 4.1.7 nie zapisuje wygenerowanego wyzwania logowania WebAuthn, co pozwala atakującemu na przechwycenie udanej asercji WebAuthn i jej wielokrotne odtwarzanie, aby uwierzytelnić się jako użytkownik bez interakcji z nim.

phpMyFAQ przed wersją 4.1.7 zawiera podatność brute-force w kroku uwierzytelniania dwuskładnikowego, gdzie licznik nieudanych prób jest powiązany z sesją i resetowany po każdym pomyślnym ponownym uwierzytelnieniu hasłem. Atakujący z ważnym hasłem może ominąć limit pięciu prób, uzyskując nowy ciasteczko sesji i wielokrotnie ponownie uwierzytelniając się, aby zresetować licznik, co umożliwia nieograniczone zgadywanie kodów TOTP.

phpMyFAQ przed wersją 4.1.7, gdy jest skonfigurowany do korzystania z PostgreSQL przez natywne rozszerzenie PHP pgsql, deklaruje nieprawidłowy znak ESCAPE dla LIKE ('=') w backendzie Search/Database/Pgsql.php, podczas gdy escapeLikeWildcards() poprzedza dane wejściowe użytkownika prefiksem '|'. W rezultacie escapowanie znaków wieloznacznych jest nieskuteczne, a znaki % i _ dostarczone przez użytkownika pozostają aktywnymi znakami wieloznacznymi LIKE. Niezalogowany atakujący może przesłać takie znaki w publicznym formularzu wyszukiwania FAQ, aby wymusić maksymalnie szerokie dopasowania wzorców i kosztowne skanowania sekwencyjne, co prowadzi do odmowy usługi. Backend PDO PostgreSQL nie jest dotknięty, a cudzysłowy pozostają escapowane, więc nie umożliwia to wstrzyknięcia SQL przez złamanie cudzysłowów ani eksfiltracji danych.

phpMyFAQ przed wersją 4.1.7 nie egzekwuje prawidłowo uprawnienia CONFIGURATION_EDIT na punktach końcowych API odczytu dla konfiguracji LDAP, Elasticsearch, OpenSearch i pulpitu nawigacyjnego, co pozwala każdemu uwierzytelnionemu użytkownikowi na dostęp do wrażliwych danych administracyjnych. Atakujący mogą pobrać topologię serwera LDAP, nazwy kont bind, bazy wyszukiwania, statystyki indeksów i analitykę witryny, wywołując te punkty końcowe z ważną sesją.