Katalog podatności CVE

Stigmem przed wersją 0.9.0a11 nie waliduje parametru delivery_address podczas tworzenia subskrypcji webhook, co pozwala uwierzytelnionym użytkownikom na określenie wewnętrznych adresów loopback i prywatnych sieci. Atakujący mogą wywołać zdarzenia zmiany faktów, aby serwer Stigmem wysyłał żądania HTTP POST do wewnętrznych usług, umożliwiając ataki SSRF na localhost i prywatne endpointy.

Renovate w wersjach od 39.53.0 do przed 40.33.0 zawiera podatność na wstrzykiwanie poleceń w menedżerze gleam, gdzie parametr depName jest dołączany do poleceń aktualizacji gleam bez odpowiedniej sanityzacji. Atakujący z prawem zapisu do repozytorium mogą stworzyć złośliwe pliki gleam.toml, aby wykonać dowolne polecenia na maszynie uruchamiającej Renovate.

Renovate w wersjach od 31.51.0 do przed 40.33.0 zawiera podatność na wstrzykiwanie poleceń w menedżerze helmv3, gdzie parametr repository jest dołączany do poleceń logowania do rejestru helm bez odpowiedniej sanityzacji. Atakujący z prawem zapisu do repozytorium mogą stworzyć złośliwe pliki Chart.yaml, aby wykonać dowolne polecenia na maszynie uruchamiającej Renovate.

Renovate w wersjach od 32.135.0 do przed 40.33.0 zawiera podatność na wstrzykiwanie poleceń w menedżerze hermit, gdzie nazwy zależności dostarczane przez użytkownika są dołączane do poleceń instalacji i deinstalacji bez odpowiedniej sanityzacji. Atakujący z prawem zapisu do repozytorium mogą dostarczyć złośliwie nazwane zależności hermit, aby wykonać dowolne polecenia na maszynie uruchamiającej Renovate.

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.

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.

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, 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.7 nie odpowiednio sanityzuje HTML w odpowiedziach FAQ przed generowaniem plików PDF przez TCPDF. Atakujący z uprawnieniem do tworzenia lub edycji treści FAQ może osadzić znacznik <img>, którego src odnosi się do lokalnego pliku w katalogu content/ w katalogu głównym web (np. content/core/config/database.php). Podczas generowania PDF, phpMyFAQ próbuje odczytać wskazany plik; ponieważ nie jest to prawidłowy obraz, wynikowy błąd jest przekształcany w 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 obcinana (zend.exception_string_param_max_len), 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.

phpMyFAQ przed wersją 4.1.7 nie sprawdza statusu aktywności w punkcie eksportu PDF, co pozwala nieuwierzytelnionym atakującym na pobieranie metadanych szkiców FAQ. Atakujący mogą uzyskać dostęp do publicznej trasy eksportu PDF z sekwencyjnymi identyfikatorami FAQ, aby uzyskać tytuły, identyfikatory rozwiązań, nazwiska autorów i znaczniki czasu ostatniej aktualizacji nieaktywnych lub nieopublikowanych FAQ.

phpMyFAQ przed wersją 4.1.6 zapisuje archiwa ZIP kopii zapasowych treści w katalogu głównym dostępnym przez sieć jako content.zip, ujawniając wrażliwe pliki, w tym dane uwierzytelniające bazy danych. Nieuwierzytelnieni atakujący mogą wykorzystać wyścig współbieżnych żądań, aby pobrać tymczasowy plik ZIP przed jego usunięciem, lub wykorzystać XSS w kontekście administratora, aby wywołać uwierzytelnione kopie zapasowe i pobrać archiwum.

phpMyFAQ przed wersją 4.1.7 zawiera podatność na ominięcie uwierzytelniania w SetupController, która pozwala nieuwierzytelnionym atakującym na uruchamianie migracji bazy danych i tworzenie kopii zapasowych konfiguracji, gdy tryb konserwacji jest włączony. Atakujący mogą wywołać punkty POST /api/setup/update-database i POST /api/setup/backup, aby wykonać aktualizacje bazy danych, wyłączyć tryb konserwacji i wyodrębnić dane uwierzytelniające bazy danych z wygenerowanych archiwów ZIP.

cgltf do wersji 1.15 zawiera podatność na przepełnienie liczby całkowitej w kontroli granic dla nie-sparse accessorów w funkcji cgltf_validate(), co pozwala zdalnym atakującym na ujawnienie pamięci i wywołanie odmowy usługi poprzez dostarczenie spreparowanych wartości liczby accessorów. Atakujący mogą dostarczyć złośliwe dane wejściowe .gltf lub .glb z odpowiednio spreparowaną liczbą accessorów, aby przepełnić mnożenie liczby całkowitej bez znaku (stride accessora * liczba elementów), co powoduje przejście kontroli granic i wywołanie odczytu poza stertą, gdy funkcja cgltf_accessor_read_float() zostanie wywołana na zwalidowanym, złośliwym accessorze.

Rozszerzenie Joomla - yootheme.com - Open redirect w CommentController::twitterAuthenticate() w Zoo < 4.1.64 - Parametr żądania referer jest przekazywany bezpośrednio do setRedirect() bez żadnej walidacji.