Katalog podatności CVE

Klever-Go w wersjach 1.7.14 do 1.7.17 jest podatny na zdalnie wyzwalany atak DoS przez nieograniczone tworzenie gorutyn. Obsługa bezpośrednich wiadomości tworzy nową gorutynę dla każdej wiadomości przed sprawdzeniem antiflood, co pozwala pojedynczemu peerowi na wysłanie strumienia wiadomości i przeciążenie węzła.

Klever-Go w wersjach 1.7.14 do 1.7.17 jest podatny na panikę z powodu nil-wskaźnika wywołaną przez transakcję protobuf z pominiętym polem RawData. Brak sprawdzenia nil przed dereferencją tx.RawData.Version w txVersionChecker.CheckTxVersion powoduje crash całego procesu węzła, co może doprowadzić do zatrzymania łańcucha.

Kakoune, edytor kodu, przed wersją 2026.05.21 zawiera domyślnie włączony skrypt autorestore.kak, który może być wykorzystany przez złośliwe pliki kopii zapasowych do wykonania dowolnych poleceń kakoune i powłoki po prostu przez otwarcie pliku.

lakeFS, narzędzie open-source do zarządzania obiektowym storage, przed wersją 1.81.1 (open source) i 1.84.0 (enterprise) renderuje pliki Markdown z obiektów repozytorium bez sanityzacji HTML. Użytkownik z prawem zapisu może umieścić złośliwy plik .md z dowolnym HTML/JavaScript, który wykona się w sesji innego użytkownika.

Klever-Go przed wersją 1.7.18 jest podatny na amplifikację tablicy skrótów w logice obsługi żądań P2P resolvera. Małe skompresowane żądanie (442 bajty) może rozwinąć się do 200 000 wpisów skrótów, powodując zdalną amplifikację pamięci i CPU.

Klever-Go przed wersją 1.7.20 ma podatność w weryfikacji podpisu nagłówka, gdzie nieużywane bity dopełnienia PubKeysBitmap są liczone do kworum dwóch trzecich walidatorów. Złośliwy producent bloków może ustawić te bity, aby osiągnąć wymagane kworum bez prawdziwej liczby podpisów, osłabiając bezpieczeństwo konsensusu.

PraisonAI Platform API przed wersją 0.1.4 ma dwie luki autoryzacyjne, które razem łamią izolację przestrzeni roboczych. Warstwa usług wykonuje globalne wyszukiwania po kluczu głównym bez sprawdzania własności przestrzeni roboczej, a endpointy zarządzania członkami wymagają tylko roli 'member', co pozwala każdemu członkowi na awans do właściciela i usunięcie oryginalnego właściciela.

OpenBao przed wersją 2.5.4 ma podatność w przestrzeniach nazw, gdzie najemca, który celowo ujawni identyfikatory dzierżaw, może mieć swoją dzierżawę i poświadczenia odwołane lub odnowione przez użytkownika z innej przestrzeni nazw za pomocą nieudokumentowanych endpointów sys/revoke i sys/renew.

Przed wersją 2026.5.0 aplikacja towarzysząca Home Assistant dla systemu iOS traktuje linki tagów (NFC lub QR) dostarczane przez mechanizm routingu systemowego, takie jak uniwersalne linki iOS, tak jakby zostały fizycznie zeskanowane, bez weryfikacji aplikacji wywołującej lub monitowania użytkownika. W rezultacie każda niezaufana aplikacja na urządzeniu może przekazać dowolny tag do Home Assistant, powodując wykonanie powiązanej automatyzacji, jakby to uprawniony użytkownik zeskanował autoryzowany tag. Umożliwia to ciche, bezobsługowe wykonywanie automatyzacji przez niezaufanych lokalnych wywołujących. Problem został naprawiony w wersji 2026.5.0.

Przed wersją 2026.5.3 aplikacja towarzysząca Home Assistant traktuje linki tagów (NFC lub QR) dostarczane przez mechanizm routingu systemowego tak, jakby zostały fizycznie zeskanowane, bez weryfikacji aplikacji wywołującej lub monitowania użytkownika. W rezultacie każda niezaufana aplikacja na urządzeniu może przekazać dowolny tag do Home Assistant, powodując wykonanie powiązanej automatyzacji, jakby to uprawniony użytkownik zeskanował autoryzowany tag. Umożliwia to ciche, bezobsługowe wykonywanie automatyzacji przez niezaufanych lokalnych wywołujących. Problem został naprawiony w wersji 2026.8.1.

Przed wersją 2.0.0 Pathling Server operacja `$import-pnp` akceptuje dostarczony przez wywołującego `exportUrl` i używa go jako zdalnego punktu końcowego FHIR Bulk Export bez ograniczania go do zaufanego źródła. Gdy skonfigurowane są poświadczenia PNP, Pathling buduje uwierzytelniony klient eksportu masowego kierujący się na host wybrany przez wywołującego, pobiera pliki wybrane z manifestu, a następnie reklasyfikuje te pliki jako zaufane lokalne importy `file://` - omijając listę dozwolonych `allowableSources`, która chroni zwykłą operację `$import`. Problem został naprawiony w Pathling Server 2.0.0. Obejściem jest wyłączenie operacji `$import-pnp` (`pathling.operations.importPnpEnabled=false`) lub niekonfigurowanie poświadczeń PNP.

Przed wersją 2.0.0 Pathling Server, typowana powierzchnia CRUD/wyszukiwania/wsadowa FHIR pozwala uwierzytelnionemu wywołującemu z tylko ogólnymi uprawnieniami operacyjnymi na działanie na wybranych przez atakującego rodzinach zasobów, ponieważ te punkty wejścia nie egzekwują spójnie udokumentowanych uprawnień `read` i `write` dla poszczególnych zasobów. Udokumentowany model autoryzacji wymaga, aby uprawnienie operacyjne (np. `pathling:search`) było sparowane z odpowiednim uprawnieniem `read` lub `write` dla zasobu (np. `pathling:read:Patient`). Usuwanie i operacje wsadowe są udokumentowane jako wymagające uprawnienia zapisu dla wszystkich typów zasobów. Jednak typowane wyszukiwanie, aktualizacja i powiązane procedury obsługi są oznaczone tylko adnotacją `@OperationAccess(...)` i działają na typie zasobu wybranym przez dostawcę bez sprawdzania odpowiedniego uprawnienia dla zasobu. Problem został naprawiony w Pathling Server 2.0.0.

Przed wersją 2.0.0 Pathling Server, typowana powierzchnia CRUD/wyszukiwania/wsadowa FHIR pozwala uwierzytelnionemu wywołującemu z tylko ogólnymi uprawnieniami operacyjnymi na działanie na wybranych przez atakującego rodzinach zasobów, ponieważ te punkty wejścia nie egzekwują spójnie udokumentowanych uprawnień `read` i `write` dla poszczególnych zasobów. Udokumentowany model autoryzacji wymaga, aby uprawnienie operacyjne (np. `pathling:search`) było sparowane z odpowiednim uprawnieniem `read` lub `write` dla zasobu (np. `pathling:read:Patient`). Usuwanie i operacje wsadowe są udokumentowane jako wymagające uprawnienia zapisu dla wszystkich typów zasobów. Jednak typowane wyszukiwanie, aktualizacja i powiązane procedury obsługi są oznaczone tylko adnotacją `@OperationAccess(...)` i działają na typie zasobu wybranym przez dostawcę bez sprawdzania odpowiedniego uprawnienia dla zasobu. Problem został naprawiony w Pathling Server 2.0.0.

gopacket zapewnia możliwości przetwarzania pakietów dla języka Go. Do wersji 1.7.0 włącznie, wiele dekoderów warstw używa długości, liczników lub przesunięć kontrolowanych przez atakującego przed ich walidacją względem buforów pakietów, co pozwala spreparowanemu pakietowi zdekodowanemu przez DecodingLayerParser lub DecodeFromBytes na wywołanie nieodwracalnego paniki i zdalną odmowę usługi. Dostępny jest commit z poprawką pod adresem 210f25f.

Przed wersją 6.9.11 w HAPI FHIR, plik XhtmlParser.java nie narzuca maksymalnej głębokości zagnieżdżenia elementów, więc głęboko zagnieżdżona narracja text.div wywołuje nieograniczoną rekurencję między parseElementInner() i parseElement(), powodując StackOverflowError. Atakujący, który może przesłać zasoby FHIR zawierające takie narracje, może w ten sposób doprowadzić do awarii wątku roboczego parsowania lub walidacji, wpływając na usługi walidatora i każdą aplikację parsującą dostarczone przez atakującego FHIR JSON lub XML. Problem został naprawiony w wersji 6.9.11.

Przed wersją 6.9.11 w HAPI FHIR, parser JSON w org.hl7.fhir.utilities.json.parser.JsonParser nie egzekwuje maksymalnej głębokości zagnieżdżenia dla tablic lub obiektów. W rezultacie mały, ale głęboko zagnieżdżony, składniowo poprawny dokument FHIR JSON może wywołać nieograniczoną rekurencję readArray() lub readObject(), powodując StackOverflowError przed uruchomieniem walidacji strukturalnej. Atakujący, który może przesłać zasoby JSON do walidacji, może w ten sposób doprowadzić do awarii wątku żądania, a usługi, które nie izolują bezpiecznie StackOverflowError, mogą doświadczyć utraty pracowników lub niestabilności procesu — stan odmowy usługi. Problem został naprawiony w wersji 6.9.11.

Element Call w wersjach od 0.5.17 do 0.19.3 raportuje dane analityczne do serwera PostHog, gdy jest to skonfigurowane przez klucz `posthog` w config.json lub parametry URL `posthogApiHost` i `posthogApiKey`. Kilka pól tych danych (`$initial_person_info`, `$session_entry_url`, `$current_url`) zawiera pełny URL odwiedzonej strony, w tym fragment. Użytkownicy samodzielnej instancji SPA, takiej jak https://call.element.io, mogli zgłosić pełne URL-e niektórych połączeń, w tym hasła szyfrowania, do skonfigurowanego serwera PostHog.

Przed wersją 2.0.0 Pathling Server, punkt końcowy `/$result` pozwala wywołującemu, który może uzyskać dowolny ważny identyfikator zadania eksportu asynchronicznego, na podanie wartości parametru `file` zawierających sekwencje przejścia ścieżki. Procedura obsługi weryfikuje tylko dostarczone `job` i nigdy nie normalizuje ani nie ogranicza żądanej ścieżki `file` do katalogu `jobs/<jobId>` tego zadania przed otwarciem jej jako zasobu systemu plików. Ponieważ przestrzeń robocza eksportu asynchronicznego znajduje się w tym samym katalogu głównym bazy danych magazynu, co utrwalone tabele zasobów, atakujący może użyć własnego zadania eksportu do odczytu innych plików z magazynu. Problem został naprawiony w Pathling Server 2.0.0. Jako tymczasowe złagodzenie, wyłącz operacje eksportu asynchronicznego (`pathling.operations.exportEnabled`, `patientExportEnabled`, `groupExportEnabled`, `bulkSubmitEnabled`) lub włącz uwierzytelnianie i ogranicz możliwość eksportu do zaufanych wywołujących.

Pathling Server przed wersją 2.0.0 umożliwia uprawnionemu użytkownikowi podanie parametru `oauthMetadataUrl` bez weryfikacji względem listy dozwolonych źródeł. W rezultacie przepływ OAuth dla operacji bulk-submit ufa niezaufanemu punktowi końcowemu tokenu i używa zapisanych poświadczeń do uwierzytelnienia.

Pathling Server przed wersją 2.0.0 ma podatność na path traversal w punkcie końcowym `/$result`. Osoba znająca identyfikator zadania eksportu może podać ścieżkę pliku zawierającą sekwencje `../`, co pozwala na odczyt plików spoza katalogu zadania, w tym danych z magazynu.