PHP2Shell (CVE-2026-109618 un CVE-2026-109619): kas tagad jādara uzņēmumiem, kuri izmanto PHP

Tehniķis ar klēpjdatoru strādā pie serveru statnes

PHP projekts 2026. gada 21. oktobrī izlaida PHP 8.5.12, 8.4.27, 8.3.36 un 8.2.35, lai novērstu divas ievainojamības, kas „var ļaut attālināti izpildīt kodu bez autentifikācijas“. Vienkāršiem vārdiem: ikviens, kas spēj nosūtīt HTTP pieprasījumu jūsu tīmekļa vietnei, iespējams, var palaist jūsu serverī savu kodu. Parole nav vajadzīga, un dažās konfigurācijās uzbrukums nostrādā, pirms jūsu lietotne ir izpildījusi kaut vienu rindiņu. Šis ievainojamību pāris nosaukts par PHP2Shell, un PHP abas novērtē ar 9,2 (CVSS 4.0, skalā līdz 10).

Šis ceļvedis ir domāts tiem, kam jārīkojas: PHP tīmekļa vietņu un interneta veikalu īpašniekiem, IT vadītājiem un ikvienam, kam PHP darbina kāds piegādātājs. Tas uzrakstīts 2026. gada 22. oktobrī, dienu pēc laidiena, balstoties uz paša PHP projekta drošības paziņojumiem, valstu kiberdrošības iestāžu norādījumiem un uzņēmumu publicētajiem skaitļiem. Kur avoti nesaskan, mēs to norādām.

Īsumā

Atjauniniet pašu PHP un pēc tam to restartējiet. WordPress, Drupal, Laravel vai kāda spraudņa atjaunināšana to nenovērš. Ievainojamība ir PHP, zem jūsu lietotnes.
Tvērumā ir katra PHP instalācija, kas apkalpo tīmekļa pieprasījumus, norāda PHP: PHP-FPM, Apache ar mod_php, php-cgi, FrankenPHP un LiteSpeed. Par visaugstākā riska konfigurāciju PHP uzskata Apache ar mod_php.
Gandrīz puse PHP tīmekļa vietņu darbojas ar zaru, kam PHP projekts vairs neizdod laidienus (tā mēs lasām W3Techs datus, skatiet tālāk). Tām nav oficiālas pakotnes, ko instalēt.
Iestatījumi un ugunsmūri dod laiku, nevis drošību. PHP uzskaita pagaidu pasākumus un norāda, ka tie „nepadara instalāciju drošu“.
Ja šodien nevarat uzstādīt labojumus, ASV, Apvienotās Karalistes un ES iestādes dod vienu un to pašu padomu: atslēdziet sistēmu no interneta, līdz to varēsiet izdarīt.

Kas notika, pēc kārtas

2026. gada 19. augusts. Wiz pētnieki atrada pirmo no ievainojamībām, kā teikts viņu publikācijā, un 24. augustā par abām ziņoja PHP drošības komandai. PHP drošības paziņojumos minēti arī vairāku citu uzņēmumu pētnieki.
20. oktobris. CVE numuri noplūda internetā divas dienas pirms plānotās atklāšanas. PHP pārcēla laidienu par dienu agrāk, uz 21. oktobri plkst. 14:00 UTC, un aicināja visus sagatavoties.
21. oktobris, 03:02 UTC. Cloudflare ieslēdza ugunsmūra noteikumus visiem klientiem, kuriem ir tā tīmekļa lietotņu ugunsmūris (WAF), ieskaitot bezmaksas plānu. Vēlāk tas ziņoja, ka „novēroja uzbrukumu datplūsmu, kas vērsta pret mūsu klientiem“, un redzēja uzbrucējus „mainām uzbrukuma kravu, lai mēģinātu apiet mūsu aizsardzību“.
21. oktobris, ap 14:00 UTC. PHP publicēja labojumus un savu drošības paziņojumu. Tajā pašā dienā visi aicināja organizācijas nekavējoties uzstādīt labojumus: ASV CISA, Apvienotās Karalistes NCSC, CERT-EU un Eiropas Komisijas, ENISA, CERT-EU, Europol un ES valstu datordrošības incidentu reaģēšanas vienību (CSIRT) kopīgais paziņojums.

Cik tas ir nopietni?

Trīs lietas to atšķir no parastajiem ikmēneša labojumiem.

Uzbrucējam nevajag neko, izņemot pieprasījumu. Nav vajadzīga pieteikšanās, un nevienam nav jānoklikšķina uz saites. PHP drošības paziņojumā aprakstīta demonstrēta ievainojamības izmantošana pret Apache ar mod_php, „kur neautentificēts pieprasījums var iedarbināt uzbrukumu, pirms tiek izpildīts jebkāds lietotnes kods“. Wiz demonstrēja uzbrukumus pašreizējām WordPress, Drupal un Joomla versijām un norāda, ka „pat vienkārša ‚Hello World‘ lietotne, kas darbojas ar skartu PHP versiju, var būt ievainojama“. Šādi palaists kods iegūst tīmekļa servera konta tiesības, un lielākajā daļā vietņu ar tām var nolasīt lietotnes konfigurāciju: datubāzes paroli, API atslēgas, pasta un maksājumu piekļuves datus. Otrajai ievainojamībai, CVE-2026-109619, PHP apstiprina arī atmiņas satura noplūdi: dati no servera atmiņas noplūst uz āru arī bez pilnas koda izpildes.

Instalāciju skaits ir milzīgs. Saskaņā ar W3Techs PHP darbina 69,3 % no tīmekļa vietnēm, kuru servera puses valoda ir zināma (dati uz 2026. gada 22. oktobri). Palo Alto Networks vienība Unit 42, balstoties uz savu interneta skenēšanu, saskaita vairāk nekā 22,6 miljonus internetā pieejamu instanču, kas ir potenciāli ievainojamas, un ziņo, ka vismaz viena Eiropas valsts valdība piesardzības nolūkā atslēdza savu tīmekļa vietni.

Darbs pie ievainojamību izmantošanas virzās ātri. CERT-EU ziņo, ka pirmie koncepcijas pierādījumi (proof of concept) „ir sākuši izplatīties“. Drošības uzņēmums watchTowr saka, ka tā honeypot sistēmas kopš 21. oktobra fiksē ievainojamību izmantošanu. Cloudflare ziņo par uzbrukumu datplūsmu. Un Wiz saka, ka tā pētnieki visu laiku izmantoja mākslīgā intelekta modeļus, tāpēc viens pētnieks nedēļā paveica to, kas „pasaules klases komandai būtu prasījis mēnešus“. Uzbrucējiem, kas pielāgo uzbrukuma kodu jūsu PHP versijai, ir tie paši rīki.

Godīgības labad jāmin arī otra puse: kad CISA 21. oktobrī publicēja savu brīdinājumu, tā nebija novērojusi ievainojamību izmantošanu, un neviena no abām vēl nebija iekļauta tās Known Exploited Vulnerabilities (zināmu izmantotu ievainojamību) katalogā. Red Hat problēmu vērtē kā „Important“ (svarīga), nevis kritisku, jo standarta Red Hat Enterprise Linux serverī darbojas PHP-FPM, kurā ievainojamības izmantot ir grūtāk. Grūtāk nenozīmē neiespējami: PHP apstiprina, ka viens otrās ievainojamības izmantošanas ceļš darbojas arī ar PHP-FPM. Nekas no tā nemaina to, kas jums jādara. Tas maina tikai to, cik laikus jūs tiksiet brīdināti.

Kura versija ir jums? Skaitļi

W3Techs publicē arī to, kuras PHP versijas izmanto tīmekļa vietnes, skaitot tās vietnes, kas savu versiju atklāj. Apvienojot abas tā 2026. gada 22. oktobra tabulas:

PHP zars	Daļa no PHP tīmekļa vietnēm	Labojums no PHP projekta
8.3, 8.4, 8.5	aptuveni 34 %	Jā: 8.3.36, 8.4.27, 8.5.12
8.2	aptuveni 18 %	Jā: 8.2.35. Taču paša 8.2 atbalsts beidzas 2026. gada 31. decembrī
8.0, 8.1	aptuveni 14 %	Nav laidiena. 8.0 un 8.1: tikai pirmkoda backport
7.x	26,9 %	Nav laidiena. 7.4: tikai pirmkoda backport; 7.3 un vecākām: nekas
5.x un vecākas	7,8 %	Nekas

Tātad aptuveni 48 % PHP tīmekļa vietņu darbojas ar zaru, kam PHP projekts nepublicē laidienu ar labojumu, un vēl 18 % labojumu saņem tagad, bet pēc desmit nedēļām zaudē atbalstu.

Divas atrunas. W3Techs redz tikai tās vietnes, kas rāda savu versiju. Un Linux distribūcija var būt pati salabojusi vecu zaru: Ubuntu tā ir darījusi, kā redzēsiet tālāk. Versijas numurs vien nepasaka, vai esat aizsargāti. To pasaka jūsu piegādātāja pakotnes versija.

1. solis: atrodiet visas savas PHP instalācijas

To, kas nav sarakstā, nevar salabot, un PHP prot labi paslēpties. Apvienotās Karalistes NCSC aicina organizācijas atrast katru PHP sistēmu, vispirms tās, kas pieejamas no interneta, un piebilst: „neaprobežojiet meklēšanu ar novecojušām PHP versijām“. ES kopīgajā paziņojumā brīdināts, ka daži produkti „var būt skarti šo ievainojamību dēļ pat tad, ja šķiet, ka tie tieši neizmanto PHP“.

Kur meklēt:

Tīmekļa vietnes un veikali: WordPress un WooCommerce, Drupal, Joomla, Magento un Adobe Commerce, Shopware, PrestaShop, TYPO3, kā arī viss, kas veidots ar Laravel vai Symfony.
Aizmirstās sistēmas: kampaņu mikrovietnes, kāda veca valodas versija, pirmsprodukcijas (staging) un testa serveri, kas pieejami no interneta, tīmekļa pasts vai klientu atbalsta sistēma, ko kāds uzstādīja pirms gadiem.
Konteineri: katrs attēls, kas būvēts no php bāzes attēla, satur savu PHP. Resursdatora atjaunināšana tam neko nedod.
Mitināšanas vadības paneļi: cPanel, Plesk un līdzīgi paneļi līdzās sistēmas PHP piegādā savus PHP būvējumus. Katra panelī ieslēgtā versija ir jāatjaunina atsevišķi.
Produkti, kuros iekšā ir PHP: specializētas iekārtas, uzraudzības rīki, CRM sistēmas, klientu atbalsta sistēmas un piegādātāju administrēšanas saskarnes. Nīderlandes NCSC uztur publisku šādu produktu sarakstu ar to statusu, piegādātāju pa piegādātājam.
Piegādātāji: jūsu mitināšanas uzņēmums, jūsu aģentūra, jebkurš pakalpojums, par kuru zināt, ka tā pamatā ir PHP. Rakstiski pajautājiet, kuras PHP versijas darbina jūsu sistēmas un kad tām tiks uzstādīti labojumi.

Katrai pierakstiet PHP versiju, kā PHP darbojas (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, konteiners), vai tā ir pieejama no interneta un kas spēj tai uzstādīt labojumus.

2. solis: uzstādiet labojumus pareizā secībā

Sāciet ar visu, kas ir pieejams no interneta, un no tā vispirms ar Apache mod_php konfigurācijām.

Ja izmantojat atbalstītu zaru (8.2 līdz 8.5). Atjauniniet uz 8.5.12, 8.4.27, 8.3.36 vai 8.2.35 vai uz savas distribūcijas pakotni, kurā ir labojums. PHP norāda, ka Linux distribūcijas labojumus saņēma iepriekš. Līdz šim apstiprināts:

Ubuntu: pakotnes ar labojumu katrai versijai no 14.04 līdz 26.10. Versijās 22.04 un jaunākās tās pienāk ar parastajiem atjauninājumiem; versijās 20.04 un vecākās tām vajadzīgs Ubuntu Pro abonements, kas līdz piecām mašīnām ir bez maksas (Canonical paziņojums).
Debian: Debian 13 saņēma php8.4 8.4.27 (DSA-6574-1), Debian 12 saņēma php8.2 8.2.35 (DLA-4848-1).
Red Hat Enterprise Linux: Red Hat drošības biļetenā RHSB-2026-013 pakotnes uzskaitītas katrai versijai.
Remi repozitorijs, ko plaši izmanto jaunākām PHP versijām Red Hat saimes sistēmās: CERT-EU 21. oktobrī atzīmēja, ka laidiena dienā tajā nebija pakotņu, un ieteica pāriet uz distribūcijas pakotnēm vai būvēt no pirmkoda. Pirms uz to paļaujaties, pārbaudiet, vai tajā pakotnes jau ir parādījušās.

Ja izmantojat PHP 7.4, 8.0 vai 8.1. PHP projekts šiem zariem laidienu nepublicē. Tā drošības komanda trim zariem sagatavoja minimālus pirmkoda backport labojumus, kas noder, ja PHP kompilējat paši. Pretējā gadījumā labojumam jānāk no jūsu piegādātāja (piemēram, Ubuntu Pro aptver PHP 7.4 uz Ubuntu 20.04) vai no pārejas uz jaunāku PHP versiju. CISA padoms ikvienam, kam ir 8.1 vai vecāka versija un kas nevar atjaunināt, ir tiešs: atslēdziet sistēmu, līdz tai ir uzstādīti labojumi vai tā ir pārcelta uz jaunāku versiju.

Ja izmantojat PHP 7.3 vai vecāku. No PHP projekta nenāk nekas. Ja vien kāds piegādātājs joprojām nelabo jūsu būvējumu, izvēle ir pāreja uz jaunāku versiju vai sistēmas atslēgšana.

Pēc atjaunināšanas restartējiet. Pakotnes instalēšana neaizstāj jau strādājošo PHP. Ubuntu paziņojumā tas pateikts tieši: lietotne, „visticamāk, būtu jārestartē“. Restartējiet PHP-FPM, Apache, LiteSpeed vai konteineru katrā serverī. Tad pārbaudiet versiju, ko patiešām izmanto tīmekļa serveris, nevis tikai php -v komandrindā, jo tas var būt cits būvējums.

Konteineri: pārbūvējiet attēlus no bāzes attēla ar labojumu un izvietojiet tos no jauna. Resursdators ar labojumiem, kurā darbojas vecs attēls, joprojām ir pakļauts uzbrukumam.

Pārvaldītā mitināšana: pajautājiet pakalpojumu sniedzējam datumu un versiju, tad pārbaudiet paši.

3. solis: ja šodien nevarat uzstādīt labojumus

PHP drošības paziņojumā uzskaitīti pagaidu pasākumi, un tos ievada brīdinājums: tie „samazina pakļautību konkrētiem uzbrukuma ceļiem, bet nepadara instalāciju drošu“. Īsumā tiem, kas uztur jūsu serverus:

Pret CVE-2026-109618: iestatiet memory_limit=-1 tā, lai lietotne to nevarētu pārrakstīt (piemēram, ar php_admin_value PHP-FPM pūlā vai Apache konfigurācijā); iestatiet zemu post_max_size (PHP iesaka 8M, ja failu augšupielāde netiek izmantota, un 32M, ja tiek); ierobežojiet pieprasījuma izmēru, lauku skaitu un multipart daļas tīmekļa serverī vai starpniekserverī; un izmantojiet konteinera vai cgroup atmiņas ierobežojumu, nekad RLIMIT_AS vai RLIMIT_DATA.
Pret CVE-2026-109619: iestatiet session.upload_progress.enabled=0 failā php.ini vai servera konfigurācijā (nevis ar ini_set() vai .user.ini failu) un restartējiet visus worker procesus. PHP 8.5 iestatiet arī fatal_error_backtraces=0.

Divi brīdinājumi. Sesijas iestatījums, kas 20. oktobrī plaši izplatījās, aizver tikai otrās ievainojamības ceļus, kā norādīja PHP drošības komandas loceklis; pret pirmo tas neko nedara. Un memory_limit=-1 noņem PHP pašas atmiņas ierobežojumu, tāpēc viens smags pieprasījums tagad var izsmelt servera resursus. Apvienojiet to ar konteinera vai cgroup ierobežojumu.

Tīmekļa lietotņu ugunsmūris palīdz, bet tikai nedaudz. Cloudflare noteikumi pēc noklusējuma ir ieslēgti visos plānos ar tā WAF, ieskaitot bezmaksas plānu, un Palo Alto Networks un citi piegādātāji ir publicējuši savu aizsardzību. Cloudflare tomēr aicina klientus uzstādīt PHP labojumus „pat ar WAF aizsardzību“, un tas redzēja, kā uzbrucēji maina kravas, lai apietu tā noteikumus. Turklāt WAF aizsargā tikai to datplūsmu, kas iet caur to. Ja jūsu serveris atbild arī tieši uz savu IP adresi, uzbrucējs var WAF apiet.

Ja nekas no tā nav ātri izdarāms, CISA, CERT-EU, NCSC un ES kopīgais paziņojums norāda vienā virzienā: atslēdziet sistēmu no publiskā interneta, līdz tā ir salabota. Apkopes lapa uz vienu dienu izmaksā mazāk nekā no jauna pārbūvēts serveris.

4. solis: pārbaudiet, vai jums jau nav uzbrukts

Apdraudējuma logs atvērās 20. oktobrī, kad sākās noplūde, un par uzbrukumu datplūsmu ziņoja nākamajā rītā. Ja sistēma šajā laikā bija pieejama un bez labojumiem, labojumu uzstādīšana aizver durvis, bet nepasaka, vai kāds jau nav iegājis iekšā. NCSC aicina ikvienu, kurš nevarēja uzstādīt labojumus nekavējoties, pārbaudīt, vai nav kompromitēšanas pazīmju un sētas durvju.

Kam pievērst uzmanību, balstoties uz publicētajiem norādījumiem un ierasto incidentu apstrādes praksi:

PHP procesi, kas dara to, ko PHP nekad nedara, piemēram, palaiž čaulu (shell) vai lejupielādē rīkus (CISA).
Neparasti multipart pieprasījumi, kam seko atmiņas ierobežojuma kļūdas vai atkārtotas HTTP 500 atbildes, PHP worker procesi, kas restartējas bez skaidra iemesla, un neparasti lieli vai bojāti PHPSESSID sīkfaili atbildēs (Wiz).
Jauni vai mainīti PHP faili augšupielādes mapēs, kešatmiņas mapēs vai tīmekļa saknes mapē, jauni administratoru konti jūsu satura pārvaldības sistēmā un ieplānoti uzdevumi, ko neviens nav izveidojis.

Tīri žurnāli nav pierādījums. PHP drošības paziņojums par otro ievainojamību brīdina tieši par to, un Wiz norāda, ka lietotnes žurnālos var būt maz konteksta.

Ja kaut ko atrodat, uztveriet to kā incidentu, nevis kā labojumu uzstādīšanas darbu. Izolējiet serveri, saglabājiet pierādījumus, piesaistiet incidentu reaģēšanas pakalpojumu sniedzēju un nomainiet visus slepenos datus, ko tīmekļa serveris varēja nolasīt: datubāzes paroles, API atslēgas, maksājumu un pasta piekļuves datus, parakstīšanas atslēgas. Tā kā otrā ievainojamība var atklāt atmiņas saturu, apsveriet jutīgāko no šiem slepenajiem datiem nomaiņu jebkurā serverī, kas vairākas dienas bija pieejams un bez labojumiem, pat ja ielaušanās pazīmju nav.

5. solis: par ko jums, iespējams, jāziņo

Ievainojamība pati par sevi nav incidents, par kuru jāziņo. Izmantota ievainojamība var būt.

NIS2: ja jūsu organizācija ietilpst tvērumā un kompromitēšana ir nozīmīgs incidents, agrīnais brīdinājums jūsu valsts CSIRT jāiesniedz 24 stundu laikā. Skatiet mūsu NIS2 ceļvedi.
VDAR: ja ir piekļūts personas datiem, uzraudzības iestādei jāpaziņo 72 stundu laikā no brīža, kad uzzinājāt par pārkāpumu, ja vien nav maz ticams, ka tas rada risku cilvēkiem. Skatiet mūsu VDAR ceļvedi.
Kibernoturības akts: ja pārdodat programmatūru vai ierīci, kurā ir PHP, jūs saskaņā ar Kibernoturības aktu esat tās ražotājs. Kopš 2026. gada 11. septembra ražotājiem jāziņo par aktīvi izmantotām ievainojamībām savos produktos caur Kibernoturības akta vienoto ziņošanas platformu, kā atgādina ES kopīgais paziņojums. Skatiet mūsu Kibernoturības akta ceļvedi.
Jūsu klienti: ja mitināt vai darbināt PHP klientiem, viņi jautās. Īsa rakstiska piezīme (ko izmantojat, kad uzstādījāt labojumus, ko pārbaudījāt) atbild uz lielāko daļu jautājumu, un tā ir tā pati piezīme, ko gribēs redzēt auditors vai kiberapdrošinātājs.

Pēc ārkārtas situācijas: ko mainīt

Lielākajā daļā labi uzturētu serveru PHP2Shell labojumi būs uzstādīti dažu dienu laikā. Tas, ko šis gadījums atklāja par jūsu infrastruktūru, paliks spēkā arī pēc tam.

Ziniet, cik ilgi jums aizņem labojumu uzstādīšana. No drošības paziņojuma līdz brīdim, kad restartēts katrs serveris: stundas, dienas vai nedēļas? Ja godīgā atbilde ir „būtu jāpajautā aģentūrai“, sakārtojiet to pirms nākamā gadījuma. Ja pētnieki saka, ka mākslīgais intelekts saīsināja viņu darbu pie ievainojamības izmantošanas no mēnešiem līdz nedēļai, pieņemiet, ka uzbrucēji var rīkoties tikpat ātri.
Saglabājiet tikko izveidoto uzskaiti. Tā bija grūtākā reaģēšanas daļa, un tā noveco brīdī, kad par to vairs neviens neatbild.
Pārejiet no PHP versijām, kuru atbalsts beidzies. Vietnei ar 7.4 vai 8.1 šoreiz vajadzēja piegādātāju vai pirmkoda backport; nākamreiz var nebūt ne viena, ne otra. PHP 8.2 atbalsts beidzas 2026. gada 31. decembrī, tāpēc vietnei, kas pāriet no 8.1, jāiet uzreiz uz 8.3 vai jaunāku. PHP nomaiņa bieži nozīmē arī lietotnes atjaunināšanu: mūsu raksts par Drupal, Umbraco un Kentico atbalsta beigām parāda, ko tas ietver vienai satura pārvaldības sistēmai.
Kur iespējams, dodiet priekšroku PHP-FPM, nevis mod_php. Šoreiz tā bija mazāka riska konfigurācija.
Atstājiet augšupielādes progresu izslēgtu, ja to neizmantojat. PHP drošības paziņojumā ieteikts paturēt session.upload_progress.enabled izslēgtu arī pēc labojumu uzstādīšanas, ja lietotnei tas nav vajadzīgs.
Ierakstiet labojumu uzstādīšanas termiņus līgumos. Pajautājiet mitināšanas pakalpojumu sniedzējam un aģentūrai, cik ātri viņi uzstāda kritiskus PHP labojumus, un saņemiet atbildi rakstiski.

Kontrolsaraksts šai nedēļai

Uzskaitiet katru PHP instalāciju, ieskaitot konteinerus, vadības paneļus, piegādātāju produktus un pirmsprodukcijas serverus.
Vispirms uzstādiet labojumus sistēmām, kas pieejamas no interneta, sākot ar Apache mod_php.
Restartējiet katru PHP procesu un pārbaudiet versiju, ko norāda tīmekļa serveris.
Pārbūvējiet un no jauna izvietojiet konteineru attēlus.
Kur šodien nevarat uzstādīt labojumus, piemērojiet PHP pagaidu iestatījumus, novirziet datplūsmu caur WAF vai atslēdziet sistēmu.
Rakstiski pajautājiet piegādātājiem un mitināšanas pakalpojumu sniedzējiem, kāda ir viņu PHP versija un kad tiks uzstādīti labojumi.
Pārskatiet žurnālus un failu izmaiņas visā, kas kopš 20. oktobra bija pieejams un bez labojumiem.
Izlemiet, vai uz jums attiecas ziņošanas pienākums (NIS2, VDAR, Kibernoturības akts).
Plānojiet pāreju no PHP 8.1 un vecākām versijām, kā arī no 8.2 pirms 31. decembra.

Kur varam palīdzēt

Lielākajai daļai uzņēmumu netrūkst vēlēšanās uzstādīt labojumus. Tiem trūkst skaidra priekšstata par to, kas viņiem darbojas, vai cilvēku, kas šonedēļ paveiktu darbu. Šo daļu mēs uzņemamies:

Uzskaite un labojumi dažu dienu laikā. Mēs atrodam jūsu PHP instalācijas serveros, konteineros, mitināšanas paneļos un pie piegādātājiem, uzstādām labojumus, restartējam un pārbaudām, un atstājam jums rakstisku pierakstu par to, kas un kad izdarīts. Šis pieraksts ir arī jūsu atbilde klientiem un auditoriem.
Aiziešana no vecā PHP. Lietotnes, kas iestrēgušas uz PHP 7.x, 8.0 vai 8.1, jo kods nedarbojas ar neko jaunāku: mēs tās pārnesam uz atbalstītu versiju mūsu mantoto sistēmu uzturēšanas pakalpojuma ietvaros.
Nostiprināšana un regulāra labojumu uzstādīšanas kārtība, lai nākamais drošības paziņojums būtu ieplānots darbs, nevis ārkārtas situācija.

Ja atrodat ielaušanās pazīmes, vispirms zvaniet incidentu reaģēšanas pakalpojumu sniedzējam. Mēs varam paralēli ar viņiem uzņemties pārbūvi un pāreju uz jaunāku versiju.

Uzrakstiet uz office@c9group.dev, kas jums darbojas, un mēs atbildēsim, ar ko mēs sāktu.

Avoti

Pārbaudīts 2026. gada 22. oktobrī. Situācija joprojām mainās: īpaši ievainojamību izmantošanas statuss un piegādātāju pakotnes kopš tā laika var būt mainījušies.

PHP projekts

Iestādes

Pētnieki, uzņēmumi un dati