Katalog podatności CVE

stigmem-node 0.9.0a1 interpoluje identyfikatory schematów backendu Postgres do zapytań SQL bez odpowiedniego cytowania. W dotkniętej ścieżce kodu wartość schematu jest kontrolowana przez operatora, ale niebezpieczny wzorzec może umożliwić wstrzyknięcie SQL, jeśli nazwa schematu pochodzi z danych dzierżawcy, żądania lub użytkownika. Poprawiono w 0.9.0a2.

stigmem przed wersją 0.9.0a12 zawiera podatność na złamanie autoryzacji na poziomie obiektu w punkcie końcowym decay sweep, która pozwala uwierzytelnionym atakującym z poświadczeniami zapisu dla jednego dzierżawcy na wykonywanie operacji decay wpływających na wszystkich dzierżawców. Atakujący mogą wysyłać żądania POST z ttl_seconds=0, aby wygaszać fakty we wszystkich dzierżawcach, lub użyć dry_run do uzyskania informacji o faktach i ich istnieniu między dzierżawcami.

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.

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.

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 (dotknięte wersje <= 4.1.5) nie zapisuje wyzwania logowania WebAuthn wygenerowanego przez prepareForLogin, ponieważ żaden kontroler WebAuthn nie zapisuje zmutowanych obiektów kluczy z powrotem do bazy danych. Przy logowaniu porównanie anty-replay jest pomijane przez własną ochronę null, co pozwala atakującemu, który przechwyci udane potwierdzenie WebAuthn, na odtwarzanie go w nieskończoność i uwierzytelnianie jako użytkownik bez żadnej interakcji lub klucza sprzętowego.

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 w wersjach 3.1.0 do 4.1.6 zawiera podatność obejścia uwierzytelniania w funkcji AuthLdap::create(). Gdy uwierzytelnianie LDAP jest włączone, po pomyślnym wiązaniu LDAP kod wywołuje User::setStatus('active') bezwarunkowo, co nadpisuje kolumnę account_status istniejącego lokalnego konta z 'blocked' na 'active'. W rezultacie użytkownik, którego lokalne konto phpMyFAQ zostało administracyjnie zablokowane, może przywrócić swoje konto i zalogować się, uwierzytelniając się przez LDAP. Zmiana stanu nie jest logowana, więc administratorzy nie mogą wykryć, że blokada została nadpisana. Poprawiono w wersji 4.1.7.

phpMyFAQ przed wersją 4.1.7 zawiera podatność obejścia uwierzytelniania dwuskładnikowego, gdzie tokeny remember-me są wydawane przed zakończeniem weryfikacji 2FA. Atakujący z ważnymi poświadczeniami może uzyskać ciasteczko remember-me, pominąć wyzwanie 2FA i odtworzyć ciasteczko, aby uzyskać pełny uwierzytelniony dostęp bez weryfikacji drugiego czynnika.

phpMyFAQ przed wersją 4.1.7 zawiera podatność wstrzykiwania SQL w punktach końcowych tworzenia i aktualizacji glosariusza, spowodowaną obcinaniem escapowanego ciągu przed osadzeniem go w literale SQL. Uwierzytelnieni użytkownicy z uprawnieniami dodawania lub edycji glosariusza mogą stworzyć ładunek z wiszącym backslashem, aby uciec z zamykającego cudzysłowu i wstrzyknąć dowolne polecenia SQL w celu odczytania wrażliwych informacji z bazy danych.

phpMyFAQ przed wersją 4.1.7 przechowuje tokeny resetowania hasła w publicznie dostępnym pliku śledzenia, gdy włączone jest śledzenie użytkowników. Nieuwierzytelnieni atakujący mogą odczytać plik śledzenia w ścieżce content/core/data/trackingDDMMYYYY, aby wyodrębnić tokeny resetowania i odtworzyć je przeciwko API resetowania hasła, przejmując konta użytkowników.