Katalog podatności CVE
Przetłumaczone opisy podatności z bazy NVD NIST - w języku polskim
Przeglądaj podatności według pakietuKatalog CISA KEV zaktualizowany: (v2026.11.04)
Cotygodniowy digest CVE
Jeden mail w tygodniu z nowo opublikowanymi podatnościami, o których warto wiedzieć. Bez zakładania konta.
Digest dotyczy ogólnie nowych podatności, nie Twoich serwerów. Jeśli chcesz wiedzieć, które z nich faktycznie działają w Twojej infrastrukturze, tym zajmuje się Secvalis : skanuje Twoje maszyny i zgłasza wyłącznie to, co ich dotyczy.
Nodemailer przed wersją 9.1.0 nie stosuje normalizacji UTS-46 przy kodowaniu międzynarodowych nazw domen, przez co resolver domen oblicza inny A-label Punycode niż parsery zgodne ze standardem. Atakujący może tworzyć adresy odbiorców z niewidocznymi znakami lub mapowaniami zgodności, które przechodzą kontrolę listy dozwolonych domen, ale są dostarczane do domen kontrolowanych przez atakującego przez SMTP.
Nodemailer w wersjach od 6.9.16 do 9.1.0 błędnie parsuje komentarze RFC 5322 w adresach e-mail. Komentarz zamknięty bezpośrednio przed znakiem niebędącym białym znakiem powoduje sklejenie atomów wokół komentarza, przez co adres taki jak [email protected](x)evil.com jest interpretowany jako domena good-corp.comevil.com. Może to prowadzić do dostarczenia wiadomości do domeny kontrolowanej przez atakującego. Naprawiono w wersji 9.1.0.
Nodemailer przed wersją 9.1.0 zawiera podatność na kwadratową złożoność czasową w komponencie addressparser, która pozwala zdalnym atakującym wywołać odmowę usługi poprzez dostarczenie spreparowanej listy adresów oddzielonych przecinkami. Atakujący może wysłać pojedynczy e-mail z dużą liczbą adresów, aby zablokować pętlę zdarzeń Node.js na dłuższy czas, zużywając 100% CPU i zamrażając proces.
Nodemailer w wersjach 9.1.0 i wcześniejszych nie respektuje opcji sandboxa disableFileAccess i disableUrlAccess, gdy treść wiadomości jest rozwiązywana przez publiczne API pluginów MailMessage.resolveContent() z użyciem starej trzyargumentowej sygnatury. W efekcie kod pluginu lub aplikacji może zostać zmuszony do odczytu dowolnych plików lokalnych lub wykonania wychodzących żądań HTTP(S) (SSRF), omijając włączony sandbox. Naprawiono w wersji 9.1.1.
Craft CMS od wersji 5.0.0-RC1 do przed 5.11.0 nieprawidłowo autoryzuje pola GraphQL draftCreator i revisionCreator. Zamiast wymagać zakresu user-data egzekwowanego przez Gql::canQueryUsers(), pola te są ograniczone tylko do zakresów elements.drafts:read / elements.revisions:read, a ich resolver zwraca surowy element User bez autoryzacji poszczególnych pól. Klient z tylko tymi zakresami może uzyskać adresy e-mail, nazwy użytkowników, pełne nazwiska i adresy pocztowe wszystkich twórców wersji roboczych i rewizji. Problem naprawiono w wersji 5.11.0.
Craft CMS w wersjach 5.10.0–5.10.12 zawiera niekompletną poprawkę CVE-2026-55794 — sink Controller::getPostedRedirectUrl() -> View::renderObjectTemplate() pozostał bez sandboxa, a ten sam commit dodał oracle do samodzielnego podpisywania w Cp::elementLabelHtml(). Ponieważ tokeny HMAC Craft/Yii nie są powiązane z nazwą parametru, uwierzytelniony użytkownik panelu o niskich uprawnieniach z prawem edycji jednego typu elementu może wygenerować token dla kontrolowanego przez atakującego szablonu Twig dla parametru returnUrl i odtworzyć go jako parametr POST przekierowania, osiągając niesandboxowany sink i wstrzyknięcie szablonu po stronie serwera, co prowadzi do wykonania dowolnego kodu PHP. Problem naprawiono w wersji 5.10.13.
Craft CMS w wersjach 4.8.0–4.18.5 oraz 5.0.0–5.10.12 podpisuje kontrolowany przez atakującego cookie license-shun uwierzytelnionego użytkownika tym samym kluczem i formatem, których używa do walidacji podpisanych parametrów przekierowania, ponieważ podpis HMAC nie jest powiązany z celem (cookieValidationKey Yii pochodzi z tego samego securityKey Craft używanego dla podpisanych parametrów żądania). Uwierzytelniony użytkownik niebędący administratorem może ustawić cookie przez endpoint license-shun i przenieść podpisaną kopertę do parametru przekierowania; po udanym logowaniu Craft waliduje podpis i renderuje uwierzytelnione bajty jako niesandboxowany szablon Twig, gdzie filtr map akceptuje callback tekstowy i pozwala PHP system() wykonać dowolne polecenia systemu operacyjnego jako użytkownik serwera WWW. Eksploatacja wymaga konta z uwierzytelnianiem hasłem bez aktywnego 2FA, domyślnej konfiguracji żądań i dostępności PHP system(). Problem naprawiono w wersjach 4.18.6 i 5.10.13.
Craft CMS w wersjach od 5.0.0 do 5.10.12 traktuje awarię połączenia z bazą danych jako brak instalacji, co udostępnia anonimowe akcje instalatora (m.in. install/validate-site) na zainstalowanej stronie produkcyjnej, gdy PHP działa, ale MySQL jest niedostępny. Uwierzytelniony atakujący z ważną sesją gościa i tokenem CSRF może odczytać wartości zmiennych środowiskowych, w tym klucz bezpieczeństwa, dane dostępowe do bazy czy klucze API. Naprawiono w wersji 5.10.13.
Craft CMS w wersjach od 5.7.0 do 5.10.13 zawiera podatność typu stored XSS w funkcji Generated Fields, która wyłącza automatyczne escapowanie Twig i nie koduje wartości z pamięci podręcznej. Redaktorzy treści mogą wstrzykiwać złośliwy JavaScript przez edytowalne pola, który wykonuje się w sesjach uwierzytelnionych użytkowników Panelu sterowania o wyższych uprawnieniach. Naprawiono w wersji 5.10.13.
Craft CMS 5.0.0 do 5.10.12 zawiera wadę kontroli dostępu w punkcie końcowym zmiany kolejności zagnieżdżonych elementów. Uwierzytelniony użytkownik z uprawnieniami tylko do podglądu może zmienić kolejność bloków Matrix lub pól Address w treści innego autora, do której nie ma uprawnień zapisu.
n8n przed wersjami 1.123.76, 2.37.7 i 2.38.2 ma podatność w punkcie końcowym push kontroli źródła, która pozwala uwierzytelnionemu użytkownikowi projektu na usunięcie plików (workflow i poświadczeń) z projektów, do których nie ma dostępu. Wykorzystanie wymaga włączonej funkcji Source Control (Środowiska) w wersji enterprise.
n8n przed wersjami 1.123.76, 2.37.7 i 2.38.2 ma podatność w węźle Git, która pozwala uwierzytelnionemu użytkownikowi na odczyt repozytoriów Git poza skonfigurowanym katalogiem (N8N_RESTRICT_FILE_ACCESS_TO). Poprzez zagnieżdżenie repozytorium poniżej skonfigurowanej ścieżki, użytkownik może sprawić, że walidacja URL przejdzie, a git faktycznie odczyta dane spoza dozwolonego obszaru.
AVideo do wersji 29.0 nie weryfikuje uprawnień dostępu do wideo w funkcji set_api_comment, co pozwala uwierzytelnionym użytkownikom dodawać komentarze do filmów chronionych hasłem lub ograniczonych dla grup. Atakujący mogą wysyłać żądania POST do punktu końcowego API komentarzy z dowolnymi identyfikatorami wideo.
AVideo do wersji 29.0 nie waliduje uprawnień dostępu do wideo w punkcie końcowym API like, co pozwala zalogowanym użytkownikom głosować na filmy chronione hasłem lub ograniczone dla grup. Atakujący mogą wysyłać żądania like/dislike, aby zwiększać liczniki głosów na filmach, których nie mogą oglądać.
AVideo do wersji 29.0 zawiera podatność na trwały cross-site scripting (XSS). Nieuwierzytelniony punkt końcowy zliczania wyświetleń zapisuje User-Agent atakującego bezpośrednio do bazy danych, a następnie jest on renderowany bez escapowania na stronie statystyk właściciela wideo i administratora, co pozwala na wykonanie złośliwego kodu w ich sesjach.
AVideo do wersji 29.0 zawiera wyścig w funkcji enforceRateLimit(), która nie atomowo zwiększa liczników ograniczeń, co pozwala atakującym ominąć wszystkie limity, w tym ochronę przed brute-force na logowanie, poprzez wysyłanie równoczesnych żądań. Atakujący mogą przekroczyć limit 30 prób na 5 minut dowolną liczbę razy.
AVideo (WWBN/AVideo) do wersji 29.0 jest podatny na cross-site request forgery (CSRF). Mechanizm ochrony CSRF jest wyłączany, gdy w żądaniu obecne są parametry 'user' i 'pass', ale ich wartości nie są weryfikowane. Atakujący może wykorzystać to do modyfikacji rekordów wideo, w tym przeniesienia własności, usunięcia ograniczeń dostępu i innych zmian.
W AVideo do wersji 29.0, konstruktor Like::__construct() wykonuje operacje arytmetyczne na surowych wartościach żądań przed walidacją, co pozwala na desynchronizację przechowywanych głosów od liczników. Uwierzytelnieni atakujący mogą wysyłać parametry typu tablicowego, aby doprowadzić liczniki polubień do dowolnie niskich wartości, a uszkodzenie utrzymuje się do ręcznej naprawy.
Wtyczka CloneSite w AVideo do wersji 29.0 zawiera podatność na wstrzykiwanie poleceń systemu operacyjnego (OS command injection) typu stored. Hasło SSH przechowywane w konfiguracji jest podstawiane do polecenia `sshpass -p '{password}' rsync ...` bez odpowiedniego escapowania, co pozwala na wstrzyknięcie dowolnego polecenia przez znak pojedynczego cudzysłowu. Atak wymaga uprzedniego nakłonienia administratora do zapisania złośliwego hasła przez wektor CSRF, a następnie wykonania zaplanowanego zadania cron.
W AVideo do wersji 29.0, funkcja autoCSRFGuard() utrzymuje listę wyjątków CSRF opartą na nazwach plików bez kontekstu katalogu, co pozwala plikom wtyczek o nazwach zgodnych z plikami rdzenia na dziedziczenie wyjątków CSRF. Wtyczka LoginWordPress (login.json.php) dziedziczy wyjątek i bezwarunkowo wylogowuje uwierzytelnionych użytkowników na żądania cross-site przed walidacją poświadczeń.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

