# Okno czasowe między poprawką a atakiem

> Okno czasowe między poprawką a atakiem wyjaśnione: fazy przy PHP2Shell, jak zmierzyć własne okno i jakimi krokami je skrócić w firmowym IT.

Źródło: https://phpsos.de/pl/blog/zeitfenster-patch-angriff/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**Krótko:** Okno czasowe między poprawką a atakiem było przy PHP2Shell ujemne: według doniesień medialnych pierwsza próba ataku pojawiła się już 17 października 2026, cztery dni przed aktualizacjami. Dla operatorów liczy się więc nie pytanie „Ile zostaje czasu?”, lecz „Jak długo mój serwer jest otwarty?”. To osobiste okno kończy się dopiero wtedy, gdy aktualizacja jest zainstalowana, a wszystkie procesy PHP zrestartowane.

## Punkt wyjścia: ataki przed poprawką

Przez długi czas obowiązywało wygodne założenie: między aktualizacją bezpieczeństwa a pierwszymi atakami mija kilka dni, dość czasu na następne okno serwisowe. PHP2Shell to założenie obaliło. Według doniesień medialnych powołujących się na Amazon zaobserwowano pierwszą próbę ataku już 17 października. Cloudflare również informował o wczesnych atakach. Poprawki ukazały się 21 października o godz. 14:00 UTC.

Ten artykuł wyjaśnia, jak powstają takie okna czasowe i jak skrócić własne. Dokładną kolejność dat znajdą Państwo w [osi czasu PHP2Shell](https://phpsos.de/pl/ratgeber/php2shell-chronologie/).

## Okno czasowe między poprawką a atakiem w fazach

Wokół luki bezpieczeństwa można wyróżnić kilka faz. Przy PHP2Shell wyglądały one tak:

| Faza | Ogólnie | Przy PHP2Shell |
|---|---|---|
| Przed ujawnieniem | luka jest znana tylko odkrywcom i producentowi | opracowanie poprawki pod embargiem |
| Pierwsze ataki bez poprawki | atakujący wykorzystują lukę, zanim istnieje aktualizacja | według doniesień medialnych pierwsza próba 17.10. |
| Zapowiedź | producent zapowiada aktualizację | 20.10., php.net zapowiada wydanie |
| Poprawka dostępna | ukazują się aktualizacja i komunikat bezpieczeństwa | 21.10., godz. 14:00 UTC |
| Analiza poprawki | badacze i atakujący analizują zmiany | watchTowr odtworzył według własnych informacji CVE-2026-109618 |
| Szerokie wykorzystanie | zautomatyzowane kampanie przeciw niezałatanym serwerom | oczekiwane przez BSI; potwierdzone udane ataki na szeroką skalę początkowo nieznane |
| Państwa poprawka | aktualizacja i restart na Państwa serwerach | indywidualnie |

Ostatni wiersz jest jedynym, na który mają Państwo wpływ. Wszystko wcześniej określają inni.

## Dlaczego sama poprawka zwiększa presję

Aktualizacja bezpieczeństwa zamyka lukę, ale jednocześnie czyni ją widoczną. Zmiany w kodzie źródłowym projektów open source, takich jak PHP, są publiczne. Kto porównuje różnice między starą a nową wersją, dowiaduje się, w którym miejscu był błąd. To nie zarzut wobec projektu PHP, lecz normalny przypadek otwartego oprogramowania i podstawa tego, że dystrybucje mogą budować backporty.

Dla operatorów wynika z tego: z każdym dniem po poprawce rośnie liczba tych, którzy wiedzą, jak działa luka. Jednocześnie maleje liczba niezałatanych serwerów. Pozostałe stają się przez to oczywistymi celami. Jak PHP dostarcza aktualizacje bezpieczeństwa w ramach pielęgnacji wersji, wyjaśnia artykuł o [cyklu wydawniczym PHP](https://phpsos.de/pl/php/release-zyklus/).

> **Działać natychmiast:**
> Jeśli Państwa serwer był osiągalny między 17 października a Państwa poprawką, należy sprawdzić ślady. Proszę zabezpieczyć logi od 20 października, zanim zostaną utracone przez rotację.

## Pomiar własnego okna czasowego

Państwa osobiste okno czasowe zaczyna się najpóźniej wraz z publikacją poprawek, a kończy restartem ostatniego procesu PHP. Dla każdego serwera należy zapisać:

- **Wiedza:** Kiedy ktoś w firmie dowiedział się o luce?
- **Dostępność:** Kiedy pakiet Państwa dystrybucji lub dostawcy hostingu był gotowy?
- **Instalacja:** Kiedy został zainstalowany?
- **Restart:** Kiedy nie działały już żadne stare procesy PHP?

Właśnie restart bywa zapominany. Zainstalowana aktualizacja działa dopiero po zakończeniu starych procesów. Jak to sprawdzić, opisuje artykuł [Restart PHP-FPM i wszystkich procesów PHP](https://phpsos.de/pl/php2shell/php-fpm-neustart/). Czy nadal działają procesy sprzed aktualizacji, pokazuje spojrzenie na czasy startu:

```bash
# Pokaż czas startu wszystkich procesów PHP
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
```

Jeśli czas startu jest wcześniejszy niż instalacja aktualizacji, okno jest nadal otwarte.

### Dlaczego Państwa okno zależy od drogi pozyskania

To, jak szybko mogą Państwo załatać, zależy nie tylko od Państwa, ale także od tego, skąd pochodzi Państwa PHP. Dystrybucje dostarczyły backporty według doniesień częściowo jeszcze 21 października. Kto pobiera PHP z repozytorium zewnętrznego dostawcy, jest zdany na jego tempo. Kto korzysta z kontenerów, musi przebudować i wdrożyć obrazy, sama aktualizacja w działającym kontenerze nie wystarcza. A w hostingu współdzielonym moment określa dostawca hostingu.

Kto zna drogę pozyskania każdego serwera, wie też, w którym miejscu jego okno pozostaje otwarte najdłużej. Właśnie tam przygotowanie opłaca się najbardziej, na przykład przez uzgodnienie z dostawcą hostingu lub przetestowaną procedurę dla nowych obrazów kontenerów.

## Jak skrócić okno czasowe następnym razem

1. **Subskrybować komunikaty:** Komunikaty bezpieczeństwa php.net i swojej dystrybucji otrzymywać bezpośrednio, a nie dopiero przez prasę.
2. **Ustalić odpowiedzialność:** Dla każdego serwera jedna osoba odpowiedzialna z zastępcą.
3. **Wykorzystywać automatykę tam, gdzie pasuje:** Aktualizacje bezpieczeństwa z dystrybucji mogą być instalowane automatycznie. Co za tym przemawia, a co przeciw, opisuje artykuł [Automatyczne aktualizacje bezpieczeństwa](https://phpsos.de/pl/blog/automatische-sicherheitsupdates/).
4. **Zaplanować restart:** Restart usług PHP należy na stałe do procedury, a nie do czynności końcowych.
5. **Przygotować drogę awaryjną:** Strona awaryjna i decyzja o czasowym wyłączeniu na wypadek, gdyby aktualizacja nie była możliwa od razu.
6. **Prowadzić dowód:** Dokumentować czasy instalacji i restartu, aby móc później udowodnić swoje okno.

Stały proces, który łączy te punkty, opisano w artykule o [procesie zarządzania poprawkami](https://phpsos.de/pl/blog/patch-management-prozess/).

## Jak konkretnie pomaga PHP SOS?

- **Poprawka i restart:** Instalujemy aktualizację i upewniamy się, że nie działają już stare procesy PHP.
- **Udokumentowanie okna czasowego:** Dokumentujemy instalację i restart na każdym serwerze wraz z czasem.
- **Sprawdzenie śladów:** Za czas, w którym Państwa serwer był otwarty, zabezpieczamy logi i sprawdzamy nieprawidłowości.
- **Proces na przyszłość:** Ustalamy z Państwem drogi zgłoszeń, odpowiedzialności i procedury aktualizacji.

Więcej pod hasłem [usługa łatania PHP](https://phpsos.de/pl/leistungen/php-patch-service/).

## Podsumowanie

Przy PHP2Shell nie było okresu karencji. Okno czasowe między poprawką a atakiem jest przy krytycznych lukach dziś często zerowe, a nawet ujemne. To, czym mogą Państwo sterować, to własne okno: kończy się restartem i można je dzięki przygotowaniu skrócić z dni do godzin.


## Częste pytania

**Ile czasu zostaje po aktualizacji bezpieczeństwa do ataków?**  
Stałego terminu nie ma. Przy PHP2Shell zaobserwowano według doniesień medialnych pierwszą próbę ataku już 17 października, czyli cztery dni przed poprawkami. Przy krytycznych lukach w rozpowszechnionym oprogramowaniu należy zakładać, że praktycznie nie ma okresu karencji.

**Czym jest Zero-Day?**  
Luka, która jest atakowana, zanim będzie dostępna aktualizacja. Producent miał niejako zero dni na jej usunięcie. Potem mówi się często o luce znanej lub N-Day, dla której poprawka już istnieje.

**Dlaczego ataki po poprawce bywają częstsze?**  
Wraz z poprawką staje się publicznie jasne, w którym miejscu był błąd. Badacze bezpieczeństwa i atakujący mogą analizować zmiany. Jednocześnie wiele serwerów przez dni lub tygodnie pozostaje niezałatanych, a więc opłacalnymi celami.

**Kiedy mój serwer jest naprawdę chroniony?**  
Gdy aktualizacja jest zainstalowana, a wszystkie procesy PHP zostały zrestartowane. Same nowe pliki nie działają, dopóki w pamięci pracują stare procesy. Koniec Państwa osobistego okna czasowego to więc restart, a nie pobranie.

## Źródła

- [php.net: komunikaty o bezpieczeństwie](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)
- [Help Net Security: PHP2Shell vulnerabilities patched](https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619)