# Po PHP2Shell: kodėl tolesni pranešimai tikėtini

> Po PHP2Shell tolesni PHP pranešimai tikėtini. Iš ko tai atpažinti, kuriuos šaltinius stebėti ir kaip jūsų komanda gali pasirengusi sureaguoti.

Šaltinis: https://phpsos.de/lt/blog/weitere-php-meldungen/  
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:** Po PHP2Shell tolesni PHP pranešimai tikėtini, nes jau po dviejų dienų nuo pataisos pasirodė trečias pranešimas, pilnas saugumo pranešimas dar laukiamas, o distribucijos savo paketus pateikia etapais. Kas dabar nustato aiškią stebėjimo, vertinimo, atnaujinimo ir paleidimo iš naujo eigą, į kitą naują PHP saugumo spragą sureaguoja per valandas, o ne per dienas.

## Pataisa nebuvo istorijos pabaiga

2026 m. spalio 21 d. PHP projektas abi kritines spragas CVE-2026-109618 ir CVE-2026-109619 uždarė versijomis 8.5.12, 8.4.27, 8.3.36 ir 8.2.35. Daugelis atsakingų asmenų po to padėjo varnelę. Bet po dviejų dienų, spalio 23 d., sekė dar vienas php.net pranešimas dėl CVE-2026-115560.

Šis trečias pranešimas liečia tik neįprastą sesijos konfigūraciją. Tačiau jis rodo šabloną, žinomą iš didelių saugumo atvejų: kai komponentas staiga atsiduria dėmesio centre, daugelis specialistų kartu žiūri atidžiau. Ar iš to atsiras daugiau spragų, šiandien niekas nežino. Tačiau tikėtina, kad naujienų srautas nenutrūks.

Jums kaip operatoriui tai reiškia: numatykite tolesnius pranešimus, užuot buvę nustebinti kiekvieno. Iki šiol vykusių įvykių eigą apibendrina mūsų [PHP2Shell chronologija](https://phpsos.de/lt/ratgeber/php2shell-chronologie/).

## Kodėl tolesni pranešimai tikėtini

Toliau pateiktas vertinimas remiasi viešai žinomais faktais. Tai nėra konkrečių spragų prognozė.

1. **Saugumo pranešimas dar laukiamas.** php.net CVE-2026-115560 tvarko įprastu leidimų ciklu ir paskelbė, kad pilną saugumo pranešimą (advisory) paskelbs su kitu leidimu. Iki tol kaip priemonė galioja `session.upload_progress.enabled=0`.
2. **Detalės buvo viešos anksti.** Pasak kelių pranešimų, detalės paaiškėjo nesibaigus embargui. Pasak pranešimų, watchTowr, pasak jų pačių, CVE-2026-109618 atkūrė. Tokie darbai dažnai sukelia tolesnius klausimus dėl gretimų kodo vietų.
3. **Distribucijos pateikia etapais.** Ubuntu spalio 21 d. su USN-8948-1 aprūpino aktualius leidimus, o su USN-8948-2 taisymus 14.04–20.04 vėliau pateikė per Ubuntu Pro. Red Hat savo biuletenyje rašė, kad dalis atnaujinimų prieinama, kiti rengiami.
4. **Paveikta kūrimo versija.** Pasak php.net, taisymus turi ir PHP 8.6.0 RC4. Kas bando išankstines versijas, turi atnaujinti ir šias aplinkas.
5. **Senos versijos lieka atviros.** PHP 8.1 ir senesnėms yra tik minimalūs šaltinio atgaliniai perkėlimai (backport). Kiekvienas teikėjas, kuris tokias versijas pateikia, apie savo būseną praneša savarankiškai ir savo laiku.

## Kaip nauja PHP saugumo spraga jus pasiekia

Pranešimai ateina skirtingais keliais ir su skirtingu patikimumu. Eilė beveik visada ta pati: pirmiausia PHP projektas, paskui distribucijos ir talpintojai, po to institucijos ir žiniasklaida.

| Šaltinis | Ką ten sužinote | Kiek patikima |
|---|---|---|
| php.net | Paveiktos šakos, ištaisytos versijos, pereinamosios priemonės | Pirminis šaltinis |
| Ubuntu, Debian, Red Hat | Paketų būsena pagal leidimą, pateikimo laikas | Pirminis šaltinis jūsų sistemai |
| Talpintojai ir valdymo skydelių teikėjai | Savų PHP kūrinių būsena | Įpareigoja tik raštu |
| BSI, CERT-Bund | Padėties vertinimas, įspėjimo lygis, rekomendacijos | Institucinis vertinimas |
| Specializuota spauda ir saugumo įmonės | Atakų stebėjimai, skaičiai, kontekstas | Naudinga, žymėti kaip pranešimą |

Svarbus skirtumas tarp „pataisa yra“ ir „mano sistema turi pataisą“. Pirmasis teiginys yra php.net. Antrąjį kiekvienam serveriui turite įrodyti patys.

> **Patarimas:**
> Prenumeruokite php.net ir savo distribucijos pranešimus per RSS ar el. pašto sąrašą ir nukreipkite juos į bendrą pašto dėžutę ar kanalą, kurį skaito daugiau nei vienas asmuo. Atostogos ir ligos yra dažniausios vėluojančių atnaujinimų priežastys.

## Ką paruošti prieš kitą pranešimą

PHP2Shell patirtis rodo, kur prarandamas laikas: ieškant serverių, aiškinantis atsakomybes ir pamirštant paleisti iš naujo. Viską tai galima atlikti iš anksto.

- **Inventorius:** visų serverių ir svetainių sąrašas su PHP šaka, veikimo režimu (PHP-FPM, mod_php, LiteSpeed) ir paketų šaltiniu. Be šio sąrašo kiekvienas pranešimas prasideda paieška. Kaip tai pasiekti, aprašo straipsnis [Visų svetainių ir serverių inventorius](https://phpsos.de/lt/blog/inventar-websites-server/).
- **Atsakomybė:** kiekvienai sistemai nustatyta, kas taiso, kas paleidžia iš naujo ir kas patvirtina. Talpintojų ir agentūrų atveju tai priklauso sutarčiai.
- **Vertinimo schema:** pirmam įvertinimui pakanka trijų klausimų. Ar mūsų šaka paveikta? Ar naudojame paveiktą funkciją ar veikimo režimą? Ar yra pataisa, ar tik pereinamosios priemonės?
- **Bandymo kelias:** bandomoji aplinka (staging), kurioje PHP atnaujinimą galima patikrinti per trumpą laiką.
- **Įrodymas:** nuolatinis formatas, kuriame fiksuojama paketų būsena, pakeitimų žurnalo atitikmenys ir paleidimo iš naujo laikas.

Kaip tokia eiga veikia kaip rutina, o ne gaisrininkų darbas, aprašyta skyrelyje [Pataisų valdymas kaip procesas](https://phpsos.de/lt/blog/patch-management-prozess/). Foną apie PHP projekto elgesį su spragomis pateikia puslapis [Kaip PHP projektas tvarko saugumo spragas](https://phpsos.de/lt/php/php-sicherheitsprozess/).

## Sava konfigūracija kaip išankstinio įspėjimo sistema

Dalis tolesnių pranešimų liečia tik tam tikrus nustatymus. CVE-2026-115560 yra to pavyzdys: php.net kaip sąlygą nurodo, kad programa vykdymo metu perjungia sesijos serializatorių, kol aktyvus įkėlimo eigos sekimas (upload progress). Programos, kurios to niekada nedaro, pasak php.net, nepaveiktos.

Kas žino savo veikiančią konfigūraciją, tokius pranešimus gali greičiau įvertinti. Todėl kiekvienai šakai užfiksuokite, kurios reikšmės nustatytos serverio pusėje ir kurios programos jas gali perrašyti. Jau padeda paprastas aktyvių nustatymų palyginimas:

```bash
# Veikiančios komandinės eilutės reikšmės (žiniatinklio konfigūracija gali skirtis)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"

# Nustatytos reikšmės FPM baseinuose (kelias skirtingose distribucijose skiriasi)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
```

Komandinė eilutė būtinai nerodo, kas galioja žiniatinklio kontekste. Aiškumą suteikia baseino ar VirtualHost konfigūracija ir, trumpam ir apsaugotai, phpinfo puslapis.

Dar vienas pranašumas: kas žino, kurios pereinamosios reikšmės dar nustatytos iš PHP2Shell savaitės, po kito įprasto leidimo gali jas sąmoningai peržiūrėti. Kai kurie nustatymai, pavyzdžiui, išjungtas įkėlimo eigos sekimas, gali ilgam likti prasmingi. Kitus, pavyzdžiui, labai griežtas įkėlimų ribas, pasitarę su skyriais turėtumėte vėl pritaikyti prie tikrojo poreikio.

## Kaip PHP SOS padeda konkrečiai?

- Sekame php.net, distribucijų ir BSI pranešimus ir naujus nurodymus įvertiname jūsų konkrečioms sistemoms.
- Su jumis sudarome visų PHP diegimų inventorių ir nustatome atsakomybes kiekvienam serveriui.
- Pagal [saugumo priežiūros sutartį](https://phpsos.de/lt/leistungen/security-wartungsvertrag/) įdiegiame atnaujinimus, iš naujo paleidžiame visus procesus ir dokumentuojame būklę.
- Esant pranešimams be pataisos taikome pereinamąsias priemones, kurių programos negali perrašyti, ir jas patikriname.


## Dažni klausimai

**Ar po PHP2Shell jau yra nauja PHP saugumo spraga?**  
2026 m. spalio 23 d. php.net paskelbė pranešimą apie CVE-2026-115560. Pagal jį kodo vykdymas galimas tik esant neįprastai sesijos konfigūracijai. Pilnas saugumo pranešimas (advisory) turėtų pasirodyti su kitu įprastu leidimu.

**Ar po kiekvieno naujo pranešimo turiu reaguoti nedelsdamas?**  
Ne kiekvienas pranešimas reikalauja tokio pat skubumo. Lemia sunkumo laipsnis, jūsų konfigūracijos paveikimas ir tai, ar pataisa prieinama. Nustatyta eiga padeda tai įvertinti per minutes, o ne per dienas.

**Kur pirmiausia sužinau apie naujas PHP spragas?**  
Pirminiai šaltiniai yra php.net pranešimai ir jūsų distribucijos saugumo nurodymai, pavyzdžiui, Ubuntu Security Notices, Debian Security Tracker ar Red Hat. BSI informuoja įspėjimo pranešimais. Žiniasklaidos pranešimai naudingi, bet dažnai vėlesni ir mažiau tikslūs.

**Kodėl distribucijos kartais praneša dienomis vėliau nei php.net?**  
Distribucijos taisymą turi perimti į savo paketus, sukompiliuoti ir išbandyti. Senesniems leidimams tai gali užtrukti ilgiau arba įvykti tik per papildomus pasiūlymus. Todėl verta abu šaltinius sekti atskirai.

## Šaltiniai

- [php.net: pranešimai ir saugumo nurodymai](https://www.php.net/)
- [Ubuntu Security Notice USN-8948-2](https://ubuntu.com/security/notices/USN-8948-2)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [BSI](https://www.bsi.bund.de/)