CVE-2025-42615

Funkcjonalność odzyskiwania konta (reset hasła) w aplikacji vulnerability-lookup zawiera wyścig TOCTOU w konsumpcji jednorazowych tokenów odzyskiwania. Dwa równoczesne żądania HTTP z tym samym ważnym tokenem mogą przejść weryfikację przed zatwierdzeniem transakcji, co pozwala obu ustawić własne hasło na koncie docelowym. Dodatkowo, w tym samym punkcie końcowym (confirm_account) ważny link odzyskiwania może być użyty do ustawienia pustego lub bardzo krótkiego hasła (np. trzy znaki), ponieważ walidacja formularza nie jest wywoływana.

Podatność SSRF w funkcji synchronizacji zdalnych instancji w Vulnerability-Lookup. Adresy zdalnych instancji były walidowane tylko pod kątem podstawowej składni URL, a następnie serwer wykonywał żądania do nich bez ograniczeń sieciowych, podążając za przekierowaniami bez ponownej walidacji. Uwierzytelniony administrator z uprawnieniem admin:access mógł skonfigurować instancję wskazującą na wewnętrzne, pętlowe, link-local lub cloud metadata usługi.

Vulnerability-Lookup zawiera słabość mechanizmu aktywacji konta i odzyskiwania hasła, gdzie tokeny aktywacji/recovery są wielokrotnego użytku i nie są powiązane z celem. Atakujący, który zdobędzie ważny link, może wielokrotnie zmieniać hasło i przejmować kontrolę nad kontem.

Podatność w Vulnerability-Lookup pozwala nieaktywnym lub niepotwierdzonym kontom subskrybować strumienie SSE przez endpoint /pubsub/subscribe/<topic>. Autoryzacja opierała się wyłącznie na nagłówku X-API-KEY, bez weryfikacji stanu konta. Atakujący może utworzyć konto i natychmiast uzyskać dostęp do strumieni, które powinny być dostępne tylko dla aktywnych i potwierdzonych użytkowników.

W aplikacji Vulnerability-Lookup wykryto podatność na trwały atak XSS w filtrze Jinja render_tag_badges, używanym do wyświetlania tagów referencyjnych powiązanych z rekordami podatności. Wartości z tablicy containers.cna.references[].tags[] były bezpośrednio wstawiane do elementów HTML badge i opakowywane w markupsafe.Markup, co omijało automatyczne kodowanie HTML w Jinja. Uwierzytelniony użytkownik z uprawnieniami do tworzenia lub modyfikowania rekordów podatności (np. vulnerability:create lub vulnerability:modify) mógł przesłać przez API CNA spreparowany tag zawierający dowolny HTML lub JavaScript.

W Vulnerability-Lookup w wersjach przed 2.18.0 występuje podatność przechowywanego XSS. Backend nie waliduje ani nie sanityzuje pola related_vulnerabilities w bundle'ach, a frontend konwertuje opisy komentarzy i bundle'ów z Markdown na HTML i wstrzykuje je bezpośrednio do DOM za pomocą innerHTML. Atakujący mogący tworzyć lub edytować komentarze lub bundle'e może zapisać złośliwy kod HTML/JavaScript, który zostanie wykonany w przeglądarce użytkownika odwiedzającego stronę profilu (user.html).

Niektóre endpointy w vulnerability-lookup, które modyfikowały stan aplikacji (np. zmiana wpisów w bazie danych, danych użytkownika, konfiguracji lub inne uprzywilejowane akcje), mogły być dostępne przez żądania HTTP GET bez wymaganego tokenu CSRF. Luka ta naraża aplikację na ataki Cross-Site Request Forgery (CSRF), w których atakujący nakłania zalogowanego użytkownika do odwiedzenia złośliwej strony, powodując wykonanie niepożądanych operacji w kontekście jego sesji.

vulnerability-lookup 2.16.0 zawiera podatność XSS w komponentach bundle.py, comment.py i user.py, która może być wykorzystana przez użytkownika instancji vulnerability-lookup, który może dodawać pakiety, komentarze lub obserwacje. Podatność wynika z niewystarczającej sanityzacji danych wejściowych przed renderowaniem w szablonach i tabelach, co pozwala na wstrzyknięcie dowolnego JavaScriptu.