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.
Budibase w wersjach przed 3.45.0 nie weryfikuje autoryzacji na poziomie aplikacji w punkcie końcowym POST /api/global/groups/:groupId/apps, umożliwiając builderom przypisywanie ról aplikacji poza granicami obszaru roboczego. Builder jednego obszaru roboczego może wykorzystać brak sprawdzania autoryzacji na poziomie aplikacji, aby przyznać sobie role administratora w innych obszarach roboczych poprzez modyfikację mapowań ról grup użytkowników.
Budibase przed wersją 3.45.0 nieprawidłowo ogranicza zakres endpointu GET /api/chat-links do workspace'u, co pozwala builderom wyliczać rekordy powiązań tożsamości czatu we wszystkich workspace'ach w tenancie. Atakujący z dostępem builder do jednego workspace'u może odczytać wrażliwe dane powiązań tożsamości czatu, w tym identyfikatory użytkowników i zewnętrzne identyfikatory usług czatu z innych workspace'ów, do których nie ma uprawnień.
Budibase w wersjach od 3.41.0 do 3.45.0 zawiera obejście uwierzytelniania w ścieżce logowania OIDC/SSO w @budibase/server. Gdy żaden istniejący użytkownik nie pasuje do przychodzącego podmiotu SSO, serwer wyszukuje oczekujące zaproszenia użytkowników wyłącznie po adresie e-mail potwierdzonym przez IdP — bez weryfikacji kodu zaproszenia i bez sprawdzenia email_verified. Atakujący mogący zarejestrować się w zaufanym IdP i podać zaproszony adres e-mail ofiary przejmuje oczekujące zaproszenie i dziedziczy wszystkie przyznane uprawnienia, w tym builder i admin.global.
Budibase (@budibase/server) przed wersją 3.45.0 buduje DDL zmiany nazwy kolumn MySQL i MSSQL w packages/backend-core/src/sql/sqlTable.ts, interpolując identyfikatory bezpośrednio do surowego zapytania bez użycia helperów quoteMySqlIdentifier / quoteSqlServerIdentifier. Atakujący z uprawnieniami DDL na podłączonym źródle danych MySQL/MSSQL może utworzyć kolumnę zawierającą backtick lub apostrof oraz dodatkowy SQL; gdy builder zmieni nazwę tej kolumny przez UI, wstrzyknięty SQL zostanie wykonany.
Budibase Server przed wersją 3.45.0 zawiera podatność na dowolny zapis plików w endpointcie przesyłania ikon PWA, który rozpakowuje dostarczone przez użytkownika archiwa ZIP bez odpowiedniej walidacji dowiązań symbolicznych. Atakujący z rolą BUILDER może stworzyć złośliwy ZIP z dowiązaniami symbolicznymi i zduplikowanymi wpisami plików, aby zapisać dowolne pliki jako root.
Budibase przed wersją 3.45.0 zawiera nieuwierzytelnioną podatność server-side request forgery i eksfiltracji poświadczeń w endpoincie webhook Microsoft Teams, który przyjmuje sfałszowane aktywności Bot Framework z dowolnymi wartościami serviceUrl. Atakujący może wysłać spreparowane żądanie POST, aby wstrzyknąć kontrolowany przez siebie serviceUrl, który jest utrwalany i używany do wszystkich kolejnych odpowiedzi bota, powodując wysyłanie aktywnych tokenów dostępu Microsoft OAuth w nagłówkach Authorization do hosta atakującego oraz umożliwiając ślepy dostęp do sieci wewnętrznej.
Budibase w wersjach przed 3.45.0 nie wyłącza rozwiązywania zewnętrznych referencji JSON w walidatorze importu OpenAPI/Swagger, co pozwala uwierzytelnionym builderom odczytywać dowolne pliki lokalne. Atakujący z dostępem builder może osadzić referencje file:// w specyfikacjach OpenAPI przesyłanych do endpointu importu, aby eksfiltrować wrażliwe pliki, w tym zmienne środowiskowe zawierające sekrety JWT, klucze API i poświadczenia baz danych.
stoatchat przed wersją 0.15.5 nie weryfikuje, czy bilety MFA należą do uwierzytelnionego użytkownika, co pozwala atakującym obejść MFA, używając własnego ważnego biletu z tokenem sesji innego użytkownika. Atakujący może uzyskać bilet ze swojego konta i użyć go z tokenem sesji ofiary, aby wyłączyć TOTP, wyświetlić kody odzyskiwania lub wykonać inne wrażliwe operacje bez podawania poświadczeń ofiary.
Wersje stoatchat przed 0.15.5 nie egzekwują limitów prób na poziomie konta przy wyzwaniach MFA podczas logowania, ograniczając się jedynie do limitu opartego na adresie IP. Atakujący znający hasło może odgadywać kody TOTP, ponownie wykorzystując bilety wyzwania MFA i rozkładając próby na wiele adresów IP, aby obejść ograniczenia i uzyskać dostęp do konta.
Wersje stoatchat przed 0.15.5 zawierają podatność umożliwiającą enumerację kont w punkcie końcowym logowania, ujawniającą lokalizacje plików źródłowych w odpowiedziach błędów. Nieuwierzytelniony atakujący może rozróżnić zarejestrowane i niezarejestrowane adresy e-mail, porównując pola lokalizacji błędów zwracane z żądań POST /api/auth/session/login.
January, usługa proxy/embed mediów stoatchat, przed wersją 0.15.5 nieprawidłowo rozwiązuje wartości SVG <image href> jako lokalne ścieżki systemu plików, gdy pobrany zasób jest serwowany jako image/svg+xml. Nieuwierzytelniony zdalny atakujący, który spowoduje, że usługa pośredniczy w hostowanym przez atakującego SVG, może ustalić istnienie plików lokalnych na podstawie różnic w czasie odpowiedzi oraz ujawnić obsługiwane lokalne pliki obrazów po ponownym kodowaniu.
Wersje stoatchat przed 0.15.5 zawierają podatność typu denial of service w workerze potwierdzeń przetwarzającym wiadomości z masowymi wzmiankami. Uwierzytelniony użytkownik może wysłać pięć spreparowanych wiadomości z wzmiankami ról, aby zakończyć wszystkie workery potwierdzeń, wyłączając powiadomienia push i odznaki wzmianek w całym wdrożeniu do czasu restartu procesu API.
Wersje stoatchat przed 0.15.5 nie ponownie walidują nazw użytkowników po sanityzacji Unicode, umożliwiając atakującym tworzenie nazw z zabronionymi znakami poprzez podanie liter Unicode, które przekształcają się w odrzucone znaki. Atakujący mogą obejść listy dozwolonych znaków i limity długości, tworząc nazwy łudząco podobne do zarezerwowanych, osadzając znaki specjalne i przekraczając limit 32 znaków.
Wtyczka Grav Data Manager w wersjach od 1.0.1 do 1.4.4 renderuje przechowywane wpisy danych w widoku szczegółów elementu bez escapowania, stosując filtr Twig `raw`. Nieuwierzytelniony odwiedzający, który wyśle formularz front-endowy, którego zgłoszenia są zapisywane w user/data, może zapisać ładunek HTML, który wykona się jako JavaScript w sesji i origin administratora, gdy ten otworzy wpis w klasycznym panelu administracyjnym.
Wtyczka Comments dla Grav CMS do wersji 1.2.10 rejestruje handler administracyjny, który zwraca dane komentarzy jako JSON bez sprawdzenia uwierzytelnienia. Handler opiera się na isAdmin(), co wskazuje jedynie, że usługa administracyjna jest zarejestrowana na bieżącej trasie, a nie że odwiedzający jest uwierzytelniony. Na stronie z klasyczną wtyczką Admin i włączoną wtyczką Comments nieuwierzytelniony zdalny atakujący może zażądać /admin/comments/page:<n> i pobrać wszystkie komentarze z ostatnich 7 dni, w tym adresy e-mail komentujących i bezwzględną ścieżkę systemu plików do pliku danych.
Grav to flat-file CMS. W wersjach 2.0.19 do 2.0.24 — oraz w 2.0.0 do 2.0.18 i 1.7.x tylko tam, gdzie Twig treści został jawnie włączony — treść strony autorstwa użytkownika z uprawnieniem tylko do zapisu strony jest renderowana przez sandbox Twig, który zezwala na get_cookie(), zwracający dowolny cookie wysłany z bieżącym żądaniem, w tym cookie sesji odwiedzającego. Grav przechowuje gotowy wynik po Twig w cache treści strony kluczowanym tylko na tożsamości strony i sumie kontrolnej konfiguracji, bez wymiaru sesji, użytkownika czy żądania.
Grav CMS 2.0.14 do 2.0.24 zawiera podatność na eskalację uprawnień w blueprintach grup i kont. Klucze kropkowe, takie jak `access.admin.super`, omijają zabezpieczenia i pozwalają operatorowi z uprawnieniami admin.users na nadanie sobie pełnych uprawnień super-admina.
Grav przed wersją 2.0.25 zawiera przykładowe pliki konfiguracji serwera WWW, w których reguły blokowania dostępu są dopasowywane z uwzględnieniem wielkości liter. W pliku web.config (IIS) każda reguła deny ustawia ignoreCase="false", co pozwala ominąć zabezpieczenia przez zmianę wielkości liter w ścieżce lub rozszerzeniu pliku. Na systemach plików NTFS (niewrażliwych na wielkość liter) nieuwierzytelniony atakujący może uzyskać dostęp do wrażliwych danych, takich jak sekrety konfiguracyjne czy hashe haseł.
Grav 2.0.0 do 2.0.24 zawiera lukę w sandboxie Twig, która pozwala na ominięcie zabezpieczeń. Filtr `array` jest dozwolony w sandboxie, ale nie sprawdza listy dozwolonych metod, co umożliwia odczytanie prywatnych danych kontenera DI, w tym pełnej konfiguracji z sekretami (hasła, klucze OAuth, SMTP, Redis, proxy).
grav-plugin-login (wtyczka logowania do Grav CMS) w wersjach >= 3.8.7 i < 3.9.7 pozwala na ominięcie wyzwania dwuskładnikowego uwierzytelniania (2FA) dla treści chronionych funkcją Twig `authenticated()` lub shortcode `[authenticated]`. Na stronach z włączonym 2FA, `Login::isAuthenticated()` sprawdza tylko flagę sesji oznaczającą pomyślny krok hasła, a nie flagę oznaczającą pełne zalogowanie, więc sesja na etapie podawania kodu 2FA jest traktowana jako w pełni uwierzytelniona. Atakujący znający hasło członka, ale nie mogący odpowiedzieć na drugi czynnik, może czytać treści dostępne tylko dla członków.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

