# Zašto mod_php nosi najviši rizik

> Zašto PHP tim rizik PHP2Shella kod Apachea s mod_php ocjenjuje najvišim, kako prepoznati mod_php i što sada trebate zakrpati i promijeniti.

Izvor: https://phpsos.de/hr/php2shell/mod-php-risiko/  
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:** PHP2Shellom su pogođeni svi uobičajeni načini rada, ali kod Apachea s mod_php PHP tim rizik ocjenjuje najvišim. Tamo je prikazan exploit prije nego što se uopće izvrši kod aplikacije. Tko koristi mod_php, trebao bi prvo ažurirati PHP i potpuno ponovno pokrenuti Apache.

## Što je mod_php?

Kod mod_php PHP je modul unutar Apache web-poslužitelja. Svaki Apache proces sadrži potpuni PHP interpreter i izravno izvršava PHP kod. Taj je način rada dugo bio standard i do danas je raširen na starijim poslužiteljima, u mnogim paketima distribucija i u nekim Docker image-ima.

Alternativa je PHP-FPM: tamo PHP radi kao zasebna usluga sa zasebnim procesima, a Apache ili Nginx samo prosljeđuju zahtjeve. Obje su varijante pogođene PHP2Shellom, kao i php-cgi, FrankenPHP i LiteSpeed.

Tipična okruženja s mod_php su stariji root poslužitelji koji godinama rade nepromijenjeni, standardne instalacije Apachea iz paketa distribucija i Docker image-i s Apacheom i PHP-om u jednom kontejneru. Tko nije siguran koji način rada njegov poslužitelj koristi, trebao bi to provjeriti umjesto pretpostaviti.

## Zašto se mod_php sigurnosna ranjivost smatra osobito rizičnom?

PHP tim je za PHP2Shell dao jasnu procjenu: kod mod_php rizik je najviši. Obrazloženje: tamo je prikazan exploit koji djeluje prije nego što se uopće izvrši kod aplikacije.

Za operatere to ima neugodnu posljedicu. Mnoge zaštitne mjere nalaze se u aplikaciji: sigurnosni dodaci u WordPressu, vatrozidni moduli u shopovima, provjere u vlastitom kodu. Sve su to kod aplikacije. Ako se iskorištavanje događa prije toga, dolaze prekasno.

Tome se pridodaje uska povezanost: kod mod_php PHP dijeli proces s Apacheom. Što PHP kompromitira, radi s pravima web-poslužitelja i u njegovoj memoriji. Kod PHP-FPM-a poolovi se mogu odvojiti zasebnim korisnicima po web-stranici, što može ograničiti posljedice provale.

Za određivanje prioriteta to znači: ako upravljate s više poslužitelja, oni s mod_php dolaze prvi na red, a kod njih je naknadna provjera tragova osobito važna.

Što ne znamo: koliko od 22,6 milijuna izloženih, potencijalno ranjivih instanci izbrojenih u svijetu koristi mod_php. Pouzdani podaci o tome nisu objavljeni.

## Koristi li moj poslužitelj mod_php?

Sljedeće naredbe su isključivo čitajuće. Nazivi usluga i naredbi razlikuju se po distribuciji: Debian i Ubuntu koriste `apache2`, obitelj RHEL `httpd`.

```bash
apachectl -M 2>/dev/null | grep -i php     # npr. php_module ili php8_module
httpd -M 2>/dev/null | grep -i php         # RHEL, AlmaLinux, Rocky
a2query -m | grep -i php                   # Debian/Ubuntu
apt policy libapache2-mod-php8.3           # Debian/Ubuntu, stanje paketa modula
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619"   # obitelj RHEL
```

Ako se ne pojavi nijedan PHP modul, Apache vjerojatno koristi PHP-FPM putem `proxy_fcgi`. Tada napomene na stranici [Osiguravanje Nginxa s PHP-FPM-om](https://phpsos.de/hr/server/nginx-php-fpm/) vrijede analogno.

## Što bi operateri mod_php sada trebali učiniti

1. **Ažurirati PHP modul** na 8.5.12, 8.4.27, 8.3.36 ili 8.2.35 ili potvrđeni backport Vaše distribucije.
2. **Potpuno ponovno pokrenuti Apache,** a ne samo ponovno učitati. Kod mod_php stari PHP kod nalazi se u svakom Apache procesu.

```bash
sudo systemctl restart apache2     # Debian/Ubuntu
sudo systemctl restart httpd       # obitelj RHEL
ps -o pid,lstart,cmd -C apache2    # provjeriti vrijeme pokretanja, u RHEL-u: -C httpd
```

3. **Postaviti privremene mjere ako ažuriranje još nije moguće.** php.net među ostalim navodi čvrsta ograničenja koja aplikacije ne mogu nadjačati:

```apache
# Konfiguracija poslužitelja ili VirtualHost, ne .htaccess
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
```

Uz `memory_limit=-1` pripada ograničenje memorije putem cgroupa, a ne putem `RLIMIT_AS` ili `RLIMIT_DATA`. Te mjere nisu potpuna zaštita; pojedinosti su na stranici [Hitne mjere ako još ne možete zakrpati](https://phpsos.de/hr/php2shell/sofortmassnahmen-ohne-patch/). Ako ni jedno ni drugo nije odmah moguće, BSI (njemački Savezni ured za sigurnost informacijske tehnologije) preporučuje privremeno isključiti web-poslužitelj s mreže.

> **Djelujte odmah:**
> Ako je Vaš Apache s mod_php između 17. listopada i zakrpe bio nezaštićen na internetu, osigurajte zapisnike od 20. listopada i dajte provjeriti poslužitelj zbog tragova. Sama zakrpa ne dokazuje da se ništa nije dogodilo.

## Srednjoročno: odmak od mod_php

Nakon zakrpe isplati se pogledati arhitekturu. Prelazak na PHP-FPM s Apacheom `mpm_event` i `proxy_fcgi` ili s Nginxom odvaja PHP od web-poslužitelja, omogućuje zasebne poolove i korisnike po web-stranici te olakšava ponovna pokretanja i promjene verzije. PHP2Shell ne zatvara, ali smanjuje površinu napada budućih ranjivosti.

Prelazak traži planiranje. Postavke koje su dosad postavljane putem `php_value` u `.htaccess` ne djeluju pod PHP-FPM-om i moraju se preseliti u pool. Korisnici i prava se mijenjaju, mape za prijenos i predmemoriju možda trebaju nova dopuštenja. U testnom okruženju to je dobro izvedivo, u živom radu pod vremenskim pritiskom nije. Napomene o prelasku pronaći ćete na stranici [Osiguravanje Apachea s mod_php](https://phpsos.de/hr/server/apache-mod-php/).

## Kako PHP SOS konkretno pomaže?

- **Prepoznati:** Provjeravamo koji poslužitelji koriste mod_php i iz kojeg izvora paketa modul potječe.
- **Zakrpati i ponovno pokrenuti:** Putem [usluge PHP zakrpe](https://phpsos.de/hr/leistungen/php-patch-service/) instaliramo ažuriranje i kontroliramo da više ne radi nijedan stari Apache proces.
- **Osigurati prijelaz:** Gdje je ažuriranje blokirano, mjere php.net-a postavljamo u konfiguraciju poslužitelja.
- **Prijeći:** U sklopu [ojačavanja poslužitelja](https://phpsos.de/hr/leistungen/server-haertung/) planiramo i testiramo prelazak na PHP-FPM sa zasebnim poolovima.


## Česta pitanja

**Po čemu prepoznajem koristi li moj Apache mod_php?**  
Naredbom apachectl -M ili httpd -M vidite učitane module. Ako tamo stoji modul poput php_module ili php8_module, PHP radi izravno u Apacheu. Na Debianu i Ubuntuu i a2query -m pokazuje je li php modul aktivan.

**Štiti li me sigurnosni dodatak u WordPressu kod mod_php?**  
Kod ove ranjivosti ne. Prema PHP timu kod mod_php prikazan je exploit prije nego što se uopće izvrši kod aplikacije. Dodatak je kod aplikacije i stoga dolazi prekasno. Zaštitu pruža samo PHP ažuriranje s ponovnim pokretanjem Apachea.

**Trebam li sada prijeći s mod_php na PHP-FPM?**  
Prvo zakrpati, zatim prijeći. Prelazak na PHP-FPM za većinu postavki srednjoročno je smislen jer PHP tada radi odvojeno od web-poslužitelja. PHP2Shell ipak ne zatvara, jer je i PHP-FPM pogođen.

## Izvori

- [php.net: sigurnosne objave](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Savezni ured za sigurnost informacijske tehnologije](https://www.bsi.bund.de/)