# Hitne mjere ako još ne možete zakrpati

> Zaobilazno rješenje za PHP ranjivost PHP2Shell: privremene mjere php.net-a, ispravno postavljene, s granicama i napomenama za put do zakrpe.

Izvor: https://phpsos.de/hr/php2shell/sofortmassnahmen-ohne-patch/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** Zaobilazno rješenje za PHP sigurnosnu ranjivost PHP2Shell može smanjiti rizik, ali ne zamjenjuje ažuriranje. php.net za to navodi čvrsta ograničenja memorije i prijenosa, isključivanje Session Upload Progressa i na PHP-u 8.5 `fatal_error_backtraces=0`. Ako ni to nije kratkoročno moguće, BSI (njemački Savezni ured za sigurnost informacijske tehnologije) preporučuje web-poslužitelj privremeno isključiti s mreže.

## Što zaobilazno rješenje može, a što ne

Privremene mjere php.net-a trebaju otežati uvjete pod kojima se ranjivosti CVE-2026-109618 i CVE-2026-109619 mogu iskoristiti. One izričito **nisu potpuna zaštita**. Ranjivosti su ispravljene samo u PHP-u 8.5.12, 8.4.27, 8.3.36 i 8.2.35 ili u potvrđenom backportu Vašeg pružatelja.

Mjere su smislene ako ažuriranje iz konkretnog razloga još nije moguće: prozor za održavanje tek slijedi, aplikaciju prvo treba testirati ili koristite PHP 8.1 ili stariji za koji više nema službenog ažuriranja. Tada su most, a ne cilj.

Zato uz zaobilazno rješenje istodobno planirajte i ažuriranje: tko ga provodi, u kojem prozoru za održavanje i tko poslije provjerava da su svi workeri ponovno pokrenuti? Prijelaz bez završnog datuma lako postaje trajno stanje.

## Opcija 1: poslužitelj privremeno isključiti s mreže

BSI je proglasio razinu upozorenja 3 (narančasta) i preporučuje pogođene web-poslužitelje privremeno isključiti s mreže ako ažuriranje nije odmah moguće. Neki su pružatelji to učinili iz opreza; to ne znači da su te stranice hakirane.

Za mnoge je tvrtke ispad shopa ili portala skup. Procjena može biti smislena: pristup samo putem VPN-a ili odobrenih IP adresa, statična stranica o održavanju umjesto PHP aplikacije ili isključivanje pojedinih nepotrebnih web-stranica na poslužitelju. Što je manje PHP-a dostupno izvana, to je manja površina napada.

Važno je odluku donijeti svjesno i zabilježiti je: tko je kada odlučio ostaviti poslužitelj na mreži i s kojim zaštitnim mjerama? To kasnije pomaže prema osiguravatelju, zaštiti podataka i upravi.

## Privremene mjere php.net-a

| Mjera | Vrijednost | Napomena |
|---|---|---|
| `memory_limit` | `-1`, bez mogućnosti nadjačavanja | ograničenje memorije tada postaviti putem kontejnera ili cgroupa |
| `post_max_size` | `8M` bez prijenosa, `32M` s prijenosima | `upload_max_filesize` ispod toga |
| Ograničenje memorije | putem kontejnera/cgroupa | ne putem `RLIMIT_AS` ili `RLIMIT_DATA` |
| `session.upload_progress.enabled` | `0` | u php.ini, poolu ili konfiguraciji poslužitelja, ne putem `ini_set()` ili `.user.ini` |
| `fatal_error_backtraces` | `0` | samo PHP 8.5 |

Postavka `session.upload_progress.enabled=0` ujedno je i mjera za ranjivost [CVE-2026-115560](https://phpsos.de/hr/php2shell/cve-2026-115560/) prijavljenu 23. listopada.

## Ispravno postaviti zaobilazno rješenje za PHP sigurnosnu ranjivost

Odlučujuće je mjesto. Vrijednosti moraju biti postavljene tako da ih aplikacija ne može nadjačati. Putanje i nazivi usluga razlikuju se po distribuciji; primjeri polaze od PHP-a 8.3.

**PHP-FPM, u poolu** (npr. `/etc/php/8.3/fpm/pool.d/www.conf`):

```ini
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; samo PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
```

**Apache s mod_php,** u konfiguraciji poslužitelja ili u VirtualHostu:

```apache
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
```

**Ograničenje memorije putem cgroupa,** ovdje preko systemd-a za FPM uslugu. Vrijednost prilagodite svom poslužitelju:

```ini
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
```

Zatim ponovno pokrenite sve workere, inače ništa od toga ne djeluje: `systemctl restart php8.3-fpm` ili kod mod_php Apache. Kako provjeriti da više ne radi nijedan stari proces, piše na stranici [Ponovno pokretanje PHP-FPM-a i svih workera](https://phpsos.de/hr/php2shell/php-fpm-neustart/). Opće ojačavanje konfiguracije opisuje [Sigurna konfiguracija php.ini](https://phpsos.de/hr/ratgeber/php-ini-sicher-konfigurieren/).

> **Važno:**
> Nakon prelaska testirajte prijenose i velike obrasce. Preuska vrijednost `post_max_size` može blokirati narudžbe, obrasce za prijave ili prijenose medija. To je jedan od razloga da se ažuriranje ne odgađa dugo.

## Dodatni zaštitni slojevi

Web aplikacijski vatrozid ili virtualno zakrpanje može pomoći kao dodatni sloj. Cloudflare je uveo zaštitna pravila, ali i sam upozorava da pravila samo na temelju podataka zahtjeva nisu dovoljna. WAF je stoga dopuna, a ne zamjena. Više na stranici [WAF i virtualno zakrpanje](https://phpsos.de/hr/leistungen/waf-virtuelles-patching/).

Osim toga osigurajte zapisnike poslužitelja od 20. listopada. Prema medijskim izvješćima prvi je pokušaj napada uočen već 17. listopada; zapisnici su osnova ako kasnije budete morali razjasniti je li se prije zakrpe nešto dogodilo.

## Kako PHP SOS konkretno pomaže?

- **Razjasniti stanje:** Provjeravamo je li ažuriranje kratkoročno moguće ili je potreban prijelaz te s Vama razgovaramo o opciji da se dijelovi isključe s mreže.
- **Postaviti mjere:** Vrijednosti php.net-a upisujemo na pravo mjesto, postavljamo cgroup ograničenje i ponovno pokrećemo sve workere.
- **Testirati funkcioniranje:** Obrasce, prijenose i procese narudžbe provjeravamo nakon prelaska.
- **Voditi do zakrpe:** Putem [usluge PHP zakrpe](https://phpsos.de/hr/leistungen/php-patch-service/) planiramo ažuriranje i prijelazne vrijednosti nakon toga kontrolirano vraćamo ondje gdje smetaju.


## Česta pitanja

**Štiti li zaobilazno rješenje potpuno od PHP2Shella?**  
Ne. php.net te mjere izričito naziva prijelaznima, a ne potpunom zaštitom. One smanjuju rizik dok se ažuriranje ne instalira. BSI preporučuje poslužitelje bez zakrpe privremeno isključiti s mreže.

**Mogu li postavke zadati putem .htaccess ili .user.ini?**  
Za session.upload_progress.enabled php.net izričito isključuje ini_set() i .user.ini. I za memory_limit vrijedi: vrijednost mora biti postavljena tako da je aplikacija ne može nadjačati. To uspijeva u php.ini, u FPM poolu s php_admin_value ili u Apache konfiguraciji poslužitelja.

**Je li web aplikacijski vatrozid dovoljan kao zaobilazno rješenje?**  
Kao dodatni sloj može pomoći. Cloudflare je uveo zaštitna pravila, ali i sam upozorava da pravila samo na temelju podataka zahtjeva nisu dovoljna. WAF ne zamjenjuje ni ažuriranje ni privremene mjere na poslužitelju.

**Što učiniti ako imam samo shared hosting?**  
Tada php.ini i ponovno pokretanje ovise o pružatelju hostinga. Pitajte konkretno je li ažuriranje instalirano ili privremene mjere postavljene i jesu li svi PHP procesi ponovno pokrenuti.

## Izvori

- [php.net: sigurnosne objave](https://www.php.net/)
- [BSI: Savezni ured za sigurnost informacijske tehnologije](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
