PHP2Shell (CVE-2026-109618 ir CVE-2026-109619): ką dabar turėtų daryti PHP naudojančios įmonės

Technikas su nešiojamuoju kompiuteriu dirba prie serverių spintos

2026 m. spalio 21 d. PHP projektas išleido PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35, kurios ištaiso du pažeidžiamumus, galinčius „leisti neautentifikuotą nuotolinį kodo vykdymą“. Paprastai tariant: bet kam, kas gali nusiųsti HTTP užklausą į jūsų svetainę, gali pavykti jūsų serveryje paleisti savo kodą. Slaptažodžio tam nereikia, o kai kuriose konfigūracijose ataka suveikia dar prieš jūsų programai įvykdant bent vieną eilutę. Ši pažeidžiamumų pora pavadinta PHP2Shell, ir PHP abu įvertino 9,2 balo (CVSS 4.0, 10 balų skalėje).

Šis vadovas skirtas tiems, kam teks imtis veiksmų: PHP svetainių ir el. parduotuvių savininkams, IT vadovams ir visiems, kurių PHP sistemas valdo tiekėjas. Jis parašytas 2026 m. spalio 22 d., kitą dieną po leidimo, remiantis paties PHP projekto saugumo pranešimais, nacionalinių kibernetinio saugumo agentūrų rekomendacijomis ir tiekėjų paskelbtais skaičiais. Kur šaltiniai nesutaria, tai ir nurodome.

Trumpai

Atnaujinkite patį PHP, tada jį paleiskite iš naujo. WordPress, Drupal, Laravel ar įskiepio atnaujinimas šios problemos neišsprendžia. Spraga yra pačiame PHP, po jūsų programa.
Tai liečia kiekvieną PHP diegimą, kuris aptarnauja žiniatinklio užklausas, teigia PHP: PHP-FPM, Apache su mod_php, php-cgi, FrankenPHP ir LiteSpeed. Didžiausią riziką PHP priskiria Apache su mod_php.
Beveik pusė PHP svetainių veikia su šaka, kuriai PHP projektas nebeišleidžia naujų versijų (tai mūsų W3Techs duomenų interpretacija, žr. toliau). Joms nėra oficialaus paketo, kurį būtų galima įdiegti.
Nustatymai ir užkardos suteikia laiko, bet ne saugumo. PHP pateikia laikinų priemonių sąrašą ir teigia, kad jos „nepadaro diegimo saugaus“.
Jei šiandien negalite įdiegti pataisų, JAV, JK ir ES agentūros pataria tą patį: atjunkite sistemą nuo interneto, kol galėsite tai padaryti.

Kas įvyko, eilės tvarka

2026 m. rugpjūčio 19 d. Pasak Wiz paskelbtos informacijos, jos tyrėjai aptinka pirmąją iš spragų, o rugpjūčio 24 d. praneša apie jas PHP saugumo komandai. PHP saugumo pranešimuose kaip atradėjai nurodyti ir kelių kitų bendrovių tyrėjai.
Spalio 20 d. CVE numeriai likus dviem dienoms iki planuoto paskelbimo nuteka į internetą. PHP paankstina leidimą viena diena, į spalio 21 d. 14:00 UTC, ir ragina visus pasiruošti.
Spalio 21 d., 03:02 UTC. Cloudflare įjungia užkardos taisykles visiems klientams, naudojantiems jos WAF, įskaitant nemokamą planą. Vėliau bendrovė praneša, kad „pastebėjo atakų srautą, nukreiptą į mūsų klientus“, ir matė, kaip užpuolikai „keičia atakos naudingąją apkrovą, bandydami apeiti mūsų apsaugą“.
Spalio 21 d., apie 14:00 UTC. PHP paskelbia pataisas ir savo saugumo pranešimą. Tą pačią dieną JAV CISA, Jungtinės Karalystės NCSC, CERT-EU ir Europos Komisijos, ENISA, CERT-EU, Europolo bei ES nacionalinių CSIRT bendras pareiškimas ragina organizacijas nedelsiant įdiegti pataisas.

Kiek tai rimta?

Šį atvejį nuo įprastų kas mėnesį diegiamų pataisų skiria trys dalykai.

Užpuolikui tereikia užklausos. Jokio prisijungimo, ir niekam nereikia spustelėti nuorodos. PHP saugumo pranešime aprašomas pademonstruotas išnaudojimas Apache su mod_php aplinkoje, „kai neautentifikuota užklausa gali sukelti ataką dar prieš įvykdant bet kokį programos kodą“. Wiz pademonstravo atakas prieš dabartines WordPress, Drupal ir Joomla versijas ir pažymi, kad „net paprasta ‚Hello World‘ programa, veikianti su paveikta PHP versija, gali būti pažeidžiama“. Taip paleistas kodas turi žiniatinklio serverio paskyros teises, o daugumoje svetainių ši paskyra gali skaityti programos konfigūraciją: duomenų bazės slaptažodį, API raktus, pašto ir mokėjimų prisijungimo duomenis. Dėl antrosios spragos, CVE-2026-109619, PHP taip pat patvirtina atminties atskleidimą: duomenys iš serverio atminties nuteka į išorę net ir nepasiekus visiško kodo vykdymo.

Įdiegtų sistemų bazė milžiniška. Pasak W3Techs, PHP naudoja 69,3 proc. svetainių, kurių serverio pusės kalba žinoma (2026 m. spalio 22 d. duomenys). Palo Alto Networks padalinys Unit 42, remdamasis savo interneto skenavimu, suskaičiavo daugiau kaip 22,6 mln. iš interneto pasiekiamų egzempliorių, kurie potencialiai pažeidžiami, ir praneša, kad bent viena Europos vyriausybė atsargumo sumetimais išjungė savo svetainę.

Išnaudojimo kodas kuriamas sparčiai. CERT-EU praneša, kad pirmieji koncepcijos įrodymai (proof of concept) „pradėjo plisti“. Saugumo bendrovė watchTowr teigia, kad jos spąstų sistemos (honeypot) fiksuoja išnaudojimą nuo spalio 21 d. Cloudflare praneša apie atakų srautą. O Wiz teigia, kad jos tyrėjai viso darbo metu naudojo DI modelius, todėl vienas tyrėjas per savaitę atliko tai, kam „pasaulinio lygio komandai būtų prireikę mėnesių“. Užpuolikai, pritaikantys išnaudojimo kodą jūsų PHP versijai, turi tuos pačius įrankius.

Teisybės dėlei reikia paminėti ir kitą pusę: kai CISA spalio 21 d. paskelbė savo įspėjimą, ji nebuvo pastebėjusi išnaudojimo, ir nė viena spraga dar nebuvo įtraukta į jos Known Exploited Vulnerabilities (žinomų išnaudojamų pažeidžiamumų) katalogą. Red Hat problemai suteikė lygį „Important“ (svarbus), o ne kritinį, nes standartiniame Red Hat Enterprise Linux serveryje veikia PHP-FPM, kur išnaudoti sunkiau. Sunkiau nereiškia neįmanoma: PHP patvirtina, kad vienas antrosios spragos išnaudojimo kelias veikia ir su PHP-FPM. Niekas iš to nekeičia to, ką turėtumėte daryti. Keičiasi tik tai, kiek iš anksto būsite įspėti.

Kurią versiją naudojate? Skaičiai

W3Techs taip pat skelbia, kokias PHP versijas naudoja svetainės, skaičiuodama tas, kurios atskleidžia savo versiją. Sujungus dvi jos 2026 m. spalio 22 d. lenteles:

PHP šaka	PHP svetainių dalis	Pataisa iš PHP projekto
8.3, 8.4, 8.5	apie 34 proc.	Taip: 8.3.36, 8.4.27, 8.5.12
8.2	apie 18 proc.	Taip: 8.2.35. Tačiau pačios 8.2 palaikymas baigiasi 2026 m. gruodžio 31 d.
8.0, 8.1	apie 14 proc.	Leidimo nėra. 8.0 ir 8.1: tik atgalinė pirminio kodo pataisa (backport)
7.x	26,9 proc.	Leidimo nėra. 7.4: tik atgalinė pirminio kodo pataisa; 7.3 ir senesnės: nieko
5.x ir senesnės	7,8 proc.	Nieko

Taigi apie 48 proc. PHP svetainių veikia su šaka, kuriai PHP projektas neskelbia pataisyto leidimo, o dar 18 proc. pataisą gauna dabar, bet po dešimties savaičių neteks palaikymo.

Dvi išlygos. W3Techs mato tik tas svetaines, kurios rodo savo versiją. Be to, Linux distribucija galėjo pati užlopyti seną šaką: Ubuntu tai padarė, kaip matysite toliau. Vien versijos numeris nepasako, ar esate apsaugoti. Tai pasako jūsų tiekėjo paketo versija.

1 žingsnis: suraskite kiekvieną naudojamą PHP

Negalite įdiegti pataisų tam, ko nesate surašę, o PHP moka gerai pasislėpti. Jungtinės Karalystės NCSC prašo organizacijų surasti kiekvieną PHP sistemą, pirmiausia tas, kurios pasiekiamos iš interneto, ir priduria: „neapsiribokite pasenusių PHP versijų paieška“. ES bendrame pareiškime įspėjama, kad kai kuriems produktams „šie pažeidžiamumai gali turėti poveikio, net jei atrodo, kad jie tiesiogiai PHP nenaudoja“.

Kur ieškoti:

Svetainės ir el. parduotuvės: WordPress ir WooCommerce, Drupal, Joomla, Magento ir Adobe Commerce, Shopware, PrestaShop, TYPO3 ir viskas, kas sukurta su Laravel ar Symfony.
Pamirštos sistemos: kampanijų mikrosvetainės, sena kalbos versija, iš interneto pasiekiami bandomieji (staging) ir testavimo serveriai, prieš daugelį metų kieno nors įdiegtas žiniatinklio paštas ar pagalbos tarnybos sistema.
Konteineriai: kiekvienas atvaizdas, sukurtas iš php bazinio atvaizdo, turi savo PHP. Pagrindinio serverio atnaujinimas jam nieko nepakeičia.
Prieglobos valdymo skydeliai: cPanel, Plesk ir panašūs skydeliai šalia sisteminio PHP diegia savo PHP kompiliacijas. Kiekvieną skydelyje įjungtą versiją reikia atnaujinti atskirai.
Produktai su PHP viduje: specializuoti įrenginiai, stebėsenos įrankiai, CRM sistemos, pagalbos tarnybų sistemos ir tiekėjų administravimo sąsajos. Nyderlandų NCSC tvarko viešą tokių produktų sąrašą su jų būkle, kiekvieno tiekėjo atskirai.
Tiekėjai: jūsų prieglobos bendrovė, jūsų agentūra, bet kuri paslauga, kurioje, kaip žinote, veikia PHP. Paprašykite jų raštu nurodyti, kokios PHP versijos veikia jūsų sistemose ir kada jose bus įdiegtos pataisos.

Kiekvienai sistemai užsirašykite PHP versiją, kaip veikia PHP (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, konteineris), ar sistema pasiekiama iš interneto ir kas gali įdiegti pataisą.

2 žingsnis: diekite pataisas tinkama tvarka

Pradėkite nuo visko, kas pasiekiama iš interneto, o tarp šių sistemų pirmiausia imkitės Apache mod_php konfigūracijų.

Jei naudojate palaikomą šaką (nuo 8.2 iki 8.5). Atnaujinkite į 8.5.12, 8.4.27, 8.3.36 arba 8.2.35 arba į savo distribucijos paketą, kuriame yra pataisa. PHP teigia, kad Linux distribucijos pataisas gavo iš anksto. Kol kas patvirtinta:

Ubuntu: pataisyti paketai kiekvienam leidimui nuo 14.04 iki 26.10. Nuo 22.04 jie ateina su įprastais atnaujinimais; 20.04 ir senesniems leidimams reikia Ubuntu Pro prenumeratos, kuri nemokama iki penkių kompiuterių (Canonical pranešimas).
Debian: php8.4 8.4.27 skirtas Debian 13 (DSA-6574-1), o php8.2 8.2.35 skirtas Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: Red Hat saugumo biuletenyje RHSB-2026-013 nurodyti paketai kiekvienam leidimui.
Remi saugykla, plačiai naudojama naujesnėms PHP versijoms Red Hat šeimos sistemose: spalio 21 d. CERT-EU pažymėjo, kad leidimo dieną joje nebuvo paketų, ir patarė pereiti prie distribucijos paketų arba kompiliuoti iš pirminio kodo. Prieš ja pasikliaudami patikrinkite, ar ji jau pasivijo.

Jei naudojate PHP 7.4, 8.0 ar 8.1. PHP projektas šioms versijoms leidimų neskelbia. Jo saugumo komanda šioms trims šakoms parengė minimalias atgalines pirminio kodo pataisas, kurios padeda, jei PHP kompiliuojate patys. Kitu atveju pataisą turi pateikti jūsų tiekėjas (pavyzdžiui, Ubuntu Pro apima PHP 7.4 sistemoje Ubuntu 20.04) arba tenka pereiti prie naujesnės PHP versijos. CISA patarimas visiems, kurie naudoja 8.1 ar senesnę versiją ir negali jos atnaujinti, yra tiesmukas: atjunkite sistemą, kol joje bus įdiegta pataisa arba ji bus perkelta į naujesnę versiją.

Jei naudojate PHP 7.3 ar senesnę. PHP projektas nepateikia nieko. Jei jūsų kompiliacijos nebetaiso joks tiekėjas, belieka rinktis: pereiti prie naujesnės versijos arba atjungti sistemą.

Po atnaujinimo paleiskite iš naujo. Paketo įdiegimas nepakeičia jau veikiančio PHP. Ubuntu pranešime tai pasakyta paprastai: programą „greičiausiai reikėtų paleisti iš naujo“. Kiekviename serveryje iš naujo paleiskite PHP-FPM, Apache, LiteSpeed arba konteinerį. Tada patikrinkite versiją, kurią iš tikrųjų naudoja žiniatinklio serveris, o ne tik php -v komandinėje eilutėje, nes tai gali būti kita kompiliacija.

Konteineriai: iš naujo surinkite atvaizdus iš pataisyto bazinio atvaizdo ir vėl juos įdiekite. Atnaujintas pagrindinis serveris, kuriame veikia senas atvaizdas, vis tiek lieka pažeidžiamas.

Valdoma priegloba: paklauskite paslaugų teikėjo datos ir versijos, tada patikrinkite patys.

3 žingsnis: jei šiandien pataisų įdiegti negalite

PHP saugumo pranešime pateikiamos laikinos priemonės, o prieš jas įspėjama: jos „sumažina pažeidžiamumą tam tikrais atakos keliais, bet nepadaro diegimo saugaus“. Trumpai, tiems, kas prižiūri jūsų serverius:

Dėl CVE-2026-109618: nustatykite memory_limit=-1 taip, kad programa negalėtų šios reikšmės pakeisti (pavyzdžiui, su php_admin_value PHP-FPM telkinyje (pool) arba Apache konfigūracijoje); nustatykite mažą post_max_size (PHP siūlo 8M, jei failai neįkeliami, ir 32M, jei įkeliami); žiniatinklio serveryje arba tarpiniame serveryje (proxy) apribokite užklausos dydį, laukų skaičių ir multipart dalių skaičių; atminčiai riboti naudokite konteinerio ar cgroup ribą, niekada RLIMIT_AS ar RLIMIT_DATA.
Dėl CVE-2026-109619: nustatykite session.upload_progress.enabled=0 faile php.ini arba serverio konfigūracijoje (ne su ini_set() ir ne .user.ini faile) ir iš naujo paleiskite kiekvieną darbinį procesą (worker). PHP 8.5 versijoje taip pat nustatykite fatal_error_backtraces=0.

Du įspėjimai. Seanso nustatymas, kuris spalio 20 d. plačiai paplito, uždaro tik antrosios spragos atakos kelius, kaip atkreipė dėmesį PHP saugumo komandos narys; prieš pirmąją spragą jis nieko nepadeda. Be to, memory_limit=-1 panaikina paties PHP atminties ribą, todėl viena sunki užklausa dabar gali išsekinti serverio išteklius. Naudokite jį kartu su konteinerio ar cgroup riba.

Žiniatinklio programų užkarda (WAF) šiek tiek padeda. Cloudflare taisyklės pagal numatytuosius nustatymus įjungtos visuose planuose su jos WAF, įskaitant nemokamą, o Palo Alto Networks ir kiti tiekėjai paskelbė savo apsaugos priemones. Cloudflare vis tiek ragina klientus atnaujinti PHP „net ir turint WAF apsaugą“, ir ji matė, kaip užpuolikai keitė atakų naudingąją apkrovą (payload), kad prasprūstų pro jos taisykles. Be to, WAF apsaugo tik per ją einantį srautą. Jei jūsų serveris atsako ir tiesiogiai savo IP adresu, užpuolikas gali ją apeiti.

Jei nieko iš to greitai padaryti neįmanoma, CISA, CERT-EU, NCSC ir ES bendras pareiškimas rodo ta pačia kryptimi: atjunkite sistemą nuo viešojo interneto, kol ji bus sutvarkyta. Diena su techninių darbų puslapiu kainuoja mažiau nei iš naujo atkurtas serveris.

4 žingsnis: patikrinkite, ar į jūsų sistemas jau nebuvo įsilaužta

Pavojaus langas atsivėrė spalio 20 d., kai prasidėjo nutekėjimas, o apie atakų srautą pranešta jau kitą rytą. Jei sistema tuo laikotarpiu buvo pasiekiama ir be pataisų, pataisa uždaro duris, bet nepasako, ar kas nors nespėjo įeiti anksčiau. NCSC prašo visų, kurie negalėjo nedelsdami įdiegti pataisų, patikrinti, ar nėra kompromitavimo požymių ir užpakalinių durų (backdoor).

Ko ieškoti, remiantis paskelbtomis rekomendacijomis ir įprasta incidentų valdymo praktika:

PHP procesai, darantys tai, ko PHP niekada nedaro, pavyzdžiui, paleidžiantys komandų apvalkalą (shell) ar atsisiunčiantys įrankius (CISA).
Neįprastos multipart užklausos, po kurių seka atminties ribos klaidos ar pasikartojantys HTTP 500 atsakymai, be aiškios priežasties iš naujo pasileidžiantys PHP darbiniai procesai ir neįprastai dideli ar netaisyklingi PHPSESSID slapukai atsakymuose (Wiz).
Nauji ar pakeisti PHP failai įkėlimų ar podėlio aplankuose arba svetainės šakniniame kataloge (web root), naujos administratorių paskyros jūsų TVS ir suplanuotos užduotys, kurių niekas nesukūrė.

Švarūs žurnalai nėra įrodymas. PHP saugumo pranešime dėl antrosios spragos įspėjama būtent apie tai, o Wiz pažymi, kad programos žurnaluose gali būti mažai konteksto.

Jei ką nors randate, vertinkite tai kaip incidentą, o ne kaip pataisų diegimo užduotį. Izoliuokite serverį, išsaugokite įrodymus, pasitelkite incidentų valdymo paslaugų teikėją ir pakeiskite visas paslaptis, kurias galėjo perskaityti žiniatinklio serveris: duomenų bazių slaptažodžius, API raktus, mokėjimų ir pašto prisijungimo duomenis, pasirašymo raktus. Kadangi antroji spraga gali atskleisti atminties turinį, apsvarstykite galimybę pakeisti jautriausias iš šių paslapčių kiekviename serveryje, kuris kelias dienas buvo pasiekiamas ir be pataisų, net jei įsilaužimo požymių nėra.

5 žingsnis: apie ką gali tekti pranešti

Pats pažeidžiamumas nėra incidentas, apie kurį privaloma pranešti. Išnaudotas pažeidžiamumas juo gali būti.

NIS2: jei jūsų organizacija patenka į taikymo sritį, o įsilaužimas yra didelis incidentas, išankstinį įspėjimą jūsų nacionaliniam CSIRT reikia pateikti per 24 valandas. Žr. mūsų NIS2 vadovą.
BDAR: jei buvo gauta prieiga prie asmens duomenų, priežiūros institucijai reikia pranešti per 72 valandas nuo tada, kai sužinojote apie asmens duomenų saugumo pažeidimą, nebent mažai tikėtina, kad jis sukels pavojų žmonėms. Žr. mūsų BDAR vadovą.
Kibernetinio atsparumo aktas: jei parduodate programinę įrangą ar įrenginį su PHP viduje, pagal Kibernetinio atsparumo aktą esate jo gamintojas. Kaip primenama ES bendrame pareiškime, nuo 2026 m. rugsėjo 11 d. gamintojai privalo pranešti apie aktyviai išnaudojamus pažeidžiamumus savo produktuose per bendrą Kibernetinio atsparumo akto pranešimų teikimo platformą. Žr. mūsų Kibernetinio atsparumo akto vadovą.
Jūsų klientai: jei klientams teikiate PHP prieglobą arba valdote jų PHP sistemas, jie paklaus. Trumpas rašytinis pranešimas (ką naudojate, kada įdiegėte pataisas, ką patikrinote) atsako į daugumą klausimų, ir tai tas pats dokumentas, kurį norės pamatyti auditorius ar kibernetinio draudimo bendrovė.

Po krizės: ką pakeisti

Daugumoje gerai prižiūrimų serverių PHP2Shell spragos bus užlopytos per kelias dienas. Tai, ką jos atskleidė apie jūsų infrastruktūrą, liks aktualu ir vėliau.

Žinokite, kiek laiko jums užtrunka pataisų įdiegimas. Nuo saugumo pranešimo iki to, kai kiekvienas serveris paleistas iš naujo: valandos, dienos ar savaitės? Jei sąžiningas atsakymas yra „turėtume paklausti agentūros“, sutvarkykite tai, kol neatėjo kitas kartas. Kai tyrėjai teigia, kad DI sutrumpino jų išnaudojimo kodo kūrimą nuo mėnesių iki savaitės, laikykite, kad užpuolikai irgi gali veikti tokiu tempu.
Išlaikykite ką tik sudarytą sistemų sąrašą. Tai buvo sunkiausia reagavimo dalis, o sąrašas pasensta tą pačią akimirką, kai už jį niekas nebeatsako.
Atsisakykite PHP versijų, kurių palaikymas baigėsi. Svetainei su 7.4 ar 8.1 šį kartą reikėjo tiekėjo arba atgalinės pirminio kodo pataisos; kitą kartą gali nebūti nei vieno, nei kito. PHP 8.2 palaikymas baigiasi 2026 m. gruodžio 31 d., todėl svetainė, paliekanti 8.1, turėtų pereiti tiesiai prie 8.3 ar naujesnės versijos. Perėjimas prie naujesnės PHP versijos dažnai reiškia, kad reikia atnaujinti ir programą: mūsų straipsnyje apie Drupal, Umbraco ir Kentico palaikymo pabaigą parodyta, ką tai apima vienos TVS atveju.
Kur galite, rinkitės PHP-FPM, o ne mod_php. Šį kartą tai buvo mažesnės rizikos konfigūracija.
Jei įkėlimo eigos sekimo nenaudojate, palikite jį išjungtą. PHP saugumo pranešime siūloma session.upload_progress.enabled palikti išjungtą net ir įdiegus pataisą, jei programai jo nereikia.
Įrašykite pataisų diegimo terminus į sutartis. Paklauskite prieglobos paslaugų teikėjo ir agentūros, per kiek laiko jie įdiegia kritines PHP pataisas, ir gaukite atsakymą raštu.

Kontrolinis sąrašas šiai savaitei

Surašykite visus PHP diegimus, įskaitant konteinerius, valdymo skydelius, tiekėjų produktus ir bandomuosius (staging) serverius.
Pirmiausia įdiekite pataisas iš interneto pasiekiamose sistemose, pradėdami nuo Apache mod_php.
Iš naujo paleiskite kiekvieną PHP procesą ir patikrinkite versiją, kurią nurodo žiniatinklio serveris.
Iš naujo surinkite ir vėl įdiekite konteinerių atvaizdus.
Kur šiandien pataisų įdiegti negalite, pritaikykite PHP laikinus nustatymus, nukreipkite srautą per WAF arba atjunkite sistemą.
Paprašykite tiekėjų ir prieglobos paslaugų teikėjų raštu nurodyti jų PHP versiją ir pataisų įdiegimo datą.
Peržiūrėkite žurnalus ir failų pakeitimus visose sistemose, kurios nuo spalio 20 d. buvo pasiekiamos ir be pataisų.
Nuspręskite, ar jums taikoma pranešimo prievolė (NIS2, BDAR, Kibernetinio atsparumo aktas).
Suplanuokite, kaip atsisakysite PHP 8.1 ir senesnių versijų, o 8.2 atsisakysite iki gruodžio 31 d.

Kur galime padėti

Daugumai įmonių netrūksta noro įdiegti pataisas. Joms trūksta aiškaus vaizdo, ką jos naudoja, arba žmonių, kurie atliktų darbą šią savaitę. Būtent šią dalį mes ir perimame:

Inventorizacija ir pataisos per kelias dienas. Surandame jūsų PHP diegimus serveriuose, konteineriuose, prieglobos valdymo skydeliuose ir pas tiekėjus, įdiegiame pataisas, paleidžiame iš naujo ir patikriname, o jums paliekame rašytinį įrašą, kas ir kada padaryta. Tas įrašas yra ir jūsų atsakymas klientams bei auditoriams.
Perėjimas nuo seno PHP. Programos, įstrigusios ties PHP 7.x, 8.0 ar 8.1, nes kodas neveikia su jokia naujesne versija: jas perkeliame į palaikomą versiją, teikdami mūsų senųjų sistemų priežiūros paslaugą.
Sustiprinimas ir reguliari pataisų diegimo tvarka, kad kitas saugumo pranešimas būtų suplanuotas darbas, o ne skubi situacija.

Jei randate įsilaužimo požymių, pirmiausia kreipkitės į incidentų valdymo paslaugų teikėją. Kartu su juo galime perimti sistemų atkūrimą ir perėjimą prie naujesnės versijos.

Parašykite adresu office@c9group.dev, ką naudojate, ir atsakysime, ką darytume pirmiausia.

Šaltiniai

Patikrinta 2026 m. spalio 22 d. Padėtis vis dar kinta: ypač išnaudojimo būklė ir tiekėjų paketai nuo to laiko galėjo pasikeisti.

PHP projektas

Agentūros

Tyrėjai, tiekėjai ir duomenys