Katalog podatności CVE
Przetłumaczone opisy podatności z bazy NVD NIST - w języku polskim
Katalog CISA KEV zaktualizowany: (v2026.07.27)
Remnawave Backend przed wersją 2.7.5 zawiera błąd w logice rejestracji urządzeń HWID, który pozwala uwierzytelnionemu użytkownikowi ominąć skonfigurowany limit urządzeń HWID i zarejestrować więcej urządzeń niż dozwolone, umożliwiając odsprzedaż subskrypcji i nadmierne zużycie ruchu.
Kamailio przed wersjami 6.0.5 i 5.8.7 zawiera podatność na odczyt poza zakresem w module auth. Specjalnie spreparowany pakiet SIP może spowodować awarię procesu (DoS) po pomyślnym uwierzytelnieniu użytkownika bez backendu bazy danych.
LightRAG przed wersją 1.4.14 jest podatny na atak polegający na pomyleniu algorytmu JWT, gdzie atakujący może sfałszować tokeny, ustawiając 'alg': 'none' w nagłówku JWT. Funkcja jwt.decode() nie odrzuca jawnie algorytmu 'none', więc sfałszowany token bez podpisu jest akceptowany jako ważny, co prowadzi do nieautoryzowanego dostępu. Podatność została naprawiona w wersji 1.4.14.
Podatność w LiquidJS przed wersją 10.25.4, gdzie filtr sort_natural omija opcję bezpieczeństwa ownPropertyOnly. Umożliwia to autorom szablonów wyodrębnienie wartości właściwości dziedziczonych z prototypu poprzez atak kanałem bocznym sortowania.
LobeHub przed wersją 2.1.48 zawiera podatność w warstwie uwierzytelniania webapi, która ufa nagłówkowi X-lobe-chat-auth kontrolowanemu przez klienta, który jest tylko zaciemniony przez XOR, a nie podpisany lub uwierzytelniony. Ponieważ klucz XOR jest zakodowany na stałe w repozytorium, atakujący może sfałszować dowolne ładunki uwierzytelniające i ominąć uwierzytelnianie na chronionych trasach webapi, takich jak /webapi/chat/[provider], /webapi/models/[provider], /webapi/models/[provider]/pull i /webapi/create-image/comfyui.
W InvenTree przed wersjami 1.2.7 i 1.3.0 użytkownicy z uprawnieniami personelu (staff) mogą instalować wtyczki przez API, bez konieczności posiadania konta superużytkownika. Jest to niezgodne z innymi działaniami na wtyczkach (np. odinstalowywaniem), które wymagają dostępu superużytkownika.
InvenTree od wersji 1.2.3 do 1.2.6 zawiera podatność na zdalne wykonanie kodu. Mimo że walidator szablonów używa piaskownicy, renderer w part/helpers.py nadal używa niesandboxowanego środowiska, co pozwala użytkownikowi z uprawnieniami personelu na wykonanie dowolnego kodu.
Saleor, platforma e-commerce, w wersjach od 2.10.0 do przed 3.23.0a3, 3.22.47, 3.21.54 i 3.20.118, zawiera podatność w mutacji requestEmailChange(), która ujawniała istnienie adresów e-mail podanych przez użytkownika w komunikatach błędów. Podatność została naprawiona w wersjach 3.23.0a3, 3.22.47, 3.21.54 i 3.20.118.
Saleor od wersji 2.10.0 do przed 3.23.0a3, 3.22.47, 3.21.54 i 3.20.118 ma lukę w logice biznesowej i autoryzacji w przepływie zmiany adresu email. Token zmiany emaila wygenerowany dla jednego konta może być użyty podczas uwierzytelnienia jako inne konto, co prowadzi do zmiany adresu email drugiego konta na nowy adres z tokena.
W LORIS (Longitudinal Online Research and Imaging System) w wersjach od 15.10 do 27.0.3 i 28.0.1 istnieje podatność na atak XSS w module survey_accounts. Gdy użytkownik poda nieprawidłową etykietę wizyty, dane są poprawnie kodowane w JSON, ale brak nagłówka Content-Type powoduje, że przeglądarka interpretuje ładunek jako HTML, co umożliwia atak XSS po nakłonieniu użytkownika do kliknięcia w nieprawidłowy link.
W LORIS (Longitudinal Online Research and Imaging System) w wersjach od 21.0.0 do 27.0.3 i 28.0.1, backendowy endpoint dokumentów nie sprawdzał poprawnie uprawnień dostępu. Mimo że frontend ograniczał dostęp, użytkownik mógł teoretycznie pobrać plik, do którego nie powinien mieć dostępu, jeśli znał lub był w stanie odgadnąć nazwę pliku.
LORIS w wersjach od 16.1.0 do przed 27.0.3 i 28.0.1 zawiera podatność w module media. Backend nie sprawdza uprawnień dostępu do plików, co pozwala osobie nieuprawnionej na dostęp do plików, jeśli zna ich nazwę.
Zammad przed wersją 7.0.1 zawiera błąd autoryzacji w punkcie końcowym REST POST /api/v1/ai_assistance/text_tools/:id. Dane kontekstowe (np. grupa lub organizacja) dostarczone do użycia w promptcie AI nie były sprawdzane pod kątem dostępności dla bieżącego użytkownika, co prowadzi do użycia nieautoryzowanych danych w promptcie.
W Zammad, webowym systemie helpdesk, przed wersjami 7.0.1 i 6.5.4, endpoint REST POST /api/v1/ai_assistance/text_tools/:id nie sprawdzał, czy użytkownik ma uprawnienia do korzystania z narzędzia tekstowego. Umożliwiało to użycie go w każdej sytuacji, bez odpowiedniej autoryzacji.
W Zammad, webowym systemie helpdesk, przed wersjami 7.0.1 i 6.5.4, endpoint używany do tworzenia zgłoszeń (ticket creation) nie sprawdzał autoryzacji, gdy używany był parametr do dodawania linków. Umożliwiało to nieautoryzowane tworzenie zgłoszeń z linkami.
Podatność CSRF w Zammad przed wersjami 7.0.1 i 6.5.4. Punkty końcowe OAuth dla Microsoft, Google i Facebook nie walidują parametru stanu CSRF.
Podatność w mechanizmie SSO w Zammad przed wersjami 7.0.1 i 6.5.4. System nie weryfikował, czy nagłówek pochodzi z zaufanego proxy/gateway SSO przed podjęciem działań.
Zammad, webowy system helpdesk/customer support, przed wersjami 7.0.1 i 6.5.4, zawierał podatność w modelu webhooka polegającą na braku walidacji adresów loopback lub link-local. Sprawdzany był tylko schemat URL (HTTP/HTTPS) i nazwa hosta, co mogło prowadzić do ujawnienia poufnych metadanych dostawców chmury/hostingu. Poprawka rozszerza walidację zarówno przy konfiguracji webhooków, jak i przy wyzwalaniu zadań webhooka.
Zammad to webowy system helpdesk/obsługi klienta. Przed wersjami 7.0.1 i 6.5.4, sanitizer HTML dla artykułów zgłoszeń nieprawidłowo oczyszczał schematy URI data:, co pozwalało na przechowywanie złośliwej treści w bazie danych. GUI Zammad renderuje tę treść, ale dzięki regułom CSP kliknięcie w link nie powoduje szkód. Luka jest naprawiona w wersjach 7.0.1 i 6.5.4.
System Zammad przed wersją 7.0.1 umożliwia klientom w organizacjach współdzielonych (widzącym wzajemnie swoje zgłoszenia) podgląd pól nieprzeznaczonych dla klientów, w tym pól wewnętrznych (np. priorytet, atrybuty niestandardowe). Dzieje się tak, gdy klient otwiera zgłoszenie innego użytkownika z tej samej organizacji. Klienci nie mogą modyfikować tych pól.

