Katalog podatności CVE

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 43.0.0 przed 43.4.4 (w tym obrazy Docker renovate/renovate) oraz Mend Renovate CE/EE w wersjach od 13.3.0 przed 13.6.0 nie ograniczają zmiennych środowiskowych do listy dozwolonych przy tworzeniu procesów potomnych. W rezultacie procesy potomne (np. npm install, postUpgradeTasks) mają dostęp do wszystkich zmiennych środowiskowych procesu Renovate, co umożliwia atakującym eksfiltrację sekretów.

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ą.

phpMyFAQ przed wersją 4.1.6 nie odpowiednio sanityzuje HTML w odpowiedziach FAQ przed generowaniem plików PDF przez TCPDF. Atakujący z uprawnieniami do tworzenia lub edycji treści FAQ może osadzić tag <img> z atrybutem src wskazującym na lokalny plik w katalogu content/ (np. content/core/config/database.php). Podczas generowania PDF, phpMyFAQ próbuje odczytać wskazany plik; ponieważ nie jest to prawidłowy obraz, błąd jest konwertowany na nieobsłużony wyjątek, którego ślad stosu ujawnia część zawartości pliku każdemu użytkownikowi, który wywoła eksport PDF. Domyślnie ujawniona część jest skrócona, ale większa skonfigurowana wartość może prowadzić do ujawnienia całych plików, w tym danych uwierzytelniających bazy danych.

phpMyFAQ przed wersją 4.1.6 nie sprawdza ustawienia security.enableRegistration w punktach API, co pozwala atakującym na tworzenie kont użytkowników, gdy rejestracja jest wyłączona. Atakujący mogą ominąć ograniczenie rejestracji, wysyłając żądania do punktów POST /api/register lub POST /api/v3.1/register, które nie sprawdzają flagi konfiguracyjnej egzekwowanej przez stronę HTML rejestracji.