Ukratko: Virtualno zakrpanje za PHP premošćuje vrijeme do instalacije pravog ažuriranja. Za to kombiniramo pravila web aplikacijskog vatrozida (WAF) s privremenim mjerama koje je php.net objavio za PHP2Shell i odmah utvrđujemo put do redovite zakrpe. Potpunu zaštitu to ne pruža, ali smanjuje rizik u prijelaznom razdoblju.
Kada je virtualno zakrpanje za PHP smisleno
BSI (njemački Savezni ured za sigurnost informacijske tehnologije) kod PHP2Shella preporučuje trenutačno ažuriranje, a ako to nije moguće, privremeno isključivanje web-poslužitelja s mreže. Za mnoge tvrtke ni jedno ni drugo nije odmah izvedivo: shop mora ostati dostupan, vlastiti razvoj prije ažuriranja traži test ili poslužitelj radi s PHP-om 8.1 i starijim za koji više nema službenih ažuriranja.
U tim je slučajevima virtualno zakrpanje most. Ono ne zamjenjuje odluku bi li rad izvan mreže bio primjereniji. Tu procjenu donosite Vi, a mi isporučujemo tehničku ocjenu.
Zašto sam WAF nije dovoljan
Cloudflare je prijavio uočene pokušaje napada i uveo zaštitna pravila, ali upozorava da pravila samo na temelju podataka zahtjeva nisu dovoljna. Razlog je u prirodi ranjivosti. Kod CVE-2026-109618 stanje Out of Memory može prekinuti PHP dok su podaci zahtjeva tek djelomično inicijalizirani. Kod CVE-2026-109619 interno stanje može ostati nakon oslobađanja memorije i iskoristiti ga kasniji zahtjev u istom workeru. Takve pogreške ovise o stanju poslužitelja, a ne samo o sadržaju pojedinog zahtjeva.
Zato se oslanjamo na više slojeva: WAF pravila ispred poslužitelja, privremene mjere u samom PHP-u i pojačano promatranje poslužitelja. Svaki sloj zaustavlja dio napada, nijedan sam nije dovoljan. Zajedno Vam daju vrijeme da ažuriranje uredno instalirate.
Privremene mjere prema php.net-u
php.net navodi nekoliko postavki koje smanjuju rizik, izričito bez potpune zaštite. Važno je da aplikacije ne mogu nadjačati te vrijednosti. Primjer za PHP-FPM pool s prijenosima datoteka:
; Prijelazne mjere za PHP2Shell (nije potpuna zaštita), zatim ponovno pokrenuti sve workere
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; samo PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Bez prijenosa datoteka php.net preporučuje post_max_size = 8M. Budući da se memory_limit ukida, treba dodati ograničenje memorije na razini kontejnera ili cgroupa, a ne putem RLIMIT_AS ili RLIMIT_DATA. Postavka session.upload_progress.enabled=0 pripada u php.ini, FPM pool ili konfiguraciju poslužitelja, a ne u ini_set() ili .user.ini. Ona je ujedno i otklanjanje za napomenu o CVE-2026-115560. Sve mjere ukratko su na stranici Hitne mjere ako još ne možete zakrpati.
Privremene mjere djeluju tek nakon ponovnog pokretanja svih PHP workera. I štite samo od budućih napada: je li netko već prije upao, one ne odgovaraju.
Kada je rad izvan mreže bolji izbor
Virtualno zakrpanje nije u svakoj situaciji pravi odgovor. U nekim slučajevima savjetujemo slijediti BSI i privremeno isključiti web-poslužitelj s mreže dok se ne zakrpa:
- poslužitelj radi s Apacheom i mod_php, gdje PHP tim rizik ocjenjuje najvišim i gdje je prikazan exploit prije nego što se uopće izvrši kod aplikacije
- na poslužitelju se nalaze osobito zaštite vrijedni podaci, primjerice zdravstveni podaci, podaci klijenata ili podaci o plaćanju
- ne postoji mogućnost da se privremene mjere trajno postave u konfiguraciju poslužitelja, primjerice kod nekih paketa shared hostinga
- već postoje naznake da je poslužitelj napadnut
Privremeni rad izvan mreže ne znači da je Vaša web-stranica hakirana. Neki su pružatelji iz opreza isključili web-stranice. Kratka, stvarna stranica s obavijesti za posjetitelje tada je obično bolje rješenje od neobjašnjenog ispada.
Kako PHP SOS konkretno pomaže?
- Provjeriti stanje: Bilježimo verzije PHP-a, načine rada i postojeće zaštitne slojeve poput CDN-a, WAF-a ili reverse proxyja. Kod mod_php upozoravamo na povećani rizik koji PHP tim tamo vidi.
- Izgraditi slojeve: Aktiviramo ili dopunjujemo WAF pravila, privremene mjere trajno postavljamo u konfiguraciju poslužitelja i ograničavamo memoriju putem kontejnera ili cgroupa. Za Nginx postavke oslanjamo se na Osiguravanje Nginxa s PHP-FPM-om.
- Ponovno pokretanje i test: Svi PHP procesi se ponovno pokreću, nakon čega provjeravamo prijenose, obrasce, prijavu i blagajnu.
- Promatrati: U prijelaznom razdoblju pojačano pazimo na rušenja workera, skokove memorije i neuobičajene procese.
- Planirati zakrpu: Utvrđujemo kada i kako dolazi redovito ažuriranje i provodimo ga putem usluge PHP zakrpe.
Što dobivate, što trebamo i što ne obećavamo
Dobivate dokumentaciju svih postavljenih pravila i postavki s obrazloženjem, rezultate testova te plan termina i mjera za pravu zakrpu. Od Vas trebamo pristup poslužitelju ili panelu, pristup CDN-u ili WAF-u ako postoji, tehničku kontakt osobu i podatke o funkcijama prijenosa u Vašim aplikacijama.
Ne obećavamo da virtualno zakrpanje sprječava napad. Ono smanjuje rizik na ograničeno vrijeme. Kod PHP-a 8.1 i starijeg nije trajno stanje; tu na plan ide migracija na podržanu verziju.
Česta pitanja
Što je virtualno zakrpanje?
Virtualno zakrpanje znači zaštititi poznatu ranjivost ispred aplikacije umjesto da se mijenja sam kod. To se najčešće provodi putem web aplikacijskog vatrozida ili promjenama konfiguracije. To je premošćivanje, a ne zamjena za ažuriranje.
Je li WAF mog CDN pružatelja dovoljan protiv PHP2Shella?
Sam u pravilu nije. Cloudflare je uveo zaštitna pravila, ali i sam upozorava da pravila samo na temelju podataka zahtjeva nisu dovoljna. WAF je dodatni sloj uz privremene mjere i zakrpu.
Koliko dugo se smijem oslanjati na virtualno zakrpanje?
Što kraće moguće. Treba premostiti vrijeme do redovitog ažuriranja, primjerice dok se ne oslobodi prozor za održavanje ili dok se aplikacija ne testira. Kod PHP-a 8.1 i starijeg uz to ide i plan migracije.
Mogu li privremene mjere smetati mojoj web-stranici?
Da, to je moguće. Manja ograničenja prijenosa mogu spriječiti prijenos velikih datoteka, a isključivanje Session Upload Progressa pogađa prikaze napretka pri prijenosu. Najvažnije funkcije testiramo nakon svake promjene.