Katalog podatności CVE

stigmem-node przed wersją 0.9.0a12 zawiera podatność na złamanie autoryzacji na poziomie obiektu (BOLA) w punktach końcowych przeglądu kwarantanny. W środowiskach wielodostępnych z opcjonalną wtyczką stigmem-plugin-multi-tenant, zapytania list/count oraz _get_quarantined_fact w routes/quarantine.py nie zawierały predykatu tenant_id, a wyszukiwanie garden nie było ograniczone do dzierżawcy, co pozwalało administratorowi dzierżawcy z uprawnieniami zapisu na listowanie, odczyt oraz akceptowanie lub odrzucanie faktów z kwarantanny należących do innych dzierżawców przez /v1/quarantine. Domyślne wdrożenia jedno-dzierżawcze nie są dotknięte.

stigmem-node przed wersją 0.9.0a12 zawiera podatność na złamanie autoryzacji na poziomie obiektu (BOLA) w mechanizmie tombstone RTBF (prawo do bycia zapomnianym). issue_tombstone domyślnie ustawiał dzierżawcę na "default" zamiast dzierżawcy wywołującego, co pozwalało na zapis rekordów usunięcia do niewłaściwego dzierżawcy, a ścieżka tłumienia odczytu (_get_tombstone_filter i cache zakresu tombstone) nie zawierała predykatu tenant_id, więc tłumienie tombstone było stosowane bez uwzględnienia dzierżawcy w zapytaniach o fakty i odczytach pochodzenia. W rezultacie usunięcie jednego dzierżawcy mogło być przypisane do innego, a tłumienie tombstone mogło ukrywać fakty innych dzierżawców lub nie ukrywać faktów we właściwym dzierżawcy, podważając izolację danych i gwarancje RTBF. Podatność jest wykorzystywana tylko w środowiskach wielodostępnych z opcjonalną wtyczką stigmem-plugin-multi-tenant; wdrożenia jedno-dzierżawcze nie są dotknięte. Poprawiono w 0.9.0a12.

libcrux-ecdh i libcrux-ed25519 przed wersją 0.0.6 oraz libcrux-psq przed wersją 0.0.7 zawierają błędy w implementacji kryptograficznej. libcrux-ecdh nie sprawdzał poprawnie długości i klampowania podczas walidacji sekretów X25519 (oraz miał uszkodzone sprawdzanie klampowania dla importowanych kluczy sekretnych X25519); libcrux-ed25519 wykonywał podwójne klampowanie podczas generowania kluczy; a libcrux-psq panikował zamiast propagować błąd AEADError. Błędy naprawiono w odpowiednich wersjach.

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.

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.