Katalog podatności CVE

Froxlor 2.3.10 i wcześniejsze zawierają wyścig TOCTOU w synchronizacji kluczy SSH (lib/Froxlor/Cron/System/SshKeys.php, SshKeys::generateFiles). Walidacja zawartości/symlinków wykonywana przez FileDir::makeCorrectDir()/makeCorrectFile() jest tylko w czasie sprawdzenia; ścieżka pliku jest ponownie rozwiązywana jako root w czasie zapisu, bez przypinania ścieżki lub deskryptora pliku. Na instalacjach z włączonym system.allow_customer_shell=1, klient może podmienić swój katalog ~/.ssh na symlink po sprawdzeniu, co powoduje, że cron działający jako root dopisuje klucz publiczny klienta do /root/.ssh/authorized_keys i zmienia właściciela /root/.ssh na klienta, prowadząc do pełnego przejęcia hosta panelu. Naprawiono w Froxlor 2.3.12.

Froxlor przed wersją 2.3.12 nie unieważnia istniejących sesji panelu, kluczy API i ciasteczek zaufania 2FA po zmianie hasła użytkownika. Atakujący posiadający przejęte sesje, ważne klucze API lub tokeny zaufania 2FA zachowują pełny dostęp do konta po rotacji hasła, omijając działania związane z reagowaniem na incydenty.

Froxlor do wersji 2.3.10 przechowuje tylko numeryczny identyfikator użytkownika w tokenach zapamiętanych 2FA (panel_2fa_tokens) bez rejestrowania przestrzeni nazw konta, a wyszukiwanie zapamiętanego tokena podczas logowania nie jest ograniczone do typu konta klienta lub administratora. Ponieważ identyfikatory klientów i administratorów są przydzielane z oddzielnych przestrzeni nazw, token zapamiętany 2FA wydany klientowi o danym ID pasuje również do administratora o tym samym ID. Atakujący kontrolujący konto klienta z kolidującym ID, posiadający ważne ciasteczko zapamiętane 2FA i znający hasło administratora, może ominąć drugi czynnik TOTP administratora i uzyskać uwierzytelnioną sesję administratora. Jest to tylko obejście drugiego czynnika; nie pokonuje uwierzytelniania hasłem. Naprawiono w wersji 2.3.12.

Froxlor przed wersją 2.3.13 zwraca kolumnę ssl_key_file — która przechowuje surową zawartość prywatnego klucza TLS w formacie PEM — bezpośrednio w odpowiedziach JSON poleceń API Certificates.get i Certificates.listing, ponieważ wyniki zapytań domain_ssl_settings są przekazywane przez ApiCommand::response() bez żadnego usuwania pól ani listy dozwolonych. Nisko uprzywilejowany uwierzytelniony klient API może pobrać klucze prywatne certyfikatów swoich domen, w tym klucze Let's Encrypt generowane przez Froxlor po stronie serwera i przechowywane z uprawnieniami root-only (0600), do których klient nie ma dostępu do systemu plików; konta reseller i customers_see_all admin mogą zrzucić klucze prywatne innych podmiotów przez ten sam mechanizm. Ujawnione klucze umożliwiają podszywanie się pod domenę, pasywne deszyfrowanie przechwyconego ruchu TLS oraz aktywne ataki typu man-in-the-middle.

Kyverno w wersjach przed 1.19.1 zawiera lukę pozwalającą na obejście izolacji przestrzeni nazw w wpisie kontekstu apiCall dla zasobów Policy z ograniczeniem do namespace. Wynika to z niespójnej interpretacji ścieżek między walidacją a wykonaniem. Użytkownik o niskich uprawnieniach może użyć procentowo zakodowanych segmentów kropek w urlPath, aby ominąć sprawdzanie przestrzeni nazw i odczytać zasoby z innych namespace przy użyciu poświadczeń ServiceAccount kontrolera Kyverno.

Kyverno przed wersją 1.19.1 jest podatny na SSRF. Domyślna lista blokowania egress (169.254.169.254, 169.254.169.253, metadata.google.internal, 127.0.0.0/8, ::1/128) i kontrola tokenów z ograniczonym zakresem były podłączone tylko do nowej biblioteki CEL http.Get/Post, ale nie do starszego executor usług apiCall (pkg/engine/apicall/executor.go) ani do ścieżki GlobalContextEntry external-API. Te ścieżki używają zwykłego klienta net/http bez filtrowania egress i bez walidacji adresu URL usługi, co pozwala autorowi ClusterPolicy lub GlobalContextEntry (lub osobie przesyłającej zasoby, jeśli polityka używa szablonu URL) na wysyłanie żądań GET/POST do dowolnego hosta, w tym do punktu metadanych chmury, loopback i usług wewnątrz klastra. Executor bezwarunkowo dołącza token ServiceAccount Kyverno do wybranego przez atakującego miejsca docelowego. Naprawiono w wersji 1.19.1.

Kyverno to silnik polityk dla Kubernetes. W wersjach od 1.14.0 do 1.19.0 evaluator ImageValidatingPolicy nigdy nie odczytuje pól spec.images i spec.allowedValues z PolicyException. Każdy PolicyException, którego policyRefs i matchConditions pasują do zasobu, powoduje pominięcie weryfikacji podpisu obrazu dla całego zasobu, a nie tylko dla wymienionych obrazów lub wartości. W rezultacie niepodpisane lub niezaufane obrazy mogą być dopuszczone do klastra bez weryfikacji podpisu. Różni się to od ValidatingPolicy, GeneratingPolicy i MutatingPolicy, które traktują to samo pole jako częściowe wyłączenie. Problem naprawiono w wersji 1.19.1.

Kyverno w wersjach od 1.16.0 do 1.19.0 rejestruje bibliotekę globalcontext.Lib CEL w środowisku polityk bez ograniczania jej do przestrzeni nazw polityki, w przeciwieństwie do bibliotek pokrewnych, które otrzymują przestrzeń nazw polityki. Tenant mogący tworzyć polityki z ograniczeniem do namespace w swoim namespace może wywołać globalContext.get("<entry>", "") i otrzymać pełną zawartość buforowanego GlobalContextEntry o zasięgu klastra, w tym dane z przestrzeni nazw, do których tenant nie ma uprawnień RBAC. Brak walidacji przyjęcia odrzucającej takie wywołania. Naprawiono w 1.19.1.

nodemailer w wersjach przed 10.0.6 zawiera podatność typu denial of service w wyrażeniu regularnym fallbacku free-text parsera adresów, które wykazuje kwadratowe zachowanie backtrackingu. Atakujący mogą dostarczyć spreparowane wartości nagłówków e-mail z długimi ciągami bez spacji, aby zablokować pętlę zdarzeń Node.js na dziesiątki sekund, powodując niedostępność usługi.

Adminer w wersjach od 6.0.0 do 6.0.1, gdy załadowany jest oficjalny plugin sterownika ClickHouse, jest podatny na podatność Server-Side Request Forgery przed uwierzytelnieniem. Nieuwierzytelniony atakujący może przesłać auth[driver]=clickhouse z auth[server] ustawionym na dowolny URL, powodując, że serwer Adminer wyśle żądanie HTTP POST zawierające 'SELECT version()' do tego hosta. W rootQuery(), jeśli cel zwróci status poza 200-299 (inny niż 401/403), surowe ciało odpowiedzi HTTP jest przypisywane do błędu połączenia i renderowane na stronie logowania, więc atakujący otrzymuje pełne ciało odpowiedzi wewnętrznej usługi. Umożliwia to rozpoznanie wewnętrznej sieci/portów i ujawnienie poufnych informacji zawartych w wewnętrznych stronach błędów. Naprawiono w Adminer 6.0.2.

Hugo w wersjach od v0.162.0 do v0.166.0 zawiera błąd walidacji z rozróżnianiem wielkości liter w regule blokowania adresów IP w security.http.urls, co pozwala atakującym obejść ograniczenia. Atakujący mogą użyć mieszanych wielkości liter w schematach URL w wywołaniach resources.GetRemote, aby pobierać dane z zastrzeżonych adresów IP, takich jak localhost.

Hugo, generator statycznych stron, w wersjach po v0.123.0 i przed v0.166.0, ma wadę w sprawdzaniu ograniczeń dowiązań symbolicznych (symlink confinement). Motyw lub moduł w themes/ (lub vendorowany moduł) może zawierać dowiązanie symboliczne w punkcie montowania (np. themes/mytheme/assets -> /some/dir/outside), co pozwala na odczyt plików spoza dozwolonych ścieżek podczas budowania strony oraz publikowanie ich do public/ przez statyczne montowania, omijając zasadę, że źródła montowania motywów i modułów muszą być lokalnymi ścieżkami.

Hugo w wersjach od v0.161.0 do v0.165.0 uruchamia narzędzia Node.js (css.PostCSS, css.TailwindCSS, js.Babel) w modelu uprawnień Node.js, aby ograniczyć odczyt systemu plików do katalogu projektu i skonfigurowanych montowań. Ponieważ model uprawnień Node.js waliduje tylko ścieżkę leksykalną i podąża za dowiązaniami symbolicznymi wskazującymi poza dozwolony zbiór, Hugo nie wykrywał dowiązań symbolicznych wychodzących z piaskownicy. Atakujący mogący wnosić treść do projektu Hugo może zatwierdzić dowiązanie symboliczne, takie jak assets/css/x.css -> /etc/passwd, wraz z pluginem PostCSS, który je odczytuje, umożliwiając ujawnienie dowolnego pliku czytelnego przez proces budowania Hugo i potencjalne osadzenie go w opublikowanej witrynie. Dotyczy to kompilacji używających domyślnej konfiguracji bezpieczeństwa; projekty, które nie wywołują narzędzi Node.js, nie są dotknięte. Naprawiono w v0.166.0, który skanuje dozwolone ścieżki i przerywa kompilację, gdy dowiązanie symboliczne wskazuje poza nie.

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 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.