Katalog podatności CVE

W Pivotal CRM w wersji 6.6.04.08 występuje problem, który pozwala zdalnemu atakującemu na wykonanie dowolnego kodu poprzez komponenty Pivotal.Core.Common.dll oraz Pivotal.Engine.Client.Services.Conversion.dll.

Podatność w bibliotece Ash umożliwia atakującemu ustawienie wartości prywatnego argumentu akcji, który powinien być kontrolowany tylko przez zaufany kod serwera. Filtrowanie prywatnych argumentów jest niekompletne zarówno w ścieżce regularnej (dla kluczy binarnych), jak i w ścieżce atomowej (w ogóle nie filtruje).

Wtyczka @rtk-ai/rtk-rewrite w wersji 1.0.0 nie zabezpiecza danych wejściowych przed interpretacją przez powłokę, co pozwala na wstrzyknięcie dowolnych poleceń systemowych. JSON.stringify() nie chroni przed metaznakami powłoki, takimi jak $() i backtick, które są wykonywane przez /bin/sh -c.

W wersjach przed 0.185.0, Daytona pozwalała na aktualizację i usuwanie ról organizacji bez weryfikacji, czy rola należy do danej organizacji. Użytkownik uwierzytelniony, będący właścicielem jakiejkolwiek organizacji, mógł zmodyfikować uprawnienia lub usunąć rolę należącą do innej organizacji, korzystając z identyfikatora tej roli.

W wersjach od 0.101.0 do 0.184.0, sandboxy, które zostały przełączone z publicznych na prywatne, mogły pozostać dostępne bez uwierzytelnienia przez krótki czas po zmianie, z powodu nieunieważnionego stanu widoczności w pamięci podręcznej.

W wersjach przed 0.184.0, użytkownicy mogli akceptować lub odrzucać zaproszenia do organizacji, nawet jeśli ich adres e-mail nie był zweryfikowany. System autoryzacji Daytona nie wymagał weryfikacji e-maila dla tych akcji, co stwarzało ryzyko nieautoryzowanego dostępu.

W wersjach przed 0.186 Daytona, referencja do woluminu sandbox (volumeId) była przekazywana do runnera, co mogło prowadzić do nieautoryzowanego dostępu do ścieżek poza zamierzonym katalogiem bazowym. Wykorzystanie sekwencji przechodzenia przez ścieżki mogło umożliwić zbudowanie ścieżki montowania hosta bez odpowiednich ograniczeń.

Crawl4AI przed wersją 0.8.9 zawiera podatność SSRF, która pozwala nieuwierzytelnionemu atakującemu na ominięcie sprawdzania docelowego adresu URL i skierowanie ruchu przez proxy na wewnętrzne adresy IP. Atakujący może wykorzystać tę lukę do uzyskania dostępu do wewnętrznych usług i punktów końcowych metadanych chmury, podając prawidłowy adres URL do przeszukania.

Crawl4AI przed wersją 0.8.8 zawiera podatność SSRF w serwerze API Docker, która pozwala atakującemu ominąć blokadę CIDR i uzyskać dostęp do wewnętrznych usług oraz endpointów metadanych chmury (np. 169.254.169.254) poprzez kodowanie adresu IPv4 w formie przejściowej IPv6 lub użycie adresu nieokreślonego IPv6. Ponieważ API Docker jest domyślnie nieuwierzytelnione, atak nie wymaga żadnych poświadczeń.

Crawl4AI przed wersją 0.8.7 zawiera podatność w funkcji _safe_eval_expression() w mechanizmie computed fields. Walidator AST blokuje tylko atrybuty zaczynające się od podkreślenia, ale atrybuty obiektów generatora i ramki (gi_frame, f_back, f_builtins) nie zaczynają się od podkreślenia, co umożliwia całkowitą ucieczkę z sandboksa i wykonanie dowolnego kodu. Atak nie wymaga uwierzytelnienia (JWT domyślnie wyłączone) i jest wyzwalany przez POST /crawl z spreparowanym schematem ekstrakcji.

Podatność w parserze CMS w narzędziu gpgsm pakietu GnuPG (do wersji 2.5.20) nieprawidłowo obsługuje format CMS dla szyfrowania AES-GCM. Pole aes-ICVlen powinno mieć długość 12 bajtów, ale akceptowana jest również wartość 4 bajtów, co może prowadzić do błędów w weryfikacji integralności danych.

Biblioteka GNU libidn przed wersją 1.44 zawiera podatność na odczyty poza dozwolonym zakresem z niezainicjalizowanej pamięci w interfejsach API ToUnicode, spowodowaną błędnym przetwarzaniem w funkcji idna_to_unicode_internal. Kod podatności nie występuje w libidn2.

Podatność w Deno przed wersją 2.7.5 umożliwia zdalnemu serwerowi WebSocket spowodowanie awarii procesu Deno poprzez wysłanie odpowiedzi z nagłówkami Sec-WebSocket-Protocol lub Sec-WebSocket-Extensions zawierającymi nie-drukowalne znaki ASCII (0x80-0xFF). Błąd wynika z nieprawidłowego parsowania tych nagłówków, co prowadzi do paniki i zatrzymania całego procesu.

W Daytona, przed wersją 0.185.0, występowała luka w autoryzacji między najemcami w bramie WebSocket powiadomień, która pozwalała uwierzytelnionym użytkownikom na subskrypcję kanałów powiadomień w czasie rzeczywistym innej organizacji.

W wersjach przed 0.185.0, implementacja polecenia git clone w daemonie Daytona wyłączała weryfikację certyfikatów TLS. To umożliwiało atakującym przechwycenie ruchu i kradzież poświadczeń Git.

Home Assistant przed wersją 2026.5.3 zawiera podatność w komponencie LocationSensorManager, gdzie BroadcastReceiver jest eksportowany bez wymaganych uprawnień. Każda zainstalowana aplikacja, nawet bez uprawnień w czasie wykonania, może wysłać sfałszowany obiekt LocationResult z Google Play Services, który jest akceptowany i przekazywany do serwera Home Assistant jako rzeczywista lokalizacja urządzenia.

W Home Assistant przed wersją 2026.6.0, integracja Konnected udostępnia endpoint HTTP, który dla żądań GET nie wymaga uwierzytelnienia, mimo że deklaracja w kodzie sugeruje inaczej. Żądania zapisu (POST/PUT) są chronione tokenem, ale odczyt (GET) jest całkowicie niechroniony.

Podatność w narzędziu Claude Code (wersje od 0.2.54 do 2.1.163) polega na automatycznym zatwierdzaniu żądań WebFetch do domeny huggingface.co bez monitu o zgodę lub ograniczeń --allowedTools. Atakujący może wykorzystać to do wysyłania żądań do kontrolowanych przez siebie repozytoriów, co umożliwia utworzenie ukrytego kanału do eksfiltracji danych.

W wersjach od 42.3.1 do 42.3.3 framework Electron ma problem z nieprawidłowym obliczaniem długości bajtów w Buffer, co prowadzi do przepełnienia lub niedopełnienia bufora w pamięci. Większość aplikacji ulega awarii, a niektóre mogą wykonywać nieprawidłowe alokacje bufora w API Node.js, co skutkuje nieoczekiwanym skracaniem lub alokacją.

LobeHub przed wersją 2.1.57 miał podatność w punkcie końcowym /webapi/proxy, który akceptował URL w ciele POST bez autoryzacji. Atakujący mógł wykorzystać to do wykonywania dowolnych żądań wychodzących z infrastruktury LobeHub oraz do wycieku szczegółów wdrożenia Vercel.