PoC (proof of concept)

PoC (proof of concept) to minimalny, demonstracyjny przykład wykorzystania podatności, który ma dowieść, że luka jest realna. Może to być krótki skrypt, pojedyncze żądanie HTTP albo opis kroków prowadzących do skutku. PoC różni się od gotowego narzędzia ataku tym, że pokazuje sam mechanizm, bez pełnego uzbrojenia w ładunek (payload). Specyfikacja CVSS v4.0 traktuje publiczną dostępność kodu PoC jako osobny stan dojrzałości zagrożenia, wyraźnie odróżniony od ataków obserwowanych w praktyce ^[1].

Jak działa

PoC odpowiada na jedno pytanie: czy podatność da się wykorzystać w opisanych warunkach. Zwykle pokazuje najsłabszy możliwy skutek, który wystarcza jako dowód, na przykład odczyt pliku zamiast przejęcia serwera. Pełny exploit dodaje do tego niezawodność, obejście zabezpieczeń i ładunek dający atakującemu korzyść.

W programach bug bounty PoC jest częścią zgłoszenia. Zasady programu Patchstack wymagają jasnego, tekstowego PoC krok po kroku, od instalacji wtyczki lub motywu do udanego wykorzystania, wraz z surowymi żądaniami HTTP i dokładnymi ładunkami użytymi w testach ^[3]. Zgłoszenie ma być kompletne, dokładne i powtarzalne ^[3]. Dla producenta oprogramowania PoC jest więc przede wszystkim testem: po wdrożeniu poprawki ten sam PoC powinien przestać działać.

Drogę od odkrycia do publicznego PoC w typowym procesie ujawniania pokazuje schemat poniżej.

RYS. 1PoC w procesie ujawniania

Odmiany

Nazwa PoC obejmuje formy o różnym stopniu gotowości. Specyfikacja CVSS v4.0 wprowadza metrykę dojrzałości exploita (Exploit Maturity) z czterema wartościami ^[1]. Uzupełnia ją odbiorca oceny, nie producent: specyfikacja wskazuje, że to użytkownik CVSS odpowiada za ustawienie tej metryki na podstawie informacji o dostępności kodu i technik wykorzystania ^[1].

W praktyce spotyka się też PoC prywatny, znany tylko badaczowi i producentowi, oraz PoC opisowy, przedstawiony wyłącznie słowami, bez kodu.

W WordPressie

Badacze bezpieczeństwa zgłaszają podatności we wtyczkach i motywach WordPressa między innymi przez programy bug bounty, a w programie Patchstack warunkiem przyjęcia zgłoszenia jest odtwarzalny PoC ^[3]. Program Patchstack oczekuje przy tym testów w typowym środowisku, na ustawieniach domyślnych i na najnowszej stabilnej wersji ^[3]. Do takich testów służy lokalna instalacja albo środowisko testowe (staging), nigdy cudza strona.

Dobrym przykładem decyzji o publikacji PoC jest podatność w rdzeniu naprawiona w WordPressie 7.1.2, wydanym 22 września 2026 roku ^[7]. Nieuwierzytelniony atakujący mógł w pewnych warunkach dołączyć lokalny plik PHP spoza katalogów motywu, co przy sprzyjającej konfiguracji serwera i motywu prowadziło do zdalnego wykonania kodu ^[7]. Patchstack, opisując tę lukę tego samego dnia, napisał wprost, że nie publikuje działającego żądania ^[4]. Mimo to już następnego dnia w obiegu były publiczne narzędzia skanujące, w tym nazwany szablon Nuclei, a w ruchu pojawiały się nagłówki User-Agent z nazwą cve-2026-87902-poc/1.0 ^[5].

Zagrożenia i skutki

Publiczny PoC skraca czas między ujawnieniem a atakiem. Po jego pojawieniu się luka przestaje być wiedzą nielicznych: przeróbka PoC na narzędzie masowe jest zwykle prostsza niż samodzielne znalezienie błędu. MITRE ATT&CK opisuje, że atakujący pobierają darmowe exploity z publicznych repozytoriów i śledzą fora, na których publikuje się nowe exploity ^[8]. Dla właściciela strony oznacza to, że n-day z publicznym PoC jest pilniejszy niż luka o wyższej ocenie, ale bez żadnego kodu w obiegu.

Drugim zagrożeniem są fałszywe PoC. Zespół Unit 42 opisał repozytorium na GitHubie z rzekomym PoC dla podatności CVE-2023-40477 w programie WinRAR, opublikowane 21 sierpnia 2023 roku, cztery dni po ogłoszeniu luki ^[2]. Skrypt poc.py nie wykorzystywał WinRAR-a; był przeróbką publicznego PoC dla innej podatności i uruchamiał wieloetapową infekcję kończącą się instalacją trojana zdalnego dostępu VenomRAT ^[2]. Ofiarami byli więc ci, którzy chcieli PoC przetestować, w tym badacze i administratorzy. Kod RAT (remote access trojan) trafiał na komputer osoby uruchamiającej skrypt.

Dobre praktyki

• Uruchamiać cudzy PoC tylko po przeczytaniu kodu i wyłącznie w odizolowanym środowisku; przykład z Unit 42 pokazuje, że rzekomy PoC może być złośliwym oprogramowaniem ^[2].
• Traktować pojawienie się publicznego PoC jako sygnał do przyspieszenia aktualizacji. W metryce CVSS v4.0 zmienia on dojrzałość z Unreported na POC ^[1].
• Przy zgłaszaniu luki stosować skoordynowane ujawnianie podatności (coordinated vulnerability disclosure). CERT Polska prosi, by nie publikować informacji o podatności przed zakończeniem jej obsługi, i publikuje wpisy CVE po 90 dniach od przekazania szczegółów producentowi, chyba że termin zostanie skrócony ^[6].
• Do czasu aktualizacji rozważyć wirtualne patchowanie (virtual patching) regułą WAF, dopasowaną do mechanizmu pokazanego w PoC.

Historia i przykłady

Wokół CVE-2026-87902 widać cały cykl w ciągu doby. Poprawka w WordPressie 7.1.2 pojawiła się 22 września 2026 roku ^[7]. Patchstack odnotował pierwszą próbę wykorzystania tego samego dnia o 11:49 UTC, a o 15:34 UTC pierwszą próbę zapisu pliku ^[5]. 23 września krążyły już publiczne narzędzia skanujące ^[5]. Wstrzymanie PoC przez firmę opisującą lukę nie zatrzymało więc atakujących, którzy według Patchstack początkowo pracowali na podstawie różnic w kodzie poprawki ^[5].