Kritinė PHP saugumo spraga (2026 m. spalis): ką daryti PrestaShop ir OpenCart savininkams

Marius, PHP programuotojas · Paskelbta 2026-10-21

2026 m. spalio 21 d. PHP projektas paskelbė saugumo pranešimą: išleistos PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35 versijos, kurios ištaiso dvi kritines spragas. Per jas užpuolikas gali nuotoliniu būdu vykdyti kodą serveryje net neprisijungęs prie svetainės. PHP projektas ragina visus PHP naudotojus atnaujinti nedelsiant.

PrestaShop, OpenCart ir daugelis kitų svetainių bei el. parduotuvių veikia PHP pagrindu, todėl šis pranešimas greičiausiai liečia ir Jūsų svetainę. Šiame straipsnyje paprastai paaiškinu, kas nutiko, kaip patikrinti savo PHP versiją, ko paklausti talpinimo paslaugų teikėjo ir ką daryti, jei svetainė vis dar veikia su sena PHP versija.

Kas nutiko

PHP projektas ištaisė dvi spragas. Abi įvertintos 9,2 balo pagal CVSS v4.0 (iš 10) – tai kritinis lygis. Abiem atvejais problema slypi pačiame PHP, o ne PrestaShop, OpenCart ar kitoje sistemoje, todėl sistemos ar modulių atnaujinimas šios spragos neišsprendžia – atnaujinti reikia PHP.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) – kodo vykdymas dėl atminties pažeidimo, kai PHP pritrūksta atminties. Atminties trūkumo apdorojimas gali nutraukti PHP darbą tuo metu, kai vidiniai užklausos duomenys dar tik iš dalies paruošti, o vėlesnis valymas gali palaikyti netinkamus duomenis tinkamais.

• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) – kodo vykdymas dėl likusios globalios būsenos. Užklausai priklausanti būsena gali išlikti ir po to, kai jos atmintis jau atlaisvinta, o vėlesnė užklausa tame pačiame PHP procese gali ją panaudoti.

Pasak php.net, buvo pademonstruotas išnaudojimo būdas, kai viena neprisijungusio lankytojo užklausa sukelia ataką dar prieš pradedant veikti bet kokiam svetainės kodui.

Kurias svetaines tai liečia

Pagal php.net, rizika kyla visoms PHP instaliacijoms, kurios aptarnauja interneto užklausas, įskaitant PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ir LiteSpeed. Didžiausia rizika – naudojant Apache mod_php: būtent šiuo atveju pademonstruota ataka, kuri suveikia dar prieš paleidžiant svetainės kodą.

Kitaip tariant, jei Jūsų PrestaShop, OpenCart ar kita PHP svetainė veikia su PHP versija, kurioje šios pataisos dar neįdiegtos, ji yra pažeidžiama. Pataisytos versijos:

• PHP 8.5 – 8.5.12 arba naujesnė;

• PHP 8.4 – 8.4.27 arba naujesnė;

• PHP 8.3 – 8.3.36 arba naujesnė;

• PHP 8.2 – 8.2.35 arba naujesnė.

PHP 8.1 ir senesnėms versijoms PHP projektas atnaujinimų neišleidžia (apie tai – žemiau). Linux distribucijos pataisas gavo iš anksto, todėl serveriuose, kuriuose PHP diegiamas iš distribucijos paketų, pataisa gali būti įdiegta ir nepakeitus pagrindinio versijos numerio. Dėl to versijos numeris ne visada parodo visą vaizdą – tokiu atveju geriausia pasitikslinti pas talpinimo paslaugų teikėją.

Kaip patikrinti savo PHP versiją

1. Talpinimo valdymo skydelyje. Daugumoje talpinimo paslaugų skydelių yra skiltis, kurioje matoma ir pasirenkama PHP versija (pvz., „PHP versija“ arba „Select PHP Version“). Atkreipkite dėmesį, kad skirtingiems domenams ar katalogams gali būti nustatytos skirtingos versijos.

2. PrestaShop administravime. PrestaShop rodo serverio PHP versiją skiltyje „Išplėstiniai parametrai“ → „Informacija“ (angl. Advanced Parameters → Information).

3. Laikinu phpinfo failu. Į svetainės katalogą įkelkite failą sunkiai atspėjamu pavadinimu su vienintele eilute <?php phpinfo();, atsidarykite jį naršyklėje ir pažiūrėkite versiją. Iškart po to failą ištrinkite – jame matyti daug serverio konfigūracijos detalių, kurių nereikia rodyti viešai. Ten pat, eilutėje „Server API“, matysite, kaip PHP paleidžiamas (pvz., FPM ar Apache 2.0 Handler, t. y. mod_php).

4. Paklauskite talpinimo paslaugų teikėjo. Tai patikimiausias būdas sužinoti ne tik versiją, bet ir tai, ar pataisa jau įdiegta.

Ko paklausti talpinimo paslaugų teikėjo

Jei svetainė talpinama bendrame (shared) talpinime, PHP atnaujina talpinimo paslaugų teikėjas. Trumpas laiškas su šiais klausimais padės greitai išsiaiškinti situaciją:

• Ar serveryje, kuriame veikia mano svetainė, PHP jau atnaujintas iki 8.5.12, 8.4.27, 8.3.36 ar 8.2.35, arba įdiegti distribucijos paketai su CVE-2026-109618 ir CVE-2026-109619 pataisomis?

• Ar pataisos įdiegtos visoms PHP versijoms, kurias galiu pasirinkti valdymo skydelyje?

• Kaip mano svetainėje paleidžiamas PHP – PHP-FPM, Apache mod_php, LiteSpeed ar kitaip?

• Ar po atnaujinimo perkrauti PHP procesai, kad iš tiesų veiktų nauja versija?

• Jei naudoju PHP 8.1 ar senesnę versiją: ar siūlote šios versijos saugumo pataisas, ar turėčiau pereiti prie naujesnės PHP versijos?

Jei turite savo serverį ir PHP diegiate iš rpms.remirepo.net saugyklos, atkreipkite dėmesį: php.net ragina pereiti prie distribucijos paketų arba kompiliuoti PHP iš išeities kodo, nes spalio 21 d. atnaujinimų šioje saugykloje nebuvo.

Ką daryti, jei naudojate PHP 8.1 ar senesnę versiją

PHP 8.1 ir senesnėms versijoms PHP projektas atnaujinimų neišleidžia. Kai kurios Linux distribucijos ir ilgalaikio palaikymo (LTS) tiekėjai pataisas perkelia į senesnes versijas patys, o tiems, kurie PHP kompiliuoja iš išeities kodo, php.net pateikė minimalias pataisas 7.4, 8.0 ir 8.1 versijoms. Daugumai svetainių savininkų vis dėlto tikrasis sprendimas – pereiti prie palaikomos PHP versijos.

Čia ir slypi dažniausia problema: senesnės PrestaShop ir OpenCart versijos gali neveikti su naujesne PHP versija. Net jei pati sistema veikia, nesuderinami gali būti moduliai ar tema – pavyzdžiui, mokėjimo, pristatymo ar prekių importo moduliai. Jei PHP versiją tiesiog perjungsite valdymo skydelyje, parduotuvė gali nustoti veikti arba dalis funkcijų sutriks nepastebimai.

Todėl rekomenduoju tokią tvarką:

1. pasidarykite visos svetainės ir duomenų bazės atsarginę kopiją;

2. išsiaiškinkite, kokia Jūsų PrestaShop ar OpenCart versija ir kokie moduliai bei tema įdiegti;

3. patikrinkite jų suderinamumą su naujesne PHP versija – geriausia svetainės kopijoje, o ne veikiančioje parduotuvėje;

4. pataisykite ar atnaujinkite nesuderinamus modulius, temą ar pačią sistemą;

5. tik tada perjunkite PHP versiją ir patikrinkite pagrindinius procesus: prekių paiešką, krepšelį, užsakymą, mokėjimą, laiškus, importus.

Renkantis naują versiją verta žinoti, kad PHP 8.2 palaikymas baigiasi 2026 m. gruodžio 31 d. Jei parduotuvė suderinama, verta iš karto rinktis naujesnę versiją, kad po kelių mėnesių nereikėtų to paties darbo kartoti.

Čia galiu padėti: patikrinu, ar Jūsų PrestaShop, OpenCart ar kita PHP svetainė, jos moduliai ir tema veiks su naujesne PHP versija, sutvarkau nesuderinamumus ir padedu saugiai pereiti prie naujos versijos.

Laikinos priemonės, jei atnaujinti iš karto negalima

Php.net nurodo kelias laikinas priemones, kurios sumažina riziką, bet svetainės saugia nepadaro. Vienintelis pilnas sprendimas – atnaujinti PHP. Šie nustatymai skirti serverio administratoriams; bendrame talpinime daugumos jų pats nepakeisite, tai talpinimo paslaugų teikėjo darbas.

• memory_limit=-1, nustatytas per php_admin_value, kad programa negalėtų jo pakeisti;

• mažas post_max_size (8M, jei failai neįkeliami, 32M – jei įkeliami), o upload_max_filesize – mažesnis už jį;

• užklausų dydžio ribos žiniatinklio serveryje ar tarpiniame serveryje (proxy);

• atminties riba konteineriui ar per cgroup (o ne per RLIMIT_AS ar RLIMIT_DATA);

• session.upload_progress.enabled=0 php.ini arba FPM pool konfigūracijoje (ne per ini_set ar .user.ini), po to perkraunant PHP procesus;

• PHP 8.5 versijoje – fatal_error_backtraces=0;

• neteisingų ar pasenusių (deprecated) nustatymų, keičiamų kiekvienos užklausos metu, pašalinimas;

• fatalinių klaidų ir laiko limitų viršijimų (timeouts), kuriuos gali sukelti užpuolikas, ištaisymas.

Klaidų slėpimas per error_reporting, display_errors ar operatorių @ nepadeda.

Įsilaužimo požymiai, į kuriuos verta atkreipti dėmesį

Atnaujinus PHP spraga užveriama, tačiau jei kas nors ja pasinaudojo anksčiau, jau įkeltas kenkėjiškas kodas savaime nedingsta. Todėl po atnaujinimo verta peržiūrėti, ar nėra šių požymių:

• nežinomi PHP failai svetainės kataloguose, ypač ten, kur jų neturėtų būti – nuotraukų, įkėlimų ar podėlio (cache) kataloguose;

• neseniai pakeisti failai, kurių niekas nekeitė, pvz., index.php, .htaccess ar sistemos branduolio failai;

• nežinomi administratoriai PrestaShop ar OpenCart administravime;

• lankytojų nukreipimai į šlamšto ar kitas svetimas svetaines, įterptas JavaScript kodas puslapiuose ar duomenų bazėje;

• nežinomos cron užduotys serveryje;

• neįprasta serverio apkrova, iš serverio siunčiami šlamšto laiškai ar talpinimo paslaugų teikėjo įspėjimai;

• keistos užklausos serverio žurnaluose (logs), ypač aplink tą laiką, kai prasidėjo kiti požymiai.

Jei pastebėjote bent vieną požymį, nieko neskubėkite trinti: pakeisti failai ir serverio žurnalai padeda nustatyti, kas ir kada nutiko. Tokiu atveju verta atlikti svetainės saugumo patikrą ir pakeisti administravimo, FTP bei duomenų bazės slaptažodžius.

Trumpai: ką daryti dabar

1. Patikrinkite, kokia PHP versija veikia Jūsų svetainėje.

2. Jei tai ne pataisyta versija – paprašykite talpinimo paslaugų teikėjo atnaujinti PHP arba atnaujinkite patys, jei turite savo serverį.

3. Jei naudojate PHP 8.1 ar senesnę versiją – planuokite perėjimą prie naujesnės versijos ir prieš tai patikrinkite parduotuvės, modulių ir temos suderinamumą.

4. Po atnaujinimo peržiūrėkite, ar nėra įsilaužimo požymių.

Šaltinis: php.net saugumo pranešimas „Security advisory: Critical remote code execution vulnerabilities, update now“ (2026-10-21). Straipsnis parengtas pagal 2026-10-21 turimą informaciją, naujausius duomenis rasite php.net.

Reikia pagalbos su PHP atnaujinimu ar saugumu?

Jei nesate tikri, kokia PHP versija veikia Jūsų parduotuvėje, ar ji bus suderinama su naujesne PHP versija, arba įtariate įsilaužimą – parašykite. Daugiau apie tai, ką darau, rasite puslapyje Svetainės saugumas: patikra ir nulaužtos svetainės valymas.

Parašykite, kokia sistema ir jos versija (PrestaShop, OpenCart ar kita), kokią PHP versiją matote ir kur talpinama svetainė. Atsakau per vieną darbo dieną.

Susisiekti

← Visi straipsniai

Turite klausimų dėl PrestaShop ar OpenCart modulių, prekių importo sprendimų, SilverStripe ar unikalių PHP programavimo darbų.

Parašykite man - atsakysiu ir padėsiu rasti geriausią sprendimą Jūsų verslui.