Katalog podatności CVE

Grav Admin przed wersją 2.0.20 nie sanityzuje danych wyjściowych z marked.parse() przed wstrzyknięciem ich do DOM przez dyrektywę {@html} w komponentach MarkdownEditor i MarkdownModal. Atakujący mogą wstrzyknąć schematy javascript: URI w dziennikach zmian wtyczek lub motywów, aby wykonać dowolny kod w sesjach uwierzytelnionych administratorów bez wymaganego dostępu do strony.

Grav Admin (getgrav/grav-plugin-admin2) w wersjach do 2.0.19 zawiera podatność na trwały XSS w funkcji tHtml(), która podstawia niezaufane parametry, takie jak nazwy użytkowników, do szablonów tłumaczeń przed parsowaniem wyniku jako markdown. Walidacja nazw użytkownika po stronie serwera nie blokuje znaków <, >, " czy ', co pozwala atakującemu zarejestrować nazwę zawierającą kod HTML. Gdy administrator przegląda interfejs renderujący nazwę przez tHtml(), kod wykonuje się w jego sesji. Naprawiono w wersji 2.0.21.

Grav Shortcode Core przed wersją 6.2.5 zawiera podatności na trwałe cross-site scripting w parametrze tagu [lorem] oraz parametrze summary tagu [details], które są zapisywane do renderowanych stron bez escapowania. Atakujący z prawem edycji stron mogą wstrzykiwać dowolny HTML i JavaScript, który wykonuje się w przeglądarkach wszystkich odwiedzających stronę, w tym administratorów.

Grav w wersjach od 2.0.0 do 2.0.17 nie stosuje wykrywania XSS przy zapisie do stron modułowych, co pozwala uwierzytelnionym edytorom stron na przechowywanie złośliwych ładunków Twig. Atakujący z uprawnieniami do edycji stron mogą tworzyć strony modułowe z złośliwym kodem Twig, który wykonuje się w przeglądarkach odwiedzających, w tym w sesjach administratora.

Traefik przed wersjami v2.11.55 i v3.0.0 do v3.7.10 zawiera podatność na konflikt rozwiązywania opcji TLS, która pozwala nieuwierzytelnionym atakującym ominąć uwierzytelnianie certyfikatem klienta poprzez tworzenie sprzecznych opcji TLS na routerach z wieloma hostami. Atakujący mogą dotrzeć do chronionych backendów, wykorzystując wspólne rozwiązywanie TLS dla wielu nazw hostów w jednej regule routera, co powoduje, że ścisły wymóg mTLS jest zastępowany domyślnymi opcjami dla wszystkich hostów.

Traefik w wersjach >= v3.7.0 i <= v3.7.10 zawiera obejście uwierzytelniania w dostawcy Kubernetes Ingress NGINX. Opcja TLS wygenerowana dla Ingress z adnotacją nginx.ingress.kubernetes.io/auth-tls-secret była nazwana według przestrzeni nazw i nazwy Ingress. W rezultacie dwa obiekty Ingress współdzielące ten sam host, ten sam sekret CA klienta i ten sam tryb uwierzytelniania klienta tworzyły dwie różne nazwy opcji TLS dla tego hosta. Traefik traktuje to jako konflikt opcji TLS i wraca do domyślnej konfiguracji TLS punktu wejścia, która nie wymaga certyfikatu klienta, więc trasa skonfigurowana z nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" staje się osiągalna bez certyfikatu klienta. Dotyczy tylko linii v3.7; problem naprawiono w v3.7.11.

Traefik w wersjach przed v2.11.55 oraz w wersjach v3.0.0 do v3.7.10 zawiera podatność na obejście uwierzytelniania w middleware digestAuth, gdzie nieznane nazwy użytkowników otrzymują pusty sekret zamiast odrzucenia. Atakujący mogą obliczyć poprawną odpowiedź digest przy użyciu pustego sekretu i dowolnych poświadczeń, aby obejść uwierzytelnianie na dowolnej trasie chronionej przez digestAuth bez ważnej nazwy użytkownika lub hasła.

Traefik w wersjach od v3.7.1 nie egzekwuje ograniczeń crossProviderNamespaces dla adnotacji traefik.ingress.kubernetes.io/service.middlewares w dostawcy Kubernetes Ingress. Dzierżawca z ograniczeniem do przestrzeni nazw, wykluczony z listy dozwolonych, może dołączyć do swojej usługi middleware należący do operatora, a jeśli ten middleware wstrzykuje poświadczenia backendu, może je odzyskać na kontrolowanym backendzie.

phpMyFAQ przed wersją 4.1.8 zawiera podatność na trwały XSS w funkcji FaqHelper::convertOldInternalLinks(), która wywołuje html_entity_decode() na oczyszczonej treści FAQ, co odwraca ochronę encji. Uwierzytelnieni użytkownicy z uprawnieniami do edycji FAQ mogą wstrzyknąć kod JavaScript, który wykonuje się w przeglądarkach wszystkich użytkowników przeglądających dotknięte strony FAQ.

phpMyFAQ przed wersją 4.1.8 zawiera podatność na obejście autoryzacji w punkcie końcowym tworzenia pytań. Metoda isAddingQuestionsAllowed() przyznaje dostęp wszystkim wywołującym, gdy włączona jest opcja main.enableAskQuestions, ignorując ustawienie records.allowQuestionsForGuests. Nieuwierzytelnieni atakujący mogą wysyłać pytania przez API question/create, omijając ograniczenia dla gości i wstrzykując spam do kolejki moderacji administratora.

phpMyFAQ przed wersją 4.1.8 zawiera podatność na obejście uwierzytelniania w punkcie końcowym API panelu sterowania użytkownika, która pozwala uwierzytelnionym atakującym na zmianę haseł kont bez weryfikacji bieżącego hasła. Atakujący z dostępem do sesji mogą wysłać żądanie PUT do punktu końcowego aktualizacji danych użytkownika tylko z tokenem CSRF, aby po cichu zmienić hasło dowolnego użytkownika, w tym administratorów, powodując nieodwracalne przejęcie konta i zablokowanie ofiary.

phpMyFAQ przed wersją 4.1.8 zawiera podatność na ominięcie uwierzytelniania w funkcji wyłączania dwuskładnikowego uwierzytelniania (TOTP). Procedura removeTwofactorConfig() weryfikuje tylko zalogowanie użytkownika i ważny token CSRF, po czym wyłącza TOTP bez wymogu ponownego podania hasła lub aktualnego kodu TOTP. Atakujący, który przejął sesję użytkownika, może po cichu usunąć ochronę dwuskładnikową z dowolnego konta, w tym administratora.

phpMyFAQ przed wersją 4.2.0-alpha.2 zawiera brak autoryzacji w endpointach API panelu administracyjnego 'searches' i 'content-health', które wymagają tylko uwierzytelnienia bez sprawdzania uprawnień. Każdy uwierzytelniony użytkownik może uzyskać dostęp do tych endpointów i czytać statystyki wyszukiwań oraz liczniki stanu treści niezależnie od poziomu uprawnień.

phpMyFAQ przed wersją 4.1.8 zawiera sekrety TOTP w postaci jawnego tekstu w plikach ZIP eksportu danych użytkownika. Atakujący, którzy zdobędą wyeksportowane archiwa, mogą wyodrębnić ziarno TOTP i generować ważne kody jednorazowe, aby obejść uwierzytelnianie dwuskładnikowe.

phpMyFAQ przed wersją 4.1.8 egzekwuje nieprawidłowe kontrole uprawnień na stronach treści administracyjnych, co pozwala edytorom z niższymi uprawnieniami czytać wersje robocze i nieaktywne treści. Atakujący z uprawnieniami tylko do dodawania mogą uzyskać dostęp do endpointów edycji newsów i tłumaczeń FAQ, aby przeglądać nieopublikowane treści.

phpMyFAQ przed wersją 4.1.8 nie weryfikuje CAPTCHA, gdy parametr 'store' jest ustawiony na 'now' w żądaniach przesyłania pytań. Nieuwierzytelnieni atakujący mogą ominąć ochronę CAPTCHA i przesyłać nieograniczoną liczbę pytań bezpośrednio, powodując zanieczyszczenie bazy danych i wyzwalając powiadomienia e-mail.

SiYuan przed wersją v3.8.2 zawiera podatność na nieograniczone zużycie zasobów w oprogramowaniu pośredniczącym ograniczającym współbieżność żądań, które przechowuje wpisy muteksów dla każdej unikalnej ścieżki żądania bez mechanizmu usuwania. Nieuwierzytelnieni atakujący mogą wysyłać wiele unikalnych ścieżek żądań, trwale zwiększając zużycie pamięci procesu i narzut synchronizacji, co pogarsza dostępność usługi.

SiYuan przed wersją v3.8.2 zawiera podatność na odmowę usługi w mechanizmie ograniczania prób logowania Basic Auth w usłudze publikacji, który przechowuje stan nieudanych prób z użyciem nazw użytkowników kontrolowanych przez atakującego, bez limitów pojemności i zasad usuwania. Nieuwierzytelnieni atakujący mogą wysyłać powtarzane żądania uwierzytelnienia z unikalnymi nieprawidłowymi nazwami użytkowników, wyczerpując pamięć i zwiększając narzut synchronizacji, co pogarsza dostępność usługi.

SiYuan przed wersją v3.8.2 zawiera podatność na path traversal w dostępnym dla czytelników endpointcie odczytu plików, który podąża za dowiązaniami symbolicznymi podczas otwierania autoryzowanych ścieżek zasobów. Atakujący z rolą czytelnika może zażądać logicznego zasobu w data/assets/, który jest dowiązaniem symbolicznym do pliku poza obszarem roboczym, i otrzymać zawartość docelowego pliku, omijając ograniczenia obszaru roboczego.

SiYuan przed wersją v3.8.2 zawiera podatność na nieograniczone tworzenie sesji w obsłudze Basic Auth usługi publikacji, co pozwala uwierzytelnionym atakującym na wyczerpanie pamięci. Atakujący mogą wielokrotnie uwierzytelniać się z prawidłowymi danymi, tworząc trwałe wpisy sesji bez limitu wygaśnięcia lub pojemności, powodując nieograniczony wzrost pamięci procesu i odmowę usługi.