Vulnerable and Outdated Components

Vulnerable and Outdated Components to kategoria A06 listy OWASP Top 10 w wydaniu z 2021 roku: używanie bibliotek, frameworków, systemów i innych składników oprogramowania, które mają znane podatności, nie są już wspierane albo nie są aktualizowane ^[1]. W poprzednich wydaniach z 2013 i 2017 roku kategoria nazywała się „Using Components with Known Vulnerabilities” ^[1]. W wydaniu z 2025 roku OWASP rozszerzył ją do kategorii A03:2025 Software Supply Chain Failures, obejmującej cały łańcuch dostaw oprogramowania ^[2].

Jak działa

Problem nie leży w kodzie pisanym przez właściciela aplikacji, tylko w cudzych składnikach, na których ten kod stoi. Gdy w składniku zostaje wykryta podatność i producent wydaje poprawkę, informacja o błędzie staje się publiczna. Dokumentacja WordPressa zauważa, że po wydaniu nowej wersji naprawiającej podatność informacje potrzebne do jej wykorzystania są niemal na pewno dostępne publicznie ^[4]. Od tej chwili każda niezaktualizowana instalacja jest łatwym celem.

RYS. 1Życie podatności w składniku

OWASP podkreśla, że składniki działają zwykle z tymi samymi uprawnieniami co cała aplikacja, więc błąd w dowolnym z nich może mieć poważne skutki ^[1]. Kategoria jest też trudna do zmierzenia: była jedyną w wydaniu 2021 bez żadnych wpisów CVE przypisanych do jej słabości, dlatego przyjęto dla niej domyślne wagi 5,0 ^[1]. Mimo to w ankiecie społeczności zajęła 2. miejsce ^[1].

Składniki

OWASP opisuje, kiedy aplikacja jest narażona. Według wydania 2021 dzieje się tak, gdy właściciel nie zna wersji wszystkich używanych składników, także zależności pośrednich, gdy oprogramowanie jest podatne, niewspierane albo nieaktualne, gdy nie prowadzi się regularnego skanowania i nie śledzi biuletynów bezpieczeństwa oraz gdy aktualizacje odkłada się na długie cykle zmian ^[1]. Kategoria obejmuje trzy słabości CWE, w tym CWE-1104, czyli używanie nieutrzymywanych składników zewnętrznych ^[1].

W WordPressie

Dla stron na WordPressie kategoria ma szczególne znaczenie, bo typowa instalacja składa się w dużej części z wtyczek i motywów pisanych przez różnych autorów. Patchstack w raporcie za pierwsze półrocze 2025 roku policzył 3044 podatności we wtyczkach, 386 w motywach i jedną w rdzeniu ^[3]. Z tych podatności 57,6% nie wymagało uwierzytelnienia ^[3]. Przeważają więc podatności we wtyczkach i podatności w motywach.

Rdzeń. Dokumentacja WordPressa zaleca zawsze używać najnowszej wersji, bo starsze wersje nie otrzymują poprawek bezpieczeństwa ^[4]. Opisuje też podatności serwera WWW i oprogramowania na nim jako osobne źródło ryzyka ^[4].

Wtyczki i motywy. Od WordPressa 5.5 administrator może włączyć automatyczne aktualizacje osobno dla każdej wtyczki i każdego motywu ^[5]. Domyślnie WordPress wykonuje je dwa razy dziennie i wysyła e-mail o udanych i nieudanych próbach ^[5]. Mechanizm opiera się na zadaniach WP-Cron, więc na części serwerów może nie działać poprawnie ^[5]. Osobnym problemem jest porzucona wtyczka, dla której poprawka nigdy się nie ukaże, oraz piracka wtyczka (nulled plugin), której nie da się zaktualizować z oficjalnego źródła.

PHP. Każda gałąź PHP ma dwa lata aktywnego wsparcia i dwa lata wsparcia bezpieczeństwa, po czym przestaje być wspierana ^[6]. Według strony projektu gałąź 8.2 otrzymuje poprawki bezpieczeństwa do 31 grudnia 2026 roku, a gałęzie 8.0 i 8.1 nie są już wspierane ^[6]. Zob. koniec wsparcia dla wersji PHP.

Zagrożenia i skutki

W przykładach ataków OWASP wymienia podatność CVE-2017-5638 we frameworku Struts 2, pozwalającą na zdalne wykonanie kodu, oraz trudności z łataniem urządzeń internetu rzeczy ^[1]. Wskazuje też, że atakujący wyszukują niezałatane systemy wyszukiwarkami takimi jak Shodan ^[1]. CERT Polska ostrzega, że podatności typu zdalnego wykonania kodu mogą zostać masowo wykorzystane zaraz po ujawnieniu ^[7].

• Przejęcie strony przez znaną lukę we wtyczce, bez potrzeby znajdowania nowego błędu.
• Automatyczne skanowanie, ułatwione przez ujawnianie wersji składników.
• Brak poprawki dla oprogramowania po końcu wsparcia, nawet gdy działa ono prawidłowo.

Jak się bronić

OWASP zaleca proces zarządzania poprawkami, który obejmuje usuwanie zbędnych zależności i funkcji, ciągłe śledzenie wersji składników bezpośrednich i pośrednich, obserwowanie baz CVE i NVD, pobieranie składników tylko z oficjalnych źródeł oraz wirtualne patchowanie (virtual patching) tam, gdzie aktualizacja nie jest możliwa ^[1]. Wydanie 2025 dodaje prowadzenie wykazu składników oprogramowania (SBOM) i stopniowe wdrażanie zmian zamiast jednoczesnego na wszystkich systemach ^[2].

CERT Polska zaleca automatyzację pobierania poprawek, testowanie ich przed masowym wdrożeniem i priorytetyzację według ryzyka ^[7]. Systemy po zakończeniu wsparcia należy wymieniać mimo ich prawidłowego działania, a jeśli to niemożliwe, odseparować je i ograniczyć dostęp administracyjny ^[7]. W praktyce WordPressa oznacza to środowisko testowe do sprawdzania aktualizacji, kopię zapasową przed każdą zmianą oraz regularne skanowanie podatności listy wtyczek i motywów.

Historia i przykłady

Kategoria pojawiła się na liście OWASP w 2013 roku jako A9 Using Components with Known Vulnerabilities ^[2]. W 2021 roku awansowała na pozycję A06 pod obecną nazwą ^[1]. W wydaniu 2025 połowa ankietowanych wskazała jej następczynię, Software Supply Chain Failures, jako najważniejsze ryzyko, a kategoria ma najwyższy średni wskaźnik występowania, 5,19% ^[2]. OWASP ilustruje ją atakiem na SolarWinds z 2019 roku, który dotknął około 18 000 organizacji, oraz robakiem Shai-Hulud z 2025 roku, pierwszym udanym samorozprzestrzeniającym się robakiem w rejestrze npm ^[2]; zob. atak na łańcuch dostaw.