Katalog podatności CVE

Przepełnienie bufora na stercie w funkcji H5VM_array_fill() w pliku src/H5VM.c w bibliotece HDF5 przed wersją 2.2.0. Złośliwy plik HDF5 może spowodować awarię aplikacji, a potencjalnie także wykonanie dowolnego kodu, gdy odczytywane są nieprzydzielone fragmenty zbioru danych, a metadane są niespójne z rozmiarem bufora.

Backstage przed wersją 0.17.8 w pakiecie @backstage/backend-defaults ma nieprawidłową walidację danych wejściowych w czytnikach URL magazynu w chmurze. Atakujący z dostępem do zapisu do zasobnika magazynu w chmurze używanego przez Backstage może stworzyć nazwy obiektów, które mogą kolidować z chronionymi plikami w katalogu wyjściowym. W niektórych konfiguracjach może to prowadzić do wstrzyknięcia treści.

Dostawcy katalogu magazynu w chmurze w Backstage przed wersją 1.54.6 nie weryfikowali wystarczająco ścieżek obiektów. Podmiot mogący tworzyć lub zmieniać nazwy obiektów w skonfigurowanym źródle katalogu Azure Blob Storage lub AWS S3 mógł spowodować odczyt deskryptorów katalogu spoza zamierzonej granicy magazynu, ograniczony do lokalizacji osiągalnych za pomocą skonfigurowanych poświadczeń backendu.

Pakiet @backstage/backend-defaults przed wersjami 0.16.1 i 0.17.8 nieprawidłowo zachowuje ograniczenia dostępu podczas delegowania poświadczeń usług. Zewnętrzne poświadczenie usługi skonfigurowane z ograniczeniami (np. tylko do odczytu) może je obejść, kierując żądania przez ścieżki delegowania wtyczek.

Backstage przed wersją 0.6.17 w pakiecie @backstage/plugin-proxy-backend ma nieprawidłową walidację danych wejściowych w proxy-backend. Uwierzytelniony użytkownik Backstage może skonstruować URL żądania, które powoduje przekazanie żądania do ścieżki poza skonfigurowaną ścieżką bazową na serwerze docelowym. Ogranicza się to do serwerów docelowych już skonfigurowanych jako punkty końcowe proxy i wymaga domyślnie uwierzytelnienia Backstage.

Backstage przed wersją 2.2.4 w pakiecie @backstage/plugin-techdocs-backend ma nieprawidłową walidację danych wejściowych w żądaniach statycznych treści techdocs. Przy użyciu dostawcy Azure Blob Storage, uwierzytelniony użytkownik Backstage może być w stanie odczytać ograniczone treści TechDocs, gdy włączone są uprawnienia na poziomie encji. Instalacje, które celowo wyłączają domyślną politykę uwierzytelniania backendu, mogą mieć szerszy zakres narażenia.

Backstage przed wersją 2.2.4 w pakiecie @backstage/plugin-techdocs-backend ma nieprawidłowe egzekwowanie autoryzacji dla statycznych treści techdocs. Uwierzytelniony użytkownik z dostępem do jednej witryny dokumentacji TechDocs może skonstruować URL umożliwiający odczyt dokumentacji należącej do innej encji. Dotyczy to tylko instalacji używających zewnętrznego buildera TechDocs z zewnętrznym dostawcą magazynu (S3, GCS itp.) i włączonym frameworkiem uprawnień. Instancje nieużywające frameworka uprawnień nie są dotknięte, ponieważ treści TechDocs są domyślnie widoczne dla wszystkich uwierzytelnionych użytkowników.

Pakiet @backstage/plugin-auth-backend-module-oidc-provider przed wersją 0.4.20 ma nieprawidłowe uwierzytelnianie w dostawcy OIDC. Wdrożenia używające rozwiązywania tożsamości na podstawie adresu e-mail OIDC z dostawcą zezwalającym na niezweryfikowane adresy e-mail mogą pozwolić uwierzytelnionemu użytkownikowi dostawcy na przyjęcie tożsamości innego użytkownika w katalogu.

Pakiet @backstage/plugin-kubernetes-backend w Backstage przed wersją 0.21.10 jest dotknięty nieobsługiwanym trybem uwierzytelniania klastra katalogu w backendzie Kubernetes. Wdrożenia korzystające z odkrywania klastrów katalogu mogą być dotknięte, gdy kontrybutorzy katalogu mogą tworzyć lub modyfikować encje zasobów kubernetes-cluster. Przy wymaganych uprawnieniach do punktów końcowych i RBAC podów backend może użyć swojej lokalnej tożsamości w klastrze, potencjalnie ujawniając zasoby Kubernetes czytelne dla tej tożsamości. Poświadczenie jest używane tylko z lokalnym punktem końcowym API w klastrze i nie jest wysyłane do punktu końcowego dostarczonego przez katalog.

Pakiety @backstage/plugin-scaffolder-backend-module-bitbucket-cloud przed 0.3.10 i @backstage/plugin-scaffolder-backend-module-bitbucket-server przed 0.2.25 nie weryfikują wystarczająco ścieżek systemu plików w akcjach Scaffoldera dla pull requestów Bitbucket. Uwierzytelniony użytkownik mogący wykonać odpowiedni szablon i wpłynąć na dozwolone repozytorium Bitbucket może oddziaływać na ścieżki poza oczekiwanym obszarem roboczym.

Backstage przed wersją 0.8.7 w pakiecie @backstage/plugin-catalog-backend-module-gitlab ma nieprawidłową autoryzację w ingestii użytkowników organizacji GitLab. Instalacje, które włączają ingestię zdarzeń organizacji GitLab i polegają na ograniczonych użytkownikach katalogu jako granicy dostępu, mogą dopuścić nieprzewidzianą tożsamość katalogu. W zależności od konfiguracji logowania i uprawnień może to umożliwić nieautoryzowany dostęp z uprawnieniami standardowego uwierzytelnionego użytkownika.

Backstage przed wersją 1.54.6 nie egzekwuje spójnie granic poświadczeń w akcjach scaffolder source-control. Uwierzytelniony użytkownik może spowodować, że akcja użyje szerszych poświadczeń integracji i wykona operacje z większym dostępem niż zamierzono. Problem naprawiono w wersji 1.54.6, pod warunkiem włączenia przez operatorów opcji scaffolder.requireScmUserCredentials po aktualizacji.

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.