# PHP2Shell chronologija: įvykiai nuo 2026 m. spalio 17 iki 25 d.

> PHP2Shell chronologija trumpai: nuo pirmo atakos bandymo spalio 17 d. iki 2026-10-25 būsenos. Ką kiekviena data reiškia jūsų žurnalams ir patikroms.

Šaltinis: https://phpsos.de/lt/ratgeber/php2shell-chronologie/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

**Trumpai:** PHP2Shell chronologijoje kol kas yra keturios patvirtintos datos: pirmasis pastebėtas atakos bandymas spalio 17 d., išankstinis php.net pranešimas spalio 20 d., pataisos spalio 21 d. 16 val. Vokietijos laiku ir papildomas pranešimas apie CVE-2026-115560 2026-10-23. Operatoriams iš to išplaukia: pataisyti, iš naujo paleisti visus PHP procesus ir išsaugoti žurnalus bent nuo spalio 20 d.

## Kodėl PHP2Shell chronologija svarbi operatoriams

Esant tokio sunkumo pažeidžiamumui svarbu ne tik tai, ar jūsų serveris šiandien pataisytas. Lemiama ir tai, kiek laiko jis prieš tai buvo pažeidžiamas. Šis laikotarpis nustato, kuriuos žurnalus išsaugoti, kuriuos failus patikrinti ir ar galite pagrįstai atmesti kompromitavimą.

PHP2Shell paveikia patį PHP, o ne atskirą CMS. Du kritiniai pažeidžiamumai, CVE-2026-109618 ir CVE-2026-109619, leidžia nuotoliu vykdyti kenkėjišką kodą be prisijungimo. Abu įvertinti CVSS v4.0 9,2 balo. Suprantamą įvadą rasite puslapyje [Kas yra PHP2Shell?](https://phpsos.de/lt/php2shell/was-ist-php2shell/).

Toliau pateiktoje chronologijoje yra tik tos datos, kurios 2026-10-25 yra patvirtintos. Kur duomenys remiasi žiniasklaidos pranešimais, tai nurodyta.

| Data | Įvykis | Pagrindas |
|---|---|---|
| 2026-10-17 | Pirmasis pastebėtas atakos bandymas (Amazon) | Žiniasklaidos pranešimai |
| 2026-10-20 | Išankstinis php.net pranešimas | php.net |
| 2026-10-21, 14:00 UTC | Pataisų išleidimas (16 val. Vokietijos laiku) | php.net |
| 2026-10-23 | Pranešimas apie CVE-2026-115560 | php.net |
| 2026-10-25 | Šios apžvalgos būsena | – |

## Spalio 17 d.: pirmasis pastebėtas atakos bandymas

Pasak žiniasklaidos pranešimų, 2026-10-17 buvo pastebėtas pirmasis atakos bandymas, apie kurį pranešė Amazon. Tai įvyko keturiomis dienomis prieš pataisas. Taigi buvo laikotarpis, kai atakos jau buvo mėginamos, bet atnaujinimo dar nebuvo.

Ar ir kiek atakų šiuo laikotarpiu buvo sėkmingos, neįrodyta. Svarbi pasekmė jūsų pačių patikrai: šiandien pataisytas serveris galėjo būti kompromituotas anksčiau. Pataisa nepašalina įterptos kenkėjiškos programinės įrangos ir neįrodo, kad anksčiau nieko neįvyko.

## Spalio 20 ir 21 d.: išankstinis pranešimas ir pataisos

2026-10-20 PHP projektas php.net paskelbė apie būsimus saugumo atnaujinimus. 2026-10-21 14:00 UTC, t. y. 16 val. Vokietijos laiku, sekė ištaisytos versijos.

| Šaka | Paskutinė pažeidžiama versija | Ištaisyta versijoje |
|---|---|---|
| PHP 8.5 | 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.34 | 8.2.35 |

PHP 8.1 ir senesnėms versijoms oficialių atnaujinimų nebėra, yra tik minimalūs šaltinio kodo atgaliniai pataisų perkėlimai (backport) 7.4, 8.0 ir 8.1 versijoms. Pasak specializuotos spaudos, paveiktos beveik visos versijos iki pat PHP 5.4. Paveikti veikimo režimai: PHP-FPM, Apache su mod_php, php-cgi, FrankenPHP ir LiteSpeed. Didžiausią riziką PHP komanda mato mod_php atveju, kur exploit buvo parodytas dar prieš pradedant vykdyti programos kodą.

Distribucijos ir hostingo teikėjai kartais įdiegia atgalinius pataisų perkėlimus. Tuomet, pavyzdžiui, Plesk toliau rodo 8.2.34, nors serveris pataisytas. Lemia paketo būsena ir teikėjo patvirtinimas, o ne rodomas versijos numeris. Kaip tai tvarkingai patikrinti, aprašyta puslapyje [Kaip teisingai patikrinti PHP versiją ir pataisų būseną](https://phpsos.de/lt/php2shell/php-version-pruefen/).

## Spalio 23 d.: pranešimas apie CVE-2026-115560

2026-10-23 PHP projektas paskelbė dar vieną pranešimą, šį kartą apie CVE-2026-115560. Pagal jį išnaudoti galima tik esant neįprastai konfigūracijai: konfigūracijoje nustatytas serialize_handler `php_binary` arba `php_serialize`, programa prieš `session_start()` per `ini_set()` perjungia jį į `php`, o session upload progress yra aktyvus.

Pereinamoji priemonė paprasta, ir ją reikėtų nustatyti nepriklausomai nuo to, ar žinote, kad tokia padėtis pas jus yra:

```ini
; php.ini faile, FPM baseine arba serverio konfigūracijoje
; ne per ini_set() ar .user.ini
session.upload_progress.enabled = 0
```

Po to iš naujo paleiskite visus PHP darbinius procesus (worker). Visas saugumo pranešimas turėtų pasirodyti su kitu įprastu klaidų taisymo leidimu. Iki tol šis nustatymas lieka rekomenduojama pereinamąja priemone.

## Spalio 25 d.: padėtis ir atviri klausimai

BSI paskelbė 3 (oranžinį) įspėjimo lygį. Jis rekomenduoja nedelsiant atnaujinti, o jei to neįmanoma padaryti iš karto, laikinai atjungti žiniatinklio serverius nuo tinklo. BSI tikėjosi greito plataus masto išnaudojimo; patvirtintų sėkmingų atakų plačiu mastu, pasak BSI, iš pradžių nebuvo žinoma. BSI vertinimą apibendrina puslapis [Ką BSI rekomenduoja dėl PHP2Shell](https://phpsos.de/lt/compliance/bsi-empfehlungen/).

Cloudflare pranešė apie pastebėtus atakos bandymus ir pateikė apsaugos taisykles, bet įspėja, kad vien taisyklių pagal užklausos duomenis nepakanka. Palo Alto Networks (Unit 42) suskaičiavo daugiau kaip 22,6 milijono viešai pasiekiamų, potencialiai pažeidžiamų egzempliorių. Patvirtintų kompromitavimo indikatorių (IOC) nėra paskelbta; aptikimas remiasi elgsenos analize.

Kai kurie teikėjai atsargumo dėlei atjungė svetaines. Tai automatiškai nereiškia, kad tos svetainės buvo nulaužtos. Šios apžvalgos metu atviras lieka visų pirma klausimas, kiek serverių iš tikrųjų buvo kompromituota iki pataisos.

## Ką chronologija reiškia jūsų žurnalams ir patikroms

Iš datų išplaukia trys laikotarpiai: iki spalio 17 d., nuo spalio 17 d. iki jūsų pačių pataisymo ir paleidimo iš naujo momento bei po jo. Vidurinis laikotarpis yra kritinis. Kuo ilgiau jis truko pas jus, tuo kruopščiau reikėtų tikrinti.

> **Svarbu:**
> Specializuota spauda pataria serverio žurnalus saugoti nuo 2026-10-20. Kartu išsaugokite ir turimus senesnius žurnalus, kol jų neištrynė automatinė rotacija.

Paprastas būdas išsaugoti žurnalus nepakeistus ir užfiksuoti būseną:

```bash
# Žurnalus išsaugoti vienu archyvu (kelius pritaikykite savo sistemai)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Kontrolinė suma vėlesniam įrodymui
sha256sum /root/logs-sicherung-*.tar.gz
# Kiek laiko sistema laiko žurnalus?
grep -R "rotate" /etc/logrotate.d/
```

Be to, užsirašykite, kada tiksliai buvo įdiegtas atnaujinimas ir kada iš naujo paleisti PHP procesai. Vien naujų failų nepakanka, kol atmintyje dar veikia seni procesai. Kaip analizuoti išsaugotus žurnalus, aprašo vadovas [Kaip išanalizuoti žiniatinklio serverio žurnalus po atakos](https://phpsos.de/lt/ratgeber/logfiles-auswerten/).

## Kaip PHP SOS padeda konkrečiai?

- Kartu su jumis nustatome tikrąjį jūsų serverio pažeidžiamumo langą: paketo būseną, pataisymo momentą, visų darbinių procesų paleidimą iš naujo.
- Žurnalus ir sistemos būseną išsaugome patikrinamai, prieš ką nors keisdami.
- Tikriname, ar nėra elgsenos anomalijų, pavyzdžiui, naujų PHP failų, svetimų procesų ir neįprastų išeinančių ryšių.
- Rezultatą dokumentuojame taip, kad su juo galėtų dirbti vadovybė, duomenų apsaugos pareigūnai ir draudikai.

Išsamią eigą aprašo mūsų [PHP2Shell skubi pagalba](https://phpsos.de/lt/leistungen/php2shell-soforthilfe/).


## Dažni klausimai

**Kada buvo išleistos PHP2Shell pataisos?**  
PHP projektas ištaisytas versijas išleido 2026-10-21 14:00 UTC, t. y. 16 val. Vokietijos laiku. Ištaisytos PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35 versijos.

**Nuo kurios datos turėčiau saugoti serverio žurnalus?**  
Specializuota spauda pataria žurnalus saugoti nuo 2026-10-20. Kadangi, pasak žiniasklaidos pranešimų, pirmasis atakos bandymas buvo pastebėtas jau spalio 17 d., verta išsaugoti ir turimus senesnius žurnalus, kol jų neištrynė rotacija.

**Ar CVE-2026-115560 tokia pat pavojinga kaip pirmieji du pažeidžiamumai?**  
Pagal 2026-10-23 pranešimą, išnaudoti galima tik esant neįprastai sesijų konfigūracijai. Kaip pereinamoji priemonė nurodomas session.upload_progress.enabled=0, kol pasirodys kitas įprastas klaidų taisymo leidimas.

**Ar yra patvirtintų PHP2Shell kompromitavimo indikatorių (IOC)?**  
Ne, 2026-10-25 patvirtintų kompromitavimo indikatorių nėra paskelbta. Aptikimas remiasi elgsenos analize, pavyzdžiui, neįprastais procesais, naujais failais ir įtartinais ryšiais.

## Šaltiniai

- [php.net: saugumo pranešimai](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI (Vokietijos federalinė informacijos saugumo tarnyba)](https://www.bsi.bund.de/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)