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.10.27)
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.
W pakiecie @backstage/plugin-scaffolder-backend przed wersją 4.1.0 występuje nieprawidłowa autoryzacja w listowaniu zadań scaffolder. Uwierzytelniony użytkownik wewnętrzny może przeglądać metadane zadań poza zakresem przewidzianym przez politykę uprawnień. W odpowiedzi nie są zawarte tajemnice zadań, a wpływ na integralność i dostępność nie został zidentyfikowany. Problem naprawiono w wersji 4.1.0.
W pakiecie @backstage/plugin-auth-node od wersji 0.3.0 do 0.6.15 i 0.7.5 nie zawsze honorowano jawne negatywne potwierdzenie e-maila podczas normalizacji profili OAuth. W określonych konfiguracjach użytkownik może przejąć inną tożsamość katalogową i uzyskać powiązany dostęp i uprawnienia. Problem naprawiono w wersjach 0.6.15 i 0.7.5.
Pakiet @backstage/plugin-scaffolder-backend-module-sentry od wersji 0.3.0 do 0.3.8 ma nieprawidłową walidację danych wejściowych w akcjach Scaffoldera dla Sentry. Uwierzytelniony użytkownik wewnętrzny mogący wykonać te akcje może spowodować, że backend połączy się z niezamierzonymi miejscami docelowymi i ujawni poświadczenia integracji z Sentry.
W pakiecie @backstage/plugin-catalog-backend-module-bitbucket-server od wersji 0.4.0 do 0.5.15 występuje niespójne filtrowanie repozytoriów w aktualizacjach zdarzeń katalogu Bitbucket Server. Wdrożenia korzystające z aktualizacji zdarzeniowych mogą dodawać lokalizacje z repozytoriów wykluczonych przez filtry. Problem naprawiono w wersji 0.5.15.
W pakiecie @backstage/plugin-auth-backend-module-cloudflare-access-provider od wersji 0.1.0 do 0.5.0 występuje niewystarczająca walidacja audiencji w dostawcy uwierzytelniania Cloudflare Access. Użytkownik z ważnym tokenem dla innej aplikacji Access w tym samym zespole Zero Trust może uwierzytelnić się w Backstage. Problem naprawiono w wersji 0.5.0.
W pakiecie @backstage/plugin-proxy-backend od wersji 0.5.0 do 0.6.18 występuje niespójne egzekwowanie poświadczeń dla nakładających się tras proxy. Gdy trasa nadrzędna zezwala na dostęp nieuwierzytelniony, a trasa zagnieżdżona wymaga poświadczeń, nieuwierzytelniony użytkownik może dotrzeć do zagnieżdżonego upstreamu. Problem naprawiono w wersji 0.6.18.
Pakiet @backstage/plugin-techdocs-node od wersji 0.11.12 do 1.14.7 i 1.15.5 ma nieprawidłową walidację konfiguracji wtyczki mkdocs w TechDocs. Uwierzytelniony atakujący kontrolujący repozytorium źródłowe TechDocs może spowodować, że kompilacja dokumentacji pobierze i opublikuje dane z lokalizacji sieciowych osiągalnych dla środowiska kompilacji.
W loaderze plików DirectDraw Surface (DDS) w GIMP występuje przepełnienie bufora na stercie. Przy wczytywaniu spreparowanego obrazu DDS obliczenia rozmiaru bufora na podstawie szerokości, wysokości i pitch mogą przepełnić 32-bitową arytmetykę, przez co alokowany bufor jest za mały dla zapisywanych danych pikseli przez GEGL. Może to prowadzić do uszkodzenia sterty, a w najgorszym przypadku do wykonania dowolnego kodu w kontekście procesu GIMP.
W Amazon Bedrock AgentCore Starter Toolkit przed wersją 0.3.14 występuje podatność na SSRF w przetwarzaniu schematu OpenAPI w funkcji importu agenta. Uwierzytelniony zdalny aktor w tym samym koncie AWS może spowodować, że środowisko użytkownika importującego agenta wyśle dowolne żądania wychodzące i odczyta dowolne pliki lokalne. Problem naprawiono w wersji 0.3.14, a zalecane jest przejście na @aws/agentcore.
Niewłaściwa kontrola generowania kodu w funkcji importu agentów w Amazon Bedrock AgentCore Starter Toolkit przed wersją 0.3.14 może pozwolić uwierzytelnionemu aktorowi z tego samego konta na wykonanie dowolnego kodu, gdy użytkownik importuje i uruchamia lub wdraża Agenta Bedrock, poprzez spreparowane wartości konfiguracyjne osadzone w wygenerowanym kodzie Pythona bez bezpiecznego kodowania literałów.
W opcjonalnym przykładzie hooka Lambda dla Amazon Q Business (q-business-lambda-hook) dostępnym z QnABot on AWS w wersjach 7.0.0 do 7.4.5 występuje obejście autoryzacji przez klucz kontrolowany przez użytkownika. Uwierzytelniony zdalny użytkownik może odczytać dowolne obiekty S3 w koncie AWS. Problem naprawiono w wersji 7.4.6, ale wymaga ponownego wdrożenia stosu hooka.
W SSSD (System Security Services Daemon) występuje wada polegająca na tym, że żądania przed uwierzytelnieniem zachowują stan w pamięci bez jego czyszczenia lub limitowania czasu. Lokalny atakujący może wielokrotnie inicjować przepływy uwierzytelniania bez ich kończenia, powodując nieograniczone zużycie pamięci, co może prowadzić do DoS.
W SSSD występuje wada polegająca na wyścigu w responderze autofs między zakończeniem asynchronicznego wyliczania a unieważnieniem mapy. Lokalny użytkownik może wielokrotnie wysyłać równoczesne żądania wyliczania i unieważniania map, powodując wyciek pamięci i nadmierne zużycie pamięci, co może zakłócić lub zatrzymać usługę autofs.
Luka w Ghostscript pozwala na obejście sandboxa -dSAFER i wykonanie dowolnych poleceń powłoki w kontekście procesu Ghostscript podczas renderowania spreparowanego dokumentu PostScript lub EPS. Luka łączy uszkodzenie pamięci podczas parsowania dokumentu z wyłączeniem wewnętrznych kontroli dostępu do ścieżek w czasie działania.
Podczas transferu prywatnego repozytorium do użytkownika bez dostępu, Gitea przyznaje mu tymczasowy dostęp do odczytu jako współpracownikowi. Odrzucenie lub anulowanie transferu nie cofało tej współpracy, więc odbiorca zachowywał trwały dostęp do odczytu do prywatnego repozytorium, w tym do kodu, zgłoszeń, pull requestów i wiki, oraz mógł je klonować. Właściciel repozytorium nie był powiadamiany. Dostęp przyznany przez transfer jest teraz usuwany, a współprace istniejące przed transferem są zachowywane.
Gitea rozszerza statyczną macierz `strategy.matrix` w przepływie pracy do pełnego iloczynu kartezjańskiego bez limitu rozmiaru podczas tworzenia przebiegu, przed zastosowaniem bramki zatwierdzania pull requestów z forka. Użytkownik, który może otworzyć pull request z forka, może przesłać mały plik przepływu pracy, którego macierz rozszerza się do bardzo dużej liczby zadań, zużywając pamięć serwera i potencjalnie kończąc proces Gitea. Nie jest wymagany runner. Macierze statyczne powyżej 256 kombinacji są teraz odrzucane przed rozszerzeniem.
Gdy instalator internetowy Gitea jest dostępny dla bazy danych, która już zawiera użytkowników, na przykład po zresetowaniu `INSTALL_LOCK` do `false`, przesłanie formularza instalacji z nazwą administratora pasującą do istniejącego konta wydawało uwierzytelnioną sesję dla tego konta bez weryfikacji hasła. Jeśli konto jest administratorem, sesja daje pełny dostęp administracyjny, w tym możliwość zmiany hasła konta. Bazy danych z jednym użytkownikiem również nie wymagały potwierdzenia ponownej instalacji.
Przy ustawieniu `[migrations] ALLOWED_DOMAINS` na pasujący wpis, taki jak `*` lub wildcard nazwy hosta, walidacja adresów URL migracji w Gitea mogła zezwalać na adresy zastrzeżone i link-local, takie jak `169.254.169.254`, nawet gdy `ALLOW_LOCALNETWORKS = false`. Lista blokowania sieci lokalnych nie obejmowała tych zakresów, a nazwa hosta pasująca do listy dozwolonych była akceptowana niezależnie od jej rozwiązanego adresu. Użytkownik, który może rozpocząć migracje na takiej instancji, mógł dotrzeć do tych adresów z serwera Gitea; domyślna pusta konfiguracja `ALLOWED_DOMAINS` nie jest dotknięta.
Wyrażenie regularne zewnętrznego trackera problemów repozytorium zawierające naprzemienne grupy przechwytujące mogło generować nieprawidłowe indeksy wycinka podczas renderowania odniesień do problemów w Gitea, powodując błąd runtime, który kończył proces Gitea. Użytkownik, który może edytować ustawienia zewnętrznego trackera problemów repozytorium, mógł sprawić, że późniejsze renderowanie pasującej treści, takie jak przeglądanie README, spowoduje awarię instancji dla wszystkich użytkowników.
Podczas przetwarzania treści zgłoszeń i komentarzy, Gitea skanował cały poprzedzający tekst w poszukiwaniu słów kluczowych akcji, takich jak "closes" lub "fixes", raz dla każdego linku Markdown, co dawało czas przetwarzania kwadratowy w stosunku do rozmiaru wejścia. Uwierzytelniony użytkownik mogący przesyłać treść zgłoszeń lub komentarzy mógł wysłać spreparowaną treść o rozmiarze około 1 MB, która zajmuje rdzeń CPU przez kilka minut, trzymając otwartą transakcję bazy danych.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

