Katalog podatności CVE

Moduł Ansible keyring_info wycieka hasło z systemowej magazynu kluczy (GNOME Keyring, macOS Keychain, Windows Credential Manager) do wyników zadania, ponieważ pole 'passphrase' w wyjściu nie jest chronione flagą no_log. Hasło jest widoczne w logach, debugu i cache faktów.

W interfejsie WebSocket Event-Driven Ansible (EDA) wykryto brak autoryzacji. Endpoint /api/eda/ws/ansible-rulebook nie weryfikuje uprawnień użytkownika podczas przetwarzania wiadomości Worker. Każdy uwierzytelniony użytkownik może wysłać sfałszowaną wiadomość z dowolnym activation_id, aby uzyskać poświadczenia w postaci jawnego tekstu powiązane z tą aktywacją, w tym tokeny OAuth, hasła do vaultów i klucze SSH.

FOSSBilling, system do zarządzania fakturami i klientami, ma podatność na IDOR w wersjach od 0.6.21 do 0.7.2, umożliwiającą uwierzytelnionym klientom tworzenie zgłoszeń wsparcia, które odnoszą się do zamówień innych klientów. Metoda ticketCreateForClient() nie weryfikowała własności zamówienia, co pozwalało na manipulację rel_id.

W Traefik w wersjach od 3.7.0-ea.1 do 3.7.5 wykryto podatność średniego ryzyka w dostawcy Kubernetes Ingress NGINX. Gdy Ingress jawnie włącza BasicAuth lub DigestAuth przez adnotacje auth-type i auth-secret, ale referencjonowany Secret nie może zostać rozwiązany lub sparsowany, Traefik loguje błąd, pomija instalację middleware uwierzytelniającego i nadal emituje router do backendu. Skutkuje to opublikowaniem chronionej trasy bez kontroli dostępu, umożliwiając nieautoryzowany dostęp.

Podatność w Traefiku (wersje przed 3.6.21 i 3.7.5) w dostawcy Kubernetes Gateway dotyczy mechanizmu dozwolonych przestrzeni nazw (crossProviderNamespaces). Dla reguł HTTPRoute z wieloma backendRefs (WRR) Traefik błędnie sprawdza dozwoloną listę względem docelowej przestrzeni nazw backendRef, a nie przestrzeni nazw samej trasy. Umożliwia to HTTPRoute z niedozwolonej przestrzeni nazw odwołanie się do wewnętrznych usług Traefika (np. api@internal) poprzez wskazanie backendRef.namespace na dozwoloną przestrzeń nazw objętą ReferenceGrant.

Podatność w narzędziu rtk (wersje przed 0.42.2) umożliwiała ominięcie mechanizmu kontroli uprawnień poprzez ukrycie drugiego polecenia w konstrukcjach powłoki Bash, które nie były prawidłowo rozdzielane ani odrzucane. Polecenie zaczynające się od dozwolonego prefiksu (np. 'git') mogło zawierać ukryte polecenie, które było wykonywane bez wymaganej autoryzacji użytkownika.

Pi to minimalny zestaw narzędzi do kodowania w terminalu. W wersjach od 0.74.0 do 0.78.1, instalacje tymczasowych pakietów npm lub git używały przewidywalnych ścieżek w systemowym katalogu tymczasowym, co umożliwiało lokalnemu atakującemu wstrzyknięcie złośliwego kodu.

Pi, minimalne narzędzie programistyczne dla terminala, w wersjach od 0.74.0 do 0.78.1 przechowuje klucze API i dane uwierzytelniające OAuth w pliku auth.json. Wada wyścigu w ścieżce zapisu pliku może tymczasowo utworzyć lub nadpisać ten plik z uprawnieniami wynikającymi z umask procesu, zanim zostaną one zaostrzone do uprawnień tylko dla właściciela.

Podatność w narzędziu Pi (wersje od 0.74.0 do 0.78.1) pozwala na wstrzyknięcie niebezpiecznych adresów URL w eksportowanych plikach HTML. Mechanizm filtrowania schematów URL nie radzi sobie z kontrolnymi znakami C0, które są normalizowane przez przeglądarki przed nawigacją, co umożliwia ominięcie zabezpieczeń.

Pi to minimalny zestaw narzędzi do kodowania w terminalu. W wersjach przed 0.79.0, Pi ładował lokalne zasoby i konfiguracje projektu z katalogu .pi w repozytorium bez pytania użytkownika o zaufanie do tego repozytorium, co mogło prowadzić do uruchomienia złośliwego kodu.

W Traefik przed wersją 3.7.3 wykryto krytyczną podatność w konfiguracji TLS dla HTTP/3 (QUIC). Nieuwierzytelniony klient może ominąć wymuszone uwierzytelnienie mTLS dla konkretnego routera, ponieważ uzgadnianie TLS nie obsługuje poprawnie wzorców wildcard (np. *.example.com) ani różnic w wielkości liter w nazwie SNI.

W Traefik w wersjach od 3.7.0 do 3.7.3 wykryto podatność w mechanizmie ochrony przed domain-fronting (SNICheck). Pozwala ona nieuwierzytelnionemu klientowi ominąć wzajemne uwierzytelnianie TLS wymuszone przez reguły routera z wildcardem, poprzez wysłanie żądania HTTP z nagłówkiem Host do chronionego backendu po ustanowieniu połączenia TLS z permisjami dla innego SNI.

W Traefik przed wersjami 2.11.48, 3.6.19 i 3.7.3 wykryto podatność w middleware StripPrefix. Nieuwierzytelniony atakujący może ominąć uwierzytelnianie i autoryzację na poziomie trasy, używając ścieżki zawierającej '..' lub jej zakodowaną formę '%2e%2e'.

W narzędziu RTK (Rust Token Killer) przed wersją 0.32.0 wykryto podatność polegającą na nieprawidłowym zaufaniu do lokalnych plików konfiguracyjnych projektu. Narzędzie automatycznie ładuje plik .rtk/filters.toml z katalogu roboczego z najwyższym priorytetem i bez powiadamiania użytkownika. Atakujący może umieścić złośliwy plik filtrów w repozytorium, aby selektywnie tłumić lub modyfikować wyniki poleceń powłoki (w tym zawartość plików, różnice i wyniki skanów bezpieczeństwa) bez wykrycia, co może ukryć złośliwy kod podczas wspomaganego przez AI rozwoju lub przeglądu kodu.

W Pivotal CRM w wersji 6.6.04.08 występuje problem, który pozwala zdalnemu atakującemu na wykonanie dowolnego kodu poprzez komponenty Pivotal.Core.Common.dll oraz Pivotal.Engine.Client.Services.Conversion.dll.

Podatność w bibliotece Ash umożliwia atakującemu ustawienie wartości prywatnego argumentu akcji, który powinien być kontrolowany tylko przez zaufany kod serwera. Filtrowanie prywatnych argumentów jest niekompletne zarówno w ścieżce regularnej (dla kluczy binarnych), jak i w ścieżce atomowej (w ogóle nie filtruje).

Wtyczka @rtk-ai/rtk-rewrite w wersji 1.0.0 nie zabezpiecza danych wejściowych przed interpretacją przez powłokę, co pozwala na wstrzyknięcie dowolnych poleceń systemowych. JSON.stringify() nie chroni przed metaznakami powłoki, takimi jak $() i backtick, które są wykonywane przez /bin/sh -c.

W wersjach przed 0.185.0, Daytona pozwalała na aktualizację i usuwanie ról organizacji bez weryfikacji, czy rola należy do danej organizacji. Użytkownik uwierzytelniony, będący właścicielem jakiejkolwiek organizacji, mógł zmodyfikować uprawnienia lub usunąć rolę należącą do innej organizacji, korzystając z identyfikatora tej roli.

W wersjach od 0.101.0 do 0.184.0, sandboxy, które zostały przełączone z publicznych na prywatne, mogły pozostać dostępne bez uwierzytelnienia przez krótki czas po zmianie, z powodu nieunieważnionego stanu widoczności w pamięci podręcznej.

W wersjach przed 0.184.0, użytkownicy mogli akceptować lub odrzucać zaproszenia do organizacji, nawet jeśli ich adres e-mail nie był zweryfikowany. System autoryzacji Daytona nie wymagał weryfikacji e-maila dla tych akcji, co stwarzało ryzyko nieautoryzowanego dostępu.