Katalog podatności CVE

Wtyczka Xpro Addons — 140+ Widgetów dla Elementora w WordPressie jest podatna na przechowywane ataki Cross-Site Scripting (XSS) poprzez parametr 'custom_attributes' we wszystkich wersjach do 1.7.2 włącznie, z powodu niewystarczającej sanitizacji wejścia i ucieczki wyjścia.

Brakujący krok kryptograficzny w oprogramowaniu układowym Caliptra Core prowadzi do nieprawidłowego tagu uwierzytelniającego GCM. Użycie API AES-256-GCM ze pustym AAD skutkuje tym, że stan akumulatora GHASH nie jest zapisywany po pierwszym wywołaniu aktualizacji, co powoduje, że końcowy tag nie uwzględnia pierwszej partii przetworzonego szyfrogramu.

W systemie Snipe-IT w wersjach przed 8.6.0 użytkownik z uprawnieniem users.edit może wysłać żądanie PATCH do /api/v1/users/{swoje_id} i nadać sobie dowolne uprawnienia (oprócz admin i superuser), np. assets.view, assets.create, reports.view czy import. Problem został naprawiony w wersji 8.6.0.

Poweradmin przed wersjami 4.2.4 i 4.3.3 jest podatny na wstrzykiwanie formuł CSV w funkcji eksportu logów. Nazwa użytkownika, która może być kontrolowana przez atakującego, jest zapisywana do plików CSV bez oczyszczania znaków wyzwalających formuły (=, +, -, @).

Podatność w Fortra File Integrity Monitoring (dawniej Tripwire Enterprise) przed wersją 9.4.0 może powodować przypisanie nieprawidłowych lub podwyższonych uprawnień użytkownikom utworzonym za pomocą polecenia tetool import podczas działania FIM, szczególnie gdy import tworzy lub zmienia role lub relacje rola-uprawnienie.

W systemie Fortra File Integrity Monitoring (FIM), dawniej Tripwire Enterprise, w wersjach przed 9.4.0.1 wykryto podatność na trwały atak XSS w komponencie Asset View UI. Uwierzytelniony użytkownik z odpowiednimi uprawnieniami może przechowywać złośliwy skrypt w polach konfiguracyjnych węzłów lub baz danych, który zostanie wykonany w przeglądarce innego administratora.

Podatność w jackson-databind dotyczy mechanizmu rozpakowywania właściwości (unwrapped properties) w konstruktorach. Metoda UnwrappedPropertyHandler.processUnwrappedCreatorProperties() nie sprawdza widoczności adnotacji @JsonView, co pozwala na ominięcie ograniczeń widoku i wstrzyknięcie danych z JSON do parametru konstruktora oznaczonego zarówno @JsonView, jak i @JsonUnwrapped, nawet gdy aktywny jest bardziej restrykcyjny widok.

W komponencie foreman-mcp-server wykryto wadę polegającą na używaniu dwóch mechanizmów logowania, które mogą ujawniać wrażliwe dane sesji i uwierzytelniania. Jeden z nich rejestruje identyfikatory sesji traktowane jako poświadczenia uwierzytelniające na poziomie informacyjnym, a drugi, przy włączonym logowaniu debugowania, niekompletnie oczyszcza nagłówki żądań HTTP, prowadząc do logowania w czystym tekście poufnych informacji, takich jak tokeny autoryzacyjne i klucze API.

W bibliotece jackson-databind w wersjach od 2.21.0 do 2.21.4 oraz 3.1.4 występuje podatność polegająca na pominięciu filtrowania widoku (@JsonView) dla właściwości kolekcji/map bez settera. Atakujący może dostarczyć dane JSON, które zostaną przetworzone mimo że aktywny widok powinien je wykluczać.

Podatność w jackson-databind pozwala atakującemu na ominięcie adnotacji @JsonIgnore na setterze poprzez wykorzystanie @JsonProperty na getterze. W rezultacie pole prywatne klasy staje się zapisywalne podczas deserializacji, co umożliwia bezpośredni zapis danych do obiektu.

W bibliotece jackson-databind od wersji 2.8.0 do 2.18.9, 2.21.5 i 3.1.4 występuje podatność polegająca na tym, że podczas deserializacji obiektów z adnotacją @JsonIgnoreProperties, wykluczone właściwości są usuwane z mapy BeanPropertyMap, ale późniejsze przetwarzanie z uwzględnieniem wielkości liter (ACCEPT_CASE_INSENSITIVE_PROPERTIES) odtwarza oryginalną, niefiltrowaną mapę, przywracając usunięte właściwości. W rezultacie zignorowana właściwość staje się ponownie zapisywalna.

Podatność w jackson-databind od wersji 2.0.0 do 2.18.8, 2.21.4 i 3.1.4 powoduje, że podczas deserializacji obiektu InetSocketAddress następuje natychmiastowe rozwiązywanie nazw DNS dla danych wejściowych pochodzących z niezaufanego źródła. Atakujący może wymusić wykonanie zapytania DNS na wybranym przez siebie hoście jeszcze przed jakąkolwiek walidacją aplikacyjną.

NocoDB przed wersją 2026.05.1 miał podatność, która pozwalała na wykorzystanie punktu końcowego importu arkuszy kalkulacyjnych axiosRequestMake jako ogólnego proxy HTTP. Punkt ten był dostępny bez uwierzytelnienia, co umożliwiało nieautoryzowany dostęp.

NocoDB przed wersją 2026.05.1 miał podatność w punkcie końcowym migracji bazowej, który akceptował URL dostarczony przez wywołującego bez wymuszania protokołu lub miejsca docelowego. To umożliwiało nadużycie schematu oraz badanie wewnętrznych adresów HTTP.

NocoDB przed wersją 2026.05.1 pozwalał na przesyłanie załączników .html lub .svg, które były renderowane w przeglądarce zamiast wymuszać pobranie. Problem wynikał z niezgodności w sposobie obsługi nagłówków odpowiedzi, co prowadziło do automatycznego renderowania tych plików.

NocoDB przed wersją 2026.05.1 miał podatność, w której skradziony token odświeżania mógł być użyty do generowania nowych JWT nawet po zresetowaniu hasła przez użytkownika. Proces zapomnienia hasła nie usuwał wszystkich tokenów odświeżania, co umożliwiało atakującemu wymianę skradzionego tokena na nowy token dostępu.

NocoDB przed wersją 2026.05.1 miał podatność w punkcie końcowym spreadsheet-fetch (axiosRequestMake), który akceptował URL-e z dozwoloną rozszerzeniem w dowolnym miejscu w ciągu. Umożliwiało to dostęp do punktu końcowego cloud-metadata za pomocą spreparowanego URL-a.

NocoDB przed wersją 2026.05.1 zawierał lukę w usłudze użytkowników, gdzie funkcja revokeAllOAuthTokensByUser była pustym stubem. W wyniku tego, tokeny OAuth nie były unieważniane po zmianie, zresetowaniu lub odzyskaniu hasła przez użytkownika.

NocoDB przed wersją 2026.05.1 miał podatność, która pozwalała na jednoczesne wykorzystanie tego samego kodu autoryzacji OAuth do wygenerowania dwóch różnych par tokenów (access_token, refresh_token). To naruszało zasadę jednorazowego użycia, na której opiera się PKCE.

NocoDB przed wersją 2026.05.1 pozwalał uwierzytelnionym użytkownikom z uprawnieniami do tworzenia baz na dołączenie źródła SQLite wskazującego na dowolny plik na hoście NocoDB, w tym wewnętrzne bazy danych NocoDB. Użytkownicy mogli wskazać plik noco.db lub inne bazy danych, co umożliwiało odczyt lub nadpisanie ich zawartości.