# Pavojingi klaidingi PHP2Shell patarimai, kurie šiuo metu plinta

> PHP2Shell patarimų faktų patikra: kurie plintantys patarimai neapsaugo ar net kenkia ir ką vietoj to rekomenduoja php.net, BSI ir specializuoti autoriai.

Šaltinis: https://phpsos.de/lt/blog/gefaehrliche-falschtipps/  
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:** Daugelis PHP2Shell patarimų, kurie šiuo metu plinta forumuose ir socialiniuose tinkluose, neapsaugo arba net kenkia: blokuoti užklausas su sesijos slapuku, slėpti klaidų pranešimus, nustatymus nustatyti per `.user.ini` arba atnaujinti tik CMS. php.net yra nedviprasmiškas: pilnų pereinamųjų priemonių nėra, PHP atnaujinimas su visų procesų paleidimu iš naujo yra vienintelis saugus kelias.

## Kodėl klaidingi patarimai tokioje padėtyje pavojingi

Kritinės spragos, sulaukiančios daug dėmesio, atveju atsiranda greitų sprendimų rinka. Patarimai dalijami, trumpinami ir perduodami toliau, dažnai be pirminio šaltinio apribojimų. Su PHP2Shell dar prisideda tai, kad detalės, pasak pranešimų, paaiškėjo dar prieš oficialų terminą, o pirmosiomis dienomis padėtis buvo neaiški.

Klaidingas patarimas kenkia dvigubai. Jis palieka spragą atvirą ir sukuria jausmą, kad kažkas padaryta. Būtent šis jausmas lemia, kad tikrasis atnaujinimas lieka nepadarytas. Kai kurie patarimai papildomai paralyžiuoja pačią svetainę.

## Devyni patarimai faktų patikroje

Toliau pateikta lentelė apibendrina tai, ką pastarosiomis dienomis dažnai skaitėme, ir sugretina su pirminių šaltinių teiginiais.

| Plintantis patarimas | Kodėl netinka | Kas galioja vietoj to |
|---|---|---|
| Blokuoti visas užklausas su `PHPSESSID` | Specializuotų autorių aiškiai atmestas; paralyžiuoja prisijungimus ir krepšelius | Atnaujinti PHP |
| `session.upload_progress.enabled=0` pakanka | Pasak specialistų pranešimų, neuždaro abiejų spragų | Prasminga pereinamoji priemonė, atnaujinimas lieka pareiga |
| Reikšmes nustatyti per `ini_set()` ar `.user.ini` | php.net aiškiai atkalbinėja | Serverio pusėje php.ini, FPM baseine ar serverio konfigūracijoje |
| Slėpti klaidų pranešimus | Pasak php.net, `error_reporting`, `display_errors` ar `@` nepadeda | Atnaujinimas; klaidų išvesties vis tiek viešai nerodyti |
| Atmintį riboti per `RLIMIT_AS` ar `RLIMIT_DATA` | php.net perspėja, kad būtent tai gali sukelti pažeidžiamą situaciją | Riba per konteinerį ar cgroup |
| Atnaujinti WordPress ar įskiepius | Spraga yra PHP interpretatoriuje, o ne CMS | Atnaujinti PHP vykdymo aplinką |
| Cloudflare ar kitos WAF pakanka | Apsauga tik srautui per paslaugą; tiesiogiai pasiekiami serveriai lieka atviri | WAF kaip papildomas sluoksnis, ne pakaitalas |
| Paslaugą perkrauti (reload), o ne paleisti iš naujo | Pasak Red Hat, perkrovimo (reload) nepakanka, esami worker gali išlaikyti senąją būseną | Visus worker visiškai paleisti iš naujo |
| Pataisyta reiškia švaru | Pataisa nepašalina anksčiau įterptos kenkėjiškos programinės įrangos | Žurnalus nuo 20.10. išsaugoti ir tikrinti dėl pėdsakų |

## Trys dažniausios klaidos išsamiau

### Slapukų draudimas

Patarimas atmesti visas užklausas su sesijos slapuku `PHPSESSID` skamba techniškai ir ryžtingai. Specializuoti autoriai jį aiškiai atmeta. Praktiškai jis sugriauna viską, kam reikia sesijos: klientų paskyras, krepšelius, administravimo zonas, formas su apsauga nuo klastojimo. Apsauga nuo spragos jis nėra.

### Vienas nustatymas, kuris viską išsprendžia

`session.upload_progress.enabled=0` yra php.net rekomendacijose ir yra nurodyta priemonė dėl CVE-2026-115560. Kai kuriuose straipsniuose iš to tapo „PHP2Shell išjungta“. Pasak specialistų pranešimų, vien šis nustatymas neuždaro abiejų spragų. Ir `memory_limit=-1`, pasak php.net, pašalina tik valdomą sukėlėją; gilesnio lygio atminties klaida vis tiek gali pasiekti pažeidžiamą kelią. Su PHP 8.5 `fatal_error_backtraces=0`, pasak php.net, blokuoja tik patvirtintą kelią per sekos pėdsakus (backtraces).

Kaip nustatymą vis tiek teisingai ir ilgam nustatyti, aprašo straipsnis [session.upload_progress išjungimas](https://phpsos.de/lt/blog/session-upload-progress-abschalten/). Pilną pereinamųjų priemonių sąrašą rasite skyrelyje [Skubios priemonės be pataisos](https://phpsos.de/lt/php2shell/sofortmassnahmen-ohne-patch/).

### Apsauginis skydas prieš tai

Cloudflare, pasak jos pačios, nuo spalio 21 d. turi įjungtas apsaugos taisykles, taip pat nemokamo plano klientams. Tačiau pati Cloudflare nurodo ribas: apsauga veikia tik srautui, einančiam per Cloudflare. Jei šaltinio serveris pasiekiamas tiesiogiai, ji apeinama. Be to, Cloudflare papildomai tikrina serverio atsakymą, nes vien užklausos ne visada pakanka. Kodėl WAF atnaujinimo nepakeičia, paaiškina straipsnis [WAF ar atnaujinimas](https://phpsos.de/lt/blog/waf-oder-update/).

## Patarimas su rizika: įkėlimo užklausų filtravimas pakraštyje

Ne kiekvienas nepatogus patarimas yra klaidingas. Specializuoti autoriai kaip laikiną, neoficialią priemonę siūlo `multipart/form-data` užklausas už tikrųjų įkėlimo kelių ribų blokuoti tarpiniame serveryje (proxy) ar WAF. Tai gali sumažinti atakos paviršių, bet sugriauna formas ir įkėlimus, jei leidžiamų kelių sąrašas neišsamus.

Kas šį kelią renkasi, turėtų jį iš anksto išbandyti bandomojoje aplinkoje, suderinti su skyriais ir dokumentuoti kaip terminuotą priemonę. Atnaujinimo pakaitalas ir ji nėra.

Daugelis WAF sprendimų tam siūlo stebėjimo režimą, kuriame taisyklės iš pradžių tik žurnalina, o ne blokuoja. Leiskite naujai taisyklei kelias dienas taip veikti ir įvertinkite, kurios teisėtos užklausos būtų paveiktos. Tik po to perjunkite į blokavimą. Taip išvengsite, kad nepastebimai nustotų veikti paraiškų formos, klientų portalai ar paveikslėlių įkėlimas parduotuvėje.

## Kaip patikrinti patarimą prieš jį taikant

Keturi klausimai atskiria naudingus patarimus nuo pavojingų:

1. **Šaltinis:** ar rekomendacija kyla iš php.net, jūsų distribucijos, BSI ar vardu įvardinto specializuoto autoriaus?
2. **Pretenzija:** ar priemonė aprašoma kaip pereinamoji, ar kaip sprendimas? Su PHP2Shell sprendimas yra tik atnaujinimas.
3. **Šalutinis poveikis:** kas sulūžta, kai priemonė suveikia? Patarimas be nuorodos į šalutinį poveikį yra neišsamus.
4. **Įgyvendinimo vieta:** ar nustatymas nustatomas serverio pusėje ir taip, kad nebūtų perrašomas, po to paleidžiant iš naujo visus worker?

> **Svarbu:**
> Užfiksuokite, kokias pereinamąsias priemones kada nustatėte. Taip galėsite jas vėliau tikslingai peržiūrėti ir atpažinti, ar tariama apsauga nepaaiškino tikrojo atnaujinimo.

## Kaip PHP SOS padeda konkrečiai?

- Patikriname priemones, kurios pas jus jau įgyvendintos, ir atskiriame veiksmingas nuo neveiksmingų.
- Įdiegiame PHP atnaujinimą, iš naujo paleidžiame visus procesus ir įrodome būklę.
- Kur atnaujinimas dar neįmanomas, pereinamąsias priemones pagal php.net taikome serverio pusėje ir dokumentuotai.
- Su [WAF ir virtualiu pataisymu](https://phpsos.de/lt/leistungen/waf-virtuelles-patching/) papildome apsaugą pakraštyje, nepakeisdami atnaujinimo.


## Dažni klausimai

**Ar apsaugo užklausų su PHPSESSID blokavimas?**  
Ne. Specializuoti autoriai šį plintantį patarimą aiškiai atmeta. Jis paralyžiuoja prisijungimus, krepšelius ir formas, neuždarydamas spragos interpretatoriuje.

**Ar session.upload_progress.enabled=0 pakanka nuo PHP2Shell?**  
Ne. Nustatymas yra viena iš kelių pereinamųjų priemonių ir, pasak specialistų pranešimų, neuždaro abiejų spragų. Jis prasmingas, bet PHP atnaujinimo nepakeičia.

**Ar padeda išjungti display_errors?**  
PHP2Shell atveju ne. php.net nurodo, kad diagnostikos slėpimas per error_reporting, display_errors ar @ operatorių nepadeda. Gamyboje display_errors vis tiek turėtų būti išjungtas kitais pagrindais.

**Kaip atpažinti patikimą patarimą?**  
Patikimas patarimas nurodo savo šaltinį, aprašo ribas ir pereinamąsias priemones taip ir vadina. Kas žada, kad vienas nustatymas atnaujinimą daro nebereikalingu, su PHP2Shell klysta.

## Šaltiniai

- [php.net: saugumo pranešimai](https://www.php.net/)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [Dr. Web: PHP2Shell ir PHP versijos](https://www.drweb.de/php2shell-update-php-versionen/)
- [Cloudflare tinklaraštis](https://blog.cloudflare.com/)