PHP2Shell (CVE-2026-109618 in CVE-2026-109619): kaj naj podjetja, ki uporabljajo PHP, storijo zdaj

Tehnik s prenosnikom pri delu na strežniški omari

21. oktobra 2026 je projekt PHP izdal PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35, ki odpravljajo dve ranljivosti, ki „lahko omogočita oddaljeno izvajanje kode brez preverjanja pristnosti“. Povedano preprosto: kdor koli zmore vašemu spletnemu mestu poslati zahtevo HTTP, bo morda na vašem strežniku lahko zagnal lastno kodo. Gesla ne potrebuje, pri nekaterih postavitvah pa napad deluje, še preden vaša aplikacija izvede eno samo vrstico. Par ranljivosti je dobil ime PHP2Shell, PHP pa obe ocenjuje z 9,2 (CVSS 4.0, na lestvici do 10).

Ta vodnik je za tiste, ki morajo ukrepati: lastnike spletnih mest in spletnih trgovin na PHP, vodje IT in vse, ki jim PHP poganja dobavitelj. Napisan je bil 22. oktobra 2026, dan po izdaji, na podlagi varnostnih obvestil samega projekta PHP, smernic nacionalnih agencij za kibernetsko varnost in številk, ki so jih objavili ponudniki. Kjer se viri razhajajo, to povemo.

Na kratko

Posodobite sam PHP in ga nato znova zaženite. Posodobitev WordPressa, Drupala, Laravela ali vtičnika tega ne odpravi. Ranljivost je v PHP, pod vašo aplikacijo.
Ranljivosti zadevata vsako namestitev PHP, ki streže spletne zahteve, navaja PHP: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP in LiteSpeed. Kot najbolj tvegano postavitev PHP označuje Apache z mod_php.
Skoraj polovica spletnih mest na PHP teče na veji, za katero projekt PHP ne objavlja več izdaj (po naši razlagi podatkov W3Techs, spodaj). Zanje uradnega paketa za namestitev ni.
Nastavitve in požarni zidovi kupijo čas, ne varnosti. PHP navaja začasne ukrepe in pravi, da „namestitve ne naredijo varne“.
Če popravka danes ne morete namestiti, agencije ZDA, Združenega kraljestva in EU svetujejo isto: sistem umaknite z interneta, dokler tega ne morete storiti.

Kaj se je zgodilo, po vrsti

19. avgusta 2026. Raziskovalci podjetja Wiz so po navedbah iz njihovega razkritja našli prvo od obeh ranljivosti, 24. avgusta pa so obe prijavili varnostni ekipi PHP. V varnostnih obvestilih PHP so kot najditelji navedeni tudi raziskovalci več drugih podjetij.
20. oktobra. Številki CVE sta dva dni pred načrtovanim razkritjem pricurljali na splet. PHP je izdajo prestavil za dan prej, na 21. oktober ob 14:00 UTC, in vse pozval, naj se pripravijo.
21. oktobra, 03:02 UTC. Cloudflare je v svojem požarnem zidu za spletne aplikacije (WAF) vklopil zaščitna pravila za vse stranke, ki ga uporabljajo, tudi za tiste z brezplačnim paketom. Pozneje je sporočil, da je „opazil napadalni promet, usmerjen na naše stranke“, in da so napadalci „spreminjali payload napada, da bi poskusili obiti našo zaščito“.
21. oktobra, okoli 14:00 UTC. PHP je objavil popravke in svoje varnostno obvestilo. Isti dan so ameriška CISA, britanski NCSC, CERT-EU in skupna izjava Evropske komisije, agencije ENISA, CERT-EU, Europola in nacionalnih CSIRT v EU organizacije pozvali, naj popravke namestijo takoj.

Kako resno je to?

Po treh stvareh se ta primer razlikuje od običajnega mesečnega popravka.

Napadalec ne potrebuje ničesar razen zahteve. Brez prijave, in nikomur ni treba klikniti na povezavo. Varnostno obvestilo PHP opisuje prikazano izkoriščanje na strežniku Apache z mod_php, „pri katerem lahko zahteva brez preverjanja pristnosti sproži napad, še preden se izvede kakršna koli koda aplikacije“. Wiz je prikazal napade na aktualne različice WordPressa, Drupala in Joomle ter opozarja, da je „lahko ranljiva celo preprosta aplikacija ‚Hello World‘, ki teče na prizadeti različici PHP“. Koda, zagnana na ta način, ima pravice računa spletnega strežnika, ta pa na večini spletnih mest lahko bere konfiguracijo aplikacije: geslo za bazo podatkov, ključe API, poverilnice za pošto in plačila. Pri drugi ranljivosti, CVE-2026-109619, PHP potrjuje tudi razkritje pomnilnika: podatki iz pomnilnika strežnika uhajajo navzven, tudi brez polnega izvajanja kode.

Namestitev je ogromno. Po podatkih W3Techs PHP poganja 69,3 % spletnih mest, katerih strežniški jezik je znan (podatki z dne 22. oktobra 2026). Unit 42 podjetja Palo Alto Networks na podlagi lastnega pregledovanja interneta šteje več kot 22,6 milijona izpostavljenih namestitev, ki so potencialno ranljive, in poroča, da je vsaj ena evropska vlada svoje spletno mesto iz previdnosti umaknila s spleta.

Razvoj kode za izkoriščanje hitro napreduje. CERT-EU poroča, da so prvi dokazi koncepta (proof of concept) „začeli krožiti“. Varnostno podjetje watchTowr pravi, da njegovi honeypoti od 21. oktobra beležijo izkoriščanje. Cloudflare poroča o napadalnem prometu. Wiz pa pravi, da so njegovi raziskovalci ves čas uporabljali modele UI, tako da je en raziskovalec v enem tednu opravil delo, ki bi „ekipi svetovnega razreda vzelo mesece“. Napadalci, ki kodo za izkoriščanje prilagajajo vaši različici PHP, imajo na voljo enaka orodja.

Pošteno je navesti tudi drugo plat: ko je CISA 21. oktobra objavila svoje opozorilo, izkoriščanja ni zaznala, nobena od ranljivosti pa še ni bila v njenem katalogu Known Exploited Vulnerabilities (znane izkoriščane ranljivosti). Red Hat težavo ocenjuje kot „pomembno“ (Important) in ne kot kritično, ker standardni strežnik Red Hat Enterprise Linux poganja PHP-FPM, kjer je izkoriščanje težje. Težje ne pomeni nemogoče: PHP potrjuje, da ena od poti za drugo ranljivost deluje tudi na PHP-FPM. Nič od tega ne spremeni, kaj morate storiti. Spremeni le, koliko opozorila boste dobili vnaprej.

Katero različico uporabljate? Številke

W3Techs objavlja tudi, katere različice PHP poganjajo spletna mesta, pri čemer šteje mesta, ki svojo različico razkrivajo. Če združimo njegovi dve tabeli z dne 22. oktobra 2026:

Veja PHP	Delež spletnih mest na PHP	Popravek projekta PHP
8.3, 8.4, 8.5	približno 34 %	Da: 8.3.36, 8.4.27, 8.5.12
8.2	približno 18 %	Da: 8.2.35. A veja 8.2 sama doseže konec življenjske dobe 31. decembra 2026
8.0, 8.1	približno 14 %	Brez izdaje. 8.0 in 8.1: samo backport v izvorni kodi
7.x	26,9 %	Brez izdaje. 7.4: samo backport v izvorni kodi; 7.3 in starejše: nič
5.x in starejše	7,8 %	Nič

Približno 48 % spletnih mest na PHP torej teče na veji, za katero projekt PHP ne objavlja izdaje s popravkom, nadaljnjih 18 % pa popravek dobi zdaj in podporo izgubi čez deset tednov.

Dve opozorili. W3Techs vidi samo spletna mesta, ki pokažejo svojo različico. Poleg tega je distribucija Linuxa staro vejo morda popravila sama: Ubuntu je to storil, kot boste videli spodaj. Sama številka različice ne pove, ali ste zaščiteni. To pove različica paketa vašega ponudnika.

1. korak: poiščite vsak PHP, ki ga uporabljate

Česar niste popisali, tega ne morete posodobiti, PHP pa se dobro skriva. Britanski NCSC organizacije prosi, naj poiščejo vsak sistem s PHP, najprej tiste, ki so dostopni z interneta, in dodaja: „iskanja ne omejite na zastarele različice PHP“. Skupna izjava EU opozarja, da so nekateri izdelki „lahko prizadeti zaradi teh ranljivosti, tudi če se zdi, da PHP ne uporabljajo neposredno“.

Kje iskati:

Spletna mesta in trgovine: WordPress in WooCommerce, Drupal, Joomla, Magento in Adobe Commerce, Shopware, PrestaShop, TYPO3 ter vse, kar je zgrajeno na Laravelu ali Symfonyju.
Pozabljeni sistemi: mikrostrani kampanj, stara jezikovna različica, predprodukcijski in testni strežniki, dostopni z interneta, spletna pošta ali sistem za podporo uporabnikom, ki ga je nekdo namestil pred leti.
Vsebniki: vsaka slika vsebnika, zgrajena na osnovni sliki php, nosi svoj PHP. Posodobitev gostitelja zanjo ne naredi ničesar.
Nadzorne plošče gostovanja: cPanel, Plesk in podobne plošče imajo poleg sistemskega PHP lastne gradnje PHP. Vsako različico, omogočeno v plošči, je treba posodobiti posebej.
Izdelki s PHP v notranjosti: namenske naprave, orodja za spremljanje, sistemi CRM, sistemi za podporo uporabnikom in skrbniški vmesniki ponudnikov. Nizozemski NCSC vodi javni seznam takih izdelkov z njihovim stanjem, za vsakega dobavitelja posebej.
Dobavitelji: vaš ponudnik gostovanja, vaša agencija, vsaka storitev, za katero veste, da pod njo teče PHP. Pisno jih vprašajte, katere različice PHP poganjajo vaše sisteme in kdaj bodo nameščeni popravki.

Za vsako namestitev zapišite različico PHP, kako PHP teče (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, vsebnik), ali je dostopna z interneta in kdo jo lahko posodobi.

2. korak: namestite popravke v pravem vrstnem redu

Začnite s tistim, kar je dostopno z interneta, znotraj tega pa s postavitvami Apache z mod_php.

Na podprti veji (8.2 do 8.5). Posodobite na 8.5.12, 8.4.27, 8.3.36 ali 8.2.35 ali na paket vaše distribucije, ki vsebuje popravek. PHP pravi, da so distribucije Linuxa popravke prejele vnaprej. Doslej potrjeno:

Ubuntu: popravljeni paketi za vse izdaje od 14.04 do 26.10. Na 22.04 in novejših prihajajo z običajnimi posodobitvami; na 20.04 in starejših potrebujejo naročnino Ubuntu Pro, ki je brezplačna za največ pet računalnikov (obvestilo podjetja Canonical).
Debian: php8.4 8.4.27 za Debian 13 (DSA-6574-1) in php8.2 8.2.35 za Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: varnostni bilten Red Hat RHSB-2026-013 navaja pakete za vsako izdajo.
Repozitorij Remi, ki se veliko uporablja za novejši PHP na sistemih iz družine Red Hat: CERT-EU je 21. oktobra ugotovil, da repozitorij na dan izdaje paketov ni imel, in svetoval prehod na pakete distribucije ali gradnjo iz izvorne kode. Preden se nanj zanesete, preverite, ali je medtem že nadoknadil zamudo.

Na PHP 7.4, 8.0 ali 8.1. Projekt PHP za te veje ne objavlja izdaje. Njegova varnostna ekipa je za vse tri veje pripravila minimalne backporte v izvorni kodi, ki pomagajo, če PHP prevajate sami. Sicer mora popravek priti od vašega ponudnika (Ubuntu Pro na primer pokriva PHP 7.4 na Ubuntu 20.04) ali z nadgradnjo PHP. Nasvet CISA za vse na 8.1 ali starejših, ki ne morejo posodobiti, je brez ovinkov: sistem umaknite s spleta, dokler ni popravljen ali nadgrajen.

Na PHP 7.3 ali starejšem. Od projekta PHP ne pride nič. Razen če kak ponudnik vaše gradnje še vedno popravlja, je izbira nadgradnja ali umik sistema s spleta.

Po posodobitvi znova zaženite. Namestitev paketa ne zamenja PHP, ki že teče. Obvestilo Ubuntuja to pove naravnost: aplikacijo „bo verjetno treba znova zagnati“. Na vsakem strežniku znova zaženite PHP-FPM, Apache, LiteSpeed ali vsebnik. Nato preverite različico, ki jo spletni strežnik dejansko uporablja, ne le php -v v ukazni vrstici, ki je lahko druga gradnja.

Vsebniki: slike znova zgradite na osnovni sliki s popravkom in jih ponovno namestite. Popravljen gostitelj, na katerem teče stara slika, je še vedno izpostavljen.

Upravljano gostovanje: ponudnika vprašajte za datum in različico, nato pa preverite še sami.

3. korak: če popravka danes ne morete namestiti

Varnostno obvestilo PHP navaja začasne ukrepe in jih uvede z opozorilom: „zmanjšajo izpostavljenost določenim potem napada, a namestitve ne naredijo varne“. Na kratko, za tistega, ki upravlja vaše strežnike:

Za CVE-2026-109618: nastavite memory_limit=-1 tako, da ga aplikacija ne more preglasiti (na primer s php_admin_value v poolu PHP-FPM ali v konfiguraciji Apache); nastavite nizek post_max_size (PHP predlaga 8M brez nalaganja datotek, 32M z nalaganjem); na spletnem strežniku ali posredniku (proxy) omejite velikost zahteve, število polj in število delov multipart; pomnilnik pa omejite na ravni vsebnika ali cgroup, nikoli z RLIMIT_AS ali RLIMIT_DATA.
Za CVE-2026-109619: nastavite session.upload_progress.enabled=0 v php.ini ali v konfiguraciji strežnika (ne z ini_set() ali datoteko .user.ini) in znova zaženite vse delovne procese. Na PHP 8.5 nastavite še fatal_error_backtraces=0.

Dve opozorili. Nastavitev seje, ki se je 20. oktobra množično širila, zapre samo poti druge ranljivosti, kot je opozoril član varnostne ekipe PHP; proti prvi ne naredi ničesar. Poleg tega memory_limit=-1 odstrani lastno omejitev pomnilnika v PHP, zato lahko zdaj ena sama obsežna zahteva izčrpa strežnik. Dopolnite jo z omejitvijo na ravni vsebnika ali cgroup.

Požarni zid za spletne aplikacije pomaga, a le malo. Cloudflarova pravila so privzeto vklopljena za vsak paket z njegovim WAF, tudi za brezplačnega, Palo Alto Networks in drugi ponudniki pa so objavili lastne zaščite. Cloudflare strankam kljub temu svetuje, naj PHP posodobijo „tudi z zaščito WAF“, sam pa je opazoval napadalce, ki so spreminjali payload, da bi se izmuznili njegovim pravilom. WAF poleg tega ščiti le promet, ki gre skozenj. Če je vaš strežnik dosegljiv na lastnem naslovu IP, ga lahko napadalec zaobide.

Če ničesar od tega ni mogoče narediti hitro, CISA, CERT-EU, NCSC in skupna izjava EU kažejo v isto smer: sistem umaknite z javnega interneta, dokler ni popravljen. En dan strani za vzdrževanje stane manj kot ponovno postavljen strežnik.

4. korak: preverite, ali je do vdora že prišlo

Okno se je odprlo 20. oktobra, ko se je začelo uhajanje, o napadalnem prometu pa so poročali naslednje jutro. Če je bil sistem v tem oknu dostopen in brez popravka, popravek zapre vrata, ne pove pa, ali je kdo vstopil pred tem. NCSC vse, ki popravka niso mogli namestiti takoj, prosi, naj poiščejo znake vdora in zadnja vrata (backdoor).

Kaj iskati, po objavljenih smernicah in običajni praksi obravnave incidentov:

Procesi PHP, ki počnejo stvari, ki jih PHP nikoli ne počne, na primer zaganjajo lupino ali prenašajo orodja (CISA).
Nenavadne zahteve multipart, ki jim sledijo napake zaradi omejitve pomnilnika ali ponavljajoči se odgovori HTTP 500, delovni procesi PHP, ki se brez jasnega razloga znova zaganjajo, in nenavadno veliki ali nepravilno oblikovani piškotki PHPSESSID v odgovorih (Wiz).
Nove ali spremenjene datoteke PHP v mapah za nalaganje, mapah predpomnilnika ali korenski mapi spletnega mesta, novi skrbniški računi v vašem CMS in načrtovana opravila, ki jih ni ustvaril nihče.

Čisti dnevniki niso dokaz. Varnostno obvestilo PHP za drugo ranljivost opozarja prav na to, Wiz pa ugotavlja, da dnevniki aplikacije morda vsebujejo le malo konteksta.

Če kaj najdete, to obravnavajte kot incident in ne kot nameščanje popravkov. Izolirajte strežnik, ohranite dokaze, vključite ponudnika odziva na incidente in zamenjajte vsako skrivnost, ki jo je spletni strežnik lahko prebral: gesla za baze podatkov, ključe API, poverilnice za plačila in pošto, ključe za podpisovanje. Ker lahko druga ranljivost razkrije pomnilnik, razmislite o zamenjavi najobčutljivejših med temi skrivnostmi na vsakem strežniku, ki je bil več dni izpostavljen in brez popravka, tudi če ni znakov vdora.

5. korak: kaj boste morda morali prijaviti

Ranljivost sama po sebi ni incident, ki ga je treba prijaviti. Izkoriščena ranljivost to morda je.

NIS2: če vaša organizacija spada pod direktivo in je vdor pomemben incident, morate zgodnje opozorilo nacionalnemu CSIRT poslati v 24 urah. Glejte naš vodnik po NIS2.
GDPR: če je kdo dostopal do osebnih podatkov, je treba nadzorni organ obvestiti v 72 urah od trenutka, ko ste za kršitev izvedeli, razen če ni verjetno, da bi kršitev ogrozila posameznike. Glejte naš vodnik po GDPR.
Cyber Resilience Act: če prodajate programsko opremo ali napravo, v kateri je PHP, ste po CRA njen proizvajalec. Od 11. septembra 2026 morajo proizvajalci aktivno izkoriščane ranljivosti v svojih izdelkih prijavljati prek enotne platforme za prijavo CRA, na kar opominja skupna izjava EU. Glejte naš vodnik po CRA.
Vaše stranke: če PHP gostite ali upravljate za naročnike, bodo vprašali. Kratko pisno obvestilo (kaj uporabljate, kdaj je bil nameščen popravek, kaj ste preverili) odgovori večini od njih, in to je isto obvestilo, ki ga bo želel videti revizor ali zavarovalnica kibernetskih tveganj.

Po izrednih razmerah: kaj spremeniti

Na večini dobro vodenih strežnikov bo PHP2Shell popravljen v nekaj dneh. Kar je razkril o vaši postavitvi, bo držalo tudi potem.

Vedite, koliko časa potrebujete za popravek. Od varnostnega obvestila do ponovnega zagona vsakega strežnika: ure, dnevi ali tedni? Če je pošten odgovor „morali bi vprašati agencijo“, to uredite pred naslednjim primerom. Ko raziskovalci pravijo, da jim je UI delo na kodi za izkoriščanje skrajšala z mesecev na teden, predpostavite, da lahko s takim tempom delajo tudi napadalci.
Ohranite popis, ki ste ga pravkar sestavili. Bil je najtežji del odziva, zastara pa v trenutku, ko zanj nihče ni odgovoren.
Opustite PHP, ki mu je potekla življenjska doba. Spletno mesto na 7.4 ali 8.1 je tokrat potrebovalo ponudnika ali backport v izvorni kodi; naslednjič morda ne bo na voljo ne enega ne drugega. PHP 8.2 doseže konec življenjske dobe 31. decembra 2026, zato naj spletno mesto, ki zapušča 8.1, preide neposredno na 8.3 ali novejšo različico. Prehod na novejši PHP pogosto pomeni tudi posodobitev aplikacije: naš članek o koncu življenjske dobe Drupala, Umbraca in Kentica pokaže, kaj to vključuje pri enem CMS.
Raje uporabljajte PHP-FPM kot mod_php, kjer je mogoče. Tokrat je bila to postavitev z manjšim tveganjem.
Če napredka nalaganja ne uporabljate, ga pustite izklopljenega. Varnostno obvestilo PHP predlaga, da session.upload_progress.enabled tudi po namestitvi popravka ostane izklopljen, kadar ga aplikacija ne potrebuje.
Roke za popravke zapišite v pogodbe. Ponudnika gostovanja in agencijo vprašajte, kako hitro namestita kritične popravke PHP, in odgovor zahtevajte pisno.

Kontrolni seznam za ta teden

Popišite vsako namestitev PHP, vključno z vsebniki, nadzornimi ploščami, izdelki ponudnikov in predprodukcijskimi strežniki.
Najprej posodobite sisteme, dostopne z interneta, začenši z Apache mod_php.
Znova zaženite vsak proces PHP in preverite različico, ki jo sporoča spletni strežnik.
Znova zgradite in ponovno namestite slike vsebnikov.
Kjer popravka danes ne morete namestiti, uporabite začasne nastavitve PHP, promet usmerite skozi WAF ali sistem umaknite s spleta.
Dobavitelje in ponudnike gostovanja pisno vprašajte za različico PHP in datum namestitve popravka.
Preglejte dnevnike in spremembe datotek na vsem, kar je bilo od 20. oktobra izpostavljeno in brez popravka.
Odločite, ali velja obveznost prijave (NIS2, GDPR, CRA).
Načrtujte prehod s PHP 8.1 in starejših ter z 8.2 pred 31. decembrom.

Kje lahko pomagamo

Večini podjetij ne manjka volje do nameščanja popravkov. Manjka jim jasna slika o tem, kaj uporabljajo, ali ljudje, ki bi delo opravili ta teden. Ta del prevzamemo mi:

Popis in popravki v nekaj dneh. Poiščemo vaše namestitve PHP na strežnikih, v vsebnikih, na ploščah gostovanja in pri dobaviteljih, jih posodobimo, znova zaženemo in preverimo, za sabo pa pustimo pisni zapis o tem, kaj je bilo narejeno in kdaj. Ta zapis je tudi vaš odgovor strankam in revizorjem.
Prehod s starega PHP. Aplikacije, ki so obtičale na PHP 7.x, 8.0 ali 8.1, ker koda na nobeni novejši različici ne teče: prenesemo jih na podprto različico v okviru naše storitve vzdrževanja podedovanih sistemov.
Utrjevanje in rutina nameščanja popravkov, da bo naslednje varnostno obvestilo načrtovano opravilo in ne izredne razmere.

Če najdete znake vdora, najprej pokličite ponudnika odziva na incidente. Ponovno postavitev in nadgradnjo lahko prevzamemo vzporedno z njim.

Pišite na office@c9group.dev in nam povejte, kaj uporabljate, odgovorili pa vam bomo, kaj bi naredili najprej.

Viri

Preverjeno 22. oktobra 2026. Stanje se še spreminja: zlasti stanje izkoriščanja in paketi ponudnikov so se od takrat morda spremenili.

Projekt PHP

Agencije

Raziskovalci, ponudniki in podatki