# Takoj zaprite ranljivost PHP

> Ranljivost PHP je še odprta? Popravimo na daljavo, znova zaženemo vse procese in dostavimo dokaz. Pokličite ali pišite po WhatsAppu, takoj ukrepamo.

Vir: https://phpsos.de/sl/soforthilfe/php-luecke-sofort-schliessen/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Kdor želi ranljivost PHP2Shell zapreti še danes, potrebuje štiri stvari: pravo posodobitev, ponovni zagon vseh procesov PHP, preverjanje že vnesene škodljive kode in dokaz. Ste prizadeti? Pokličite nas. Pomagamo. To prevzamemo na daljavo, od prvega sporočila.

> **Ukrepajte takoj:**
> **Zdaj ničesar ne brišite in ničesar ne postavljajte znova.** Tudi pri popravljanju velja: najprej zavarovati, nato spreminjati. Če je že kaj vdrlo, potrebujemo stanje datotek in dnevnikov. [Prijavite nujni primer](https://phpsos.de/sl/notfall/), z vami razjasnimo vrstni red.

## Zakaj ranljivost ne more čakati

Ranljivosti CVE-2026-109618 in CVE-2026-109619 sta v samem PHP-ju in omogočata izvedbo škodljive kode od daleč brez prijave. BSI je razglasil opozorilno stopnjo 3 (oranžna) in priporoča takojšnjo posodobitev. Če to ni takoj mogoče, naj se spletni strežniki začasno odklopijo z omrežja. Po poročilih medijev so bili prvi poskusi napadov opaženi že pred objavo popravkov 21. 10. 2026. Cloudflare je opazil poskuse in uvedel zaščitna pravila, vendar opozarja, da pravila samo na podlagi podatkov zahteve ne zadostujejo.

Pomembno za upravljavce: posodobitev CMS-ja ranljivosti PHP ne zapre. Tudi WordPress.org po poročilih ne načrtuje posodobitve proti njej, ker je ranljivost v interpreterju. Zapre se samo na ravni PHP, torej pri tem, kar vaš strežnik dejansko izvaja.

## Kaj storite takoj

1. **Poznajte ciljno različico.** Popravljene so PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35. PHP 8.2 31. 12. 2026 doseže konec podpore, to upoštevajte v načrtu.
2. **Zajemite vse sisteme.** Tudi testne strežnike, slike vsebnikov in stare sisteme, ki so dosegljivi z interneta.
3. **Razjasnite pristojnost.** Pri paketih gostovanja in upravljanih strežnikih posodobitev namesti ponudnik. Pisno vprašajte po različici in ponovnem zagonu.
4. **Ohranite dnevnike.** Od 20. 10. 2026 naprej, kot svetuje strokovni tisk.
5. **Uskladite okno.** Ponovni zagon za kratek čas prekine tekoče zahteve. Določite čas, ko lahko nekdo sprejema odločitve.
6. **Ne čakajte, če je odprto.** Če popravka ni mogoče namestiti takoj, z nami preverite izolacijo ali prehodne ukrepe.

## Kako konkretno pomaga PHP SOS?

1. **Ocena stanja:** Zajamemo sisteme, različice PHP, načine delovanja, ponudnike gostovanja in dosegljivost ter določimo vrstni red: najprej najbolj izpostavljeni sistemi.
2. **Zavarovanje in zapiranje:** Zavarujemo dejansko stanje, namestimo posodobitev ali gostovanje pripeljemo na dokazano popravljeno stanje in znova zaženemo vse procese. Pri vsebnikih znova zgradimo sliko in jo razmestimo.
3. **Preverjanje in čiščenje:** Ker popravek škodljive kode ne odstrani, preverimo znake zgodnejšega vdora in po potrebi očistimo.
4. **Utrjevanje in poročilo:** Prejmete pisni dokaz za vsak sistem in priporočila, da bo naslednja posodobitev potekala hitreje. Obseg storitve opisuje [storitev popravljanja PHP](https://phpsos.de/sl/leistungen/php-patch-service/).

## Posodobitev, ponovni zagon, dokaz: kaj šteje

Najpogostejša napaka je posodobitev brez ponovnega zagona. Dokler v pomnilniku tečejo stari procesi, ranljiva koda ostaja aktivna, tudi če so datoteke nove. Navodila so na strani [Ponovni zagon PHP-FPM in vseh delavcev](https://phpsos.de/sl/php2shell/php-fpm-neustart/). Druga napaka je verjeti prikazu: distribucije in ponudniki gostovanja pogosto dostavljajo povratne popravke, številka različice pa ostane enaka. Zanesljiv je dnevnik sprememb paketa s številkami CVE, v družini Debian z `apt-get changelog <paket>`.

Dodatno po priročniku PHP od varnostnih izdaj velja nova direktiva `memory_hard_limit_percent`. Če je različica PHP ne pozna, je prizadeta. Test je kratek:

```bash
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
```

Izvesti ga je treba za vsako različico in način delovanja, ker lahko ukazna vrstica uporablja drugo različico PHP kot spletni strežnik. Na koncu rezultat zabeležimo, da ga lahko pokažete svojemu ponudniku gostovanja, zavarovalnici ali naročniku.

## Če posodobitev ni takoj mogoča

Obstajajo razlogi, zakaj posodobitev danes ni mogoča: stara aplikacija, ki na novejših različicah PHP ne teče, ponudnik gostovanja brez odobritve, slika vsebnika v togem cevovodu. Za te primere php.net navaja prehodne ukrepe, ki izrecno niso popolna zaščita: nastavitev `memory_limit=-1` tako, da je aplikacije ne morejo prepisati, omejitev `post_max_size`, `session.upload_progress.enabled=0` in na PHP 8.5 `fatal_error_backtraces=0`, vsakič s ponovnim zagonom. K temu sodijo zaščitna pravila na robu, ki posodobitve ne nadomestijo. Krožeči nasvet, naj se blokirajo vse zahteve s `PHPSESSID`, strokovni avtorji izrecno zavračajo.

Kateri ukrepi ustrezajo vašemu sistemu in kaj lahko pokvarijo, razjasnimo vnaprej. Več o tem na strani [Takojšnji ukrepi, če popravka še ne morete namestiti](https://phpsos.de/sl/php2shell/sofortmassnahmen-ohne-patch/) in pri temi [WAF in virtualno popravljanje](https://phpsos.de/sl/leistungen/waf-virtuelles-patching/). Za PHP 8.1 in starejše velja poseben položaj, opisan na strani [PHP 8.1 in starejši: kaj velja zdaj](https://phpsos.de/sl/php2shell/php-8-1-und-aelter/).

## Kaj nam pošljite

- Seznam strežnikov in ponudnikov gostovanja, kolikor obstaja
- Izpis `php -v` za vsak sistem in navedba načina delovanja
- Podatek, ali se uporabljajo vsebniki, Plesk, cPanel ali upravljana ponudba
- Želeno časovno okno in kontaktna oseba za ponovne zagone
- Opažanja o nenavadnostih od 17. 10. 2026

## Zakaj PHP SOS

Delamo »Made in Germany« in smo s partnerskim omrežjem kibernetskih strokovnjakov že več kot 25 let specializirani za IT-varnost. Imate enega sogovornika, ki spremlja posodobitev, preveri ponovni zagon in dostavi dokaz. Delamo na daljavo, brez prihoda na kraj, in dokumentiramo vsak korak. Ne obljubljamo čudežev: popravek ranljivost zapre, ne dokazuje pa, da prej ni bilo nič narobe, in to vam tudi povemo.

## Ste prizadeti? Pokličite nas. Pomagamo.

Ranljivosti ne puščajte več odprte. Pokličite ali pišite po WhatsAppu. Prevzamemo že od prvega sporočila in ostanemo, dokler incident ni zaključen in dokumentiran. [Prijavite nujni primer zdaj](https://phpsos.de/sl/notfall/).


## Pogosta vprašanja

**Ali lahko ranljivost PHP zaprem sam ali potrebujem pomoč?**  
Posodobitev administratorji zmorejo, a je nagnjena k napakam: veljati mora različica, ki dejansko strežeta, in znova se morajo zagnati vsi procesi. Kdor ima več strežnikov, slike vsebnikov ali ponudnika gostovanja s posebnostmi, s podporo prihrani čas in napake.

**Ali je treba PHP po posodobitvi znova zagnati?**  
Da. Same nove datoteke ne zadostujejo, dokler v pomnilniku tečejo stari procesi PHP. Znova je treba zagnati vse delavce oziroma procese, pri mod_php pa spletni strežnik.

**Kaj storiti, če za mojo različico PHP posodobitve še ni?**  
Za PHP 8.1 in starejše projekt PHP ne izdaja več uradnih posodobitev. Takrat so potrebni dokazano popravljen povratni popravek ponudnika, selitev na vzdrževano različico ali prehodni ukrepi, ki pa ne nudijo popolne zaščite.

**Ali zadostuje, da session.upload_progress.enabled nastavim na 0?**  
Ne. Po strokovnih poročilih sama ta nastavitev ne zapre obeh ranljivosti, posodobitev PHP ostaja obvezna. Nastavite jo samo v php.ini, bazenu FPM ali konfiguraciji strežnika, ne z ini_set() ali .user.ini.

**Kako vem, da je ranljivost potem res zaprta?**  
Z dokazom na delujočem sistemu: različica ali dnevnik sprememb paketa, test za novo direktivo memory_hard_limit_percent in potrditev, da so bili po posodobitvi znova zagnani vsi procesi.

## Viri

- [php.net: varnostna obvestila](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [Priročnik PHP: jedrna konfiguracija (ini.core)](https://www.php.net/manual/en/ini.core.php)
- [BSI: nemški zvezni urad za informacijsko varnost](https://www.bsi.bund.de/)
