Katalog podatności CVE

Akcja app/process-api-response-headers przyjmuje fałszywe nagłówki odpowiedzi API Craft od każdego uwierzytelnionego użytkownika panelu; użytkownik z uprawnieniem accessCp może wstawić znaki nowej linii do X-Craft-Plugin-Licenses, co pozwala wstrzyknąć nowy znany atakującemu CRAFT_SECURITY_KEY do .env i sfałszować podpisany redirect z wywołaniem system() w Twig.

Serialize JavaScript serializuje wartości JavaScript do nadzbioru JSON obejmującego wyrażenia regularne i funkcje. Przed wersją 7.1.3 logika ucieczki źródła funkcji nie neutralizuje samego prefiksu zamykającego skrypt, gdy tekst źródłowy funkcji pod wpływem atakującego kończy się dokładnie na tym prefiksie. Ponieważ każde ciało funkcji jest ucieczkowane niezależnie, ogranicznik dostarczony przez otaczające dane wyjściowe serializacji może zakończyć element skryptu HTML, a późniejsza serializowana wartość dostarcza wstrzyknięty znacznik, który staje się aktywnym elementem na stronie. Wykorzystanie wymaga kontroli nad tekstem źródłowym serializowanej funkcji, np. poprzez podszycie się pod toString().

Happy DOM od wersji 17.0.0 do 21.0.4 w ECMAScriptModuleCompiler.ts przyjmuje alias importu ESM bez walidacji, że jest poprawnym identyfikatorem wiązania JS; przy włączonym enableJavaScriptEvaluation złośliwy HTML lub źródło modułu może spowodować wykonanie wygenerowanego JavaScriptu w procesie hosta Node.js.

Wasmtime przed wersjami 36.0.19, 48.0.7 i 49.0.4 posiada błąd w kompilatorze Cranelift na architekturze aarch64. Instrukcja br_table z ponad 256 000 celów może zostać błędnie skompilowana, umożliwiając skok do dowolnego kodu i ucieczkę z sandboxa.

Wasmtime od wersji 46.0.0 do 48.0.7 i 49.0.4 przy obniżaniu utworzonego przez hosta strumienia lub future modelu komponentów do gościa może pominąć wymaganą kontrolę typu ładunku po przejściu wartości przez kod gościa i powrocie przez StreamAny, FutureAny, Val::Stream, Val::Future lub równoważny czytnik typowany; złośliwy gość może spowodować panikę hosta Wasmtime.

Wasmtime przed wersjami 36.0.19 i 43.0.0 ma błąd w kompilatorze Cranelift polegający na cichym przepełnieniu indeksów SSA przy kompilacji dużych funkcji Wasm. Może to prowadzić do błędnej kompilacji, pomieszania typów i ucieczki z sandboxa.

GraphQL Scalars od wersji 1.24.1 do 2.0.1 w GraphQLPhoneNumber używa niejednoznacznych zagnieżdżonych kwantyfikatorów cyfr, które powodują wykładniczy backtracking przy wartościach z ciągiem cyfr i znakiem powodującym niepowodzenie dopasowania; parseLiteral i parseValue są oceniane przed uwierzytelnieniem, więc małe nieuwierzytelnione żądanie może zablokować pętlę zdarzeń Node.js.

MLflow od wersji 3.12.0rc0 do 3.17.0 w endpointach scorer invoke, register i GenAI evaluate (w tym nieuwierzytelniony POST /ajax-api/3.0/mlflow/scorer/invoke) przyjmuje serializowane dane zewnętrznych scorerów, które Scorer.model_validate_json rozwiązuje za pomocą listy dozwolonych ścieżek modułów bez ograniczenia wybranej klasy lub argumentów konstruktora; przy zainstalowanych trulens i trulens-providers-litellm atakujący może wymusić żądanie wychodzące do wybranego hosta z kontrolowanymi nagłówkami i treścią.

W LangGraph CLI w wersjach od 0.4.15 do 0.4.32 polecenie 'langgraph deploy --verbose' przekazuje tymczasowy token rejestru na standardowe wejście do 'docker login --password-stdin', ale pomocnik podprocesu CLI wypisuje dane wejściowe w trybie verbose. Każdy, kto może odczytać logi CI lub nagrania terminala przed wygaśnięciem tokenu (maksymalnie 12 godzin), może pobierać obrazy wdrożenia lub wypychać obrazy do repozytorium obrazów tego wdrożenia. Wdrożenia bez --verbose i zdalne budowanie obrazów nie są dotknięte, a sam token nie pozwala zaktualizować wdrożenia w celu uruchomienia wypchniętego obrazu.

LangGraph checkpoint savers zapewniają trwałość stanu opartą na Postgres i SQLite dla przepływów pracy i agentów LangGraph. Przed wersjami langgraph-checkpoint-postgres 3.1.3 i langgraph-checkpoint-sqlite 3.1.2 klasy PostgresStore, AsyncPostgresStore, SqliteStore i AsyncSqliteStore spłaszczają etykiety przestrzeni nazw za pomocą '.'.join(namespace), podczas gdy BaseStore waliduje etykiety tylko dla put i aput. Niezwalidowane etykiety z kropkami przekazane przez get, search, delete, list_namespaces, ich asynchroniczne odpowiedniki lub bezpośrednie operacje batch i abatch mogą wskazywać na przestrzeń nazw przechowywaną przez innego dzierżawcę, umożliwiając odczyt, nadpisanie lub usunięcie między przestrzeniami nazw. InMemoryStore nie jest dotknięty, ponieważ porównuje krotki przestrzeni nazw.

W Kakao khaiii do wersji 0.4 wykryto lukę w funkcji khaiii::nn::Linear::open w pliku src/main/cpp/khaiii/nn/Linear.cpp, w komponencie obsługi pliku konfiguracyjnego JSON. Manipulacja argumentami hidden_dim/class_num prowadzi do odczytu poza granicami. Atak wymaga lokalnego dostępu, a exploit został publicznie ujawniony. Producent wyjaśnia, że khaiii traktuje katalog zasobów (--rsc-dir) jako zaufane dane wejściowe, więc atakujący musi już mieć możliwość zapisu do tego katalogu. Luka dotyczy tylko produktów, które nie są już wspierane przez opiekuna.

W bibliotece Twisted, w wersjach przed 26.10.0rc1, protokół DNSDatagramProtocol akceptuje odpowiedź UDP DNS na oczekujące zapytanie, jeśli zgadza się 16-bitowy identyfikator transakcji, ale nie weryfikuje źródłowego adresu IP i portu. Umożliwia to atakującemu wstrzyknięcie sfałszowanej odpowiedzi DNS.

W OpenReception w wersjach 2.1.0 i starszych nieuwierzytelniony atakujący może zapisać dowolny klucz publiczny ML-KEM-768 pod tożsamością dowolnego istniejącego użytkownika w katalogu odbiorców staff-crypto dowolnego tenanta. Projekt gwarantuje, że dane spotkań są szyfrowane end-to-end do pracowników, a katalog odbiorców nie jest zapisywalny przez atakującego, więc nawet administratorzy i operator nie mogą czytać danych pacjentów. Ten endpoint łamie tę gwarancję dla nieuwierzytelnionego zdalnego aktora: pozwala zapisać dowolnego odbiorcę szyfrowania do katalogu odbiorców dowolnego tenanta. Wstrzyknięty klucz otrzymuje klucz tunelu każdego spotkania zarezerwowanego później w tym tenancie, ponieważ klienci rezerwacji szyfrują do wszystkich aktywnych kluczy pracowników. Atakujący posiada odpowiadający klucz tajny i jest trwałym, nieautoryzowanym odbiorcą tego materiału kluczowego. W momencie publikacji brak publicznie dostępnych poprawek.

W OpenReception przed wersją 2.2.2 atakujący może przepełnić rezerwacje agenta, umieszczając wiele spotkań w jednym przedziale czasowym, który system ma utrzymywać jako wyłączny. Liczba nakładających się spotkań równa się liczbie równoczesnych żądań, a jeden token rezerwacji wystarczy, ponieważ token jest zużywany po wstawieniu. Powoduje to naruszenie integralności kalendarza rezerwacji i odmowę dostępności innym klientom. Problem naprawiono w wersji 2.2.2.

W OpenReception w wersjach 2.1.0 i starszych sześciocyfrowy PIN rezerwacji powracającego klienta można zgadnąć metodą brute-force online w obrębie tenanta ofiary. Udane zgadnięcie daje token dostępu do rezerwacji klienta, a tym samym dostęp do jego tunelu spotkań z danymi szyfrowanymi end-to-end oraz możliwość działania w imieniu klienta, np. dodawania lub anulowania spotkań. Obejście ma charakter międzytenantowy — stan jednego tenanta usuwa zabezpieczenie uwierzytelniania innego tenanta. W momencie publikacji brak publicznie dostępnych poprawek.

W OpenReception przed wersją 2.2.1 atakujący, który przechwyci oczekujący token zaproszenia, może go odtworzyć, aby uzyskać poświadczenie rejestracji passkey i zarejestrować własny passkey na zaproszonym koncie, przejmując nad nim kontrolę. Dla zaproszenia pracownika lub administratora tenanta daje to dostęp do kontekstu tenanta powiązanego z tym kontem. Problem naprawiono w wersji 2.2.1.

W OpenReception przed wersją 2.0.0 link potwierdzający konto w e-mailach jest budowany z nagłówka Host żądania bez listy dozwolonych. Nieuwierzytelniony POST /api/auth/resend-confirmation rotuje token potwierdzenia oczekującego zaproszonego i wysyła e-mail z linkiem, którego host pochodzi z żądania. Atakujący wysyłając jedno żądanie z Host: attacker.example i adresem e-mail oczekującego zaproszonego powoduje, że ofiara otrzymuje e-mail, którego jedyny link prowadzi do atakującego; po kliknięciu jednorazowy token trafia do atakującego, który potwierdza konto na prawdziwej domenie tenanta i rejestruje własny passkey, przejmując konto. Wszystkie wydane wersje do v1.1.0 są podatne; brak poprawki. Osiągnięcie aplikacji ze sfałszowanym Host zależy od frontowego proxy: domyślny Caddy catch-all przekazuje go, a operator z jawnymi blokami proxy per tenant nie jest podatny. Problem naprawiono w wersji 2.0.0.

To CVE zostało odrzucone lub wycofane przez organizację numerującą CVE. Brak dostępnych szczegółów technicznych dotyczących podatności.

W Twisted przed wersją 26.10.0rc1 metoda twisted.web.http.HTTPChannel.headerReceived odrzuca bajt NUL w wartości nagłówka HTTP, ale akceptuje samotny znak powrotu karetki lub samotny znak nowej linii. Ponieważ Twisted dzieli linie nagłówków tylko na CRLF, ukryty nagłówek Content-Length może pozostać wklejony w inną wartość, podczas gdy łagodny front end traktuje samotny znak jako terminator linii. Wynikająca z tego rozbieżność ramkowania może przemycić kolejne żądanie poza kontrolą dostępu front endu, zatruć współdzielone połączenie lub pamięć podręczną i narazić późniejszego klienta na niewłaściwą odpowiedź. Problem jest pozostałością niepełnej naprawy wcześniejszych zabezpieczeń Twisted przed przemytem żądań. Problem naprawiono w wersji 26.10.0rc1.

W UbiquitousLearning mllm do wersji 2.0.2 zidentyfikowano podatność w funkcji load_model w pliku pymllm/mobile/convertor/__init__.py komponentu Convertor. Manipulacja argumentem shard_file prowadzi do path traversal. Atak wymaga wykonania lokalnego. Exploit jest publicznie dostępny i może być użyty. Projekt został poinformowany o problemie wczesnym zgłoszeniem, ale jeszcze nie odpowiedział.