Katalog podatności CVE

IBM Langflow OSS w wersjach 1.0.0 do 1.12.2 umożliwia zdalnemu uwierzytelnionemu atakującemu wykonanie dowolnego kodu z powodu nieprawidłowej neutralizacji specjalnych elementów używanych w kodzie.

IBM Langflow OSS w wersjach 1.0.0 do 1.12.2 umożliwia zdalnemu uwierzytelnionemu atakującemu wykonanie dowolnego kodu z powodu nieprawidłowej kontroli generowania kodu.

IBM Langflow OSS w wersjach od 1.0.0 do 1.12.2 może pozwolić zdalnemu atakującemu na wykonanie dowolnego kodu z powodu nieprawidłowej kontroli generowania kodu.

IBM Langflow OSS w wersjach 1.0.0 do 1.12.2 umożliwia zdalnemu uwierzytelnionemu atakującemu uzyskanie wrażliwych informacji z powodu nieprawidłowego ograniczenia ścieżki do katalogu zastrzeżonego.

IBM Langflow OSS w wersjach 1.0.0 do 1.12.2 umożliwia zdalnemu uwierzytelnionemu atakującemu uzyskanie wrażliwych informacji z powodu niewystarczającej ochrony poświadczeń.

IBM Langflow OSS w wersjach od 1.0.0 do 1.12.2 może pozwolić zdalnemu uwierzytelnionemu atakującemu na uzyskanie wrażliwych informacji z powodu nieprawidłowej kontroli dostępu.

W produkcie `sssd-kcm` wykryto podatność umożliwiającą atak DoS. Lokalny użytkownik lub proces, który może połączyć się z gniazdem UNIX `sssd-kcm`, może wysłać żądanie z dużym nagłówkiem długości, a następnie wstrzymać połączenie, powodując prealokację znacznej ilości pamięci. Prowadzi to do wyczerpania pamięci w responderze `sssd-kcm` i odmowy usługi.

W ssh w OpenSSH przed wersją 10.6, znak $ lub \ może wystąpić w nazwie użytkownika w wierszu poleceń, co prowadzi do wstrzyknięcia.

IBM Langflow OSS w wersjach 1.0.0 do 1.12.2 umożliwia zdalnemu uwierzytelnionemu atakującemu wykonanie dowolnego kodu z powodu nieprawidłowej kontroli dostępu.

Żądanie strony profilu użytkownika lub organizacji z nagłówkiem Accept dla RSS/Atom zwracało kanał aktywności właściciela bez sprawdzenia widoczności, które stosują strona profilu i trasy .rss/.atom. Anonimowi, ograniczeni użytkownicy i nie-członkowie mogli potwierdzić istnienie ograniczonych lub prywatnych użytkowników i organizacji oraz czytać ich dane profilowe i publiczną aktywność, nawet gdy funkcja ENABLE_FEED była wyłączona. Aktywność w prywatnych repozytoriach nie była uwzględniana.

Punkt końcowy API Gitea do tworzenia mirrorów push sprawdzał tylko, czy mirrorowanie jest włączone, a nie ustawienie [mirror] DISABLE_NEW_PUSH, które egzekwuje interfejs webowy. Administrator repozytorium mógł tworzyć nowe mirrory push w instancjach, gdzie administrator witryny je wyłączył. Mirror push wypycha wszystkie refy repozytorium do zdalnego repozytorium wybranego przez wywołującego, przy każdym commicie lub zgodnie z harmonogramem.

Punkt API GET /api/v1/repos/{owner}/{repo}/media/{filepath} zapisywał pliki do 1 KiB przechowywane bezpośrednio w Git (nie w LFS) do odpowiedzi bez nagłówków content type i disposition, których Gitea używa dla treści użytkownika. Plik HTML w repozytorium był renderowany przez przeglądarkę na origin Gitea. Użytkownik z prawem push do repozytorium mógł uruchomić JavaScript w sesji ofiary otwierającej URL media i działać z jej uprawnieniami.

Przy ustawieniu [repository] FORCE_PRIVATE = true, Gitea tworzy nowe repozytoria jako prywatne, ale hook post-receive nadal stosował opcję push repo.private=false do pustego repozytorium utworzonego przez push. Każdy użytkownik mogący tworzyć repozytoria mógł uczynić swoje nowe repozytorium publicznym, naruszając politykę instancji. Domyślna konfiguracja nie jest dotknięta.

API mirrorów push Gitea sprawdzało, czy właściciel repozytorium, a nie żądający użytkownik, może używać ścieżek lokalnego systemu plików. W instancjach z [security] IMPORT_LOCAL_PATHS = true, administrator repozytorium bez uprawnień do importowania lokalnych ścieżek mógł dodać mirror push do lokalnej ścieżki na serwerze, gdy właściciel repozytorium miał takie uprawnienie. Gitea wypychał refy repozytorium do istniejącego repozytorium Git na tej ścieżce z uprawnieniami procesu Gitea.

Podatność w NVIDIA Model-Optimizer umożliwiająca deserializację niezaufanych danych. Udany atak może prowadzić do wykonania kodu, manipulacji danymi, odmowy usługi oraz ujawnienia informacji.

NVIDIA TensorRT zawiera podatność umożliwiającą atakującemu wywołanie odczytu poza zakresem pamięci. Skuteczne wykorzystanie tej podatności może prowadzić do odmowy usługi (denial of service).

W sshd w OpenSSH do wersji 10.6, w niektórych środowiskach takich jak QNX 6 i SCO OpenServer 5, sshd-session może nieoczekiwanie mieć uprawnienia roota. Jest to związane z opcjami konfiguracji GatewayPorts i StreamLocalForwarding oraz brakiem wsparcia dla przekazywania deskryptorów plików i nieuprzywilejowanej alokacji urządzeń PTY.

W sshd w OpenSSH do wersji 10.6, użycie SDK macOS 27 (lub nowszego) ma skutek uboczny w postaci utraty sandboxingu, co może być nieoczekiwane.

W sshd w OpenSSH przed wersją 10.6, wartość "none" dla opcji konfiguracyjnej jest czasami interpretowana jako nazwa pliku, ale miała oznaczać, że funkcja jest wyłączona.

W Backstage przed wersjami 1.14.6 i 1.15.4, pakiet @backstage/plugin-techdocs-node ma nieprawidłową walidację konfiguracji motywu mkdocs. Użytkownik z prawem zapisu do zarejestrowanego repozytorium może dodać wartości konfiguracyjne w mkdocs.yml, które powodują wykonanie dowolnego kodu podczas budowania dokumentacji.