# Zaštita Apachea s mod_php

> Apache mod_php nakon PHP2Shella: prepoznajte način rada, zakrpajte PHP modul, potpuno ponovno pokrenite Apache i uredno pripremite prelazak na PHP-FPM.

Izvor: https://phpsos.de/hr/server/apache-mod-php/  
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:** Kod Apachea s mod_php PHP radi izravno u web-poslužitelju. PHP tim rizik zbog PHP2Shella upravo u tom načinu rada ocjenjuje najvišim jer je exploit pokazan prije nego što se uopće izvrši kod aplikacije. Zakrpajte odmah, Apache potpuno ponovno pokrenite, a zatim planirajte prelazak na PHP-FPM.

## Što je mod_php i zašto je sada važan

Kod mod_php-a Apache učitava PHP kao modul u svaki vlastiti radni proces. Svaki zahtjev za PHP datotekom izvršava se izravno u tom procesu. To je dugo bila standardna postavka i jednostavna je za podešavanje. Ali znači i ovo: sve web-stranice na poslužitelju rade s istim korisnikom, a PHP dijeli proces s web-poslužiteljem.

PHP2Shell obuhvaća ranjivosti CVE-2026-109618 i CVE-2026-109619, obje s CVSS v4.0 9,2. Kod druge unutarnje stanje zahtjeva može ostati sačuvano nakon oslobađanja memorije i iskoristiti ga kasniji zahtjev u istom procesu. Za mod_php PHP tim utvrdio je najviši rizik. Pozadina i procjena nalaze se u članku [Zašto mod_php nosi najviši rizik](https://phpsos.de/hr/php2shell/mod-php-risiko/).

## Prepoznajte Apache mod_php i provjerite verziju

Najprije provjerite koristi li Vaš Apache uopće mod_php. Sljedeće naredbe samo čitaju. Nazivi naredbi i paketa razlikuju se po distribuciji i primjeri su.

```bash
# Debian/Ubuntu: učitani moduli
apache2ctl -M 2>/dev/null | grep -i php

# RHEL obitelj
httpd -M 2>/dev/null | grep -i php

# Koji je MPM aktivan? mod_php zahtijeva prefork
apache2ctl -V 2>/dev/null | grep -i mpm

# Stanje paketa modula (primjeri)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'
```

Ako se pojavi modul poput `php_module`, radi mod_php. Sama prikazana PHP verzija nije dokaz zakrpe jer distribucije ispravke često instaliraju kao backport. Ispravljene verzije PHP projekta su 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Kod paketa distribucije vrijedi zapisnik promjena s CVE brojevima.

## Zakrpajte i potpuno ponovno pokrenite Apache

Ažuriranje instalirajte putem upravitelja paketa. Budući da je PHP smješten u Apache procesu, nakon toga mora se ponovno pokrenuti cijela usluga. Ponovno učitavanje konfiguracije ovdje nije siguran put.

```bash
# Debian/Ubuntu
systemctl restart apache2

# RHEL obitelj
systemctl restart httpd

# Kontrola: vrijeme pokretanja svih Apache procesa
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep
```

Svi Apache procesi moraju prikazivati vrijeme pokretanja nakon ažuriranja. Ako na istom poslužitelju uz to radi PHP-FPM ili php-cgi, ponovno pokrenite i te usluge.

> **Djelujte odmah:**
> Ako za Vašu PHP verziju zakrpa još nije dostupna, BSI (njemački Savezni ured za informacijsku sigurnost) preporučuje privremeno odvajanje web-poslužitelja s mreže. Kod mod_php-a to je osobito važno jer napad može djelovati prije koda aplikacije.

## Privremene mjere u Apache konfiguraciji

php.net navodi privremene mjere koje smanjuju rizik, ali ne pružaju potpunu zaštitu. Kod mod_php-a vrijednosti postavite s `php_admin_value` odnosno `php_admin_flag` u Apache konfiguraciji kako ih `.htaccess` i aplikacije ne bi mogli nadjačati.

```apache
# Primjer: u konfiguraciji VirtualHosta ili cijelog poslužitelja
<IfModule php_module>
    php_admin_flag  session.upload_progress.enabled off
    php_admin_value post_max_size 8M
    php_admin_value upload_max_filesize 6M
</IfModule>
```

Uz funkciju uploada php.net navodi `post_max_size = 32M`, a `upload_max_filesize` ispod toga. Na PHP-u 8.5 dodaje se `fatal_error_backtraces=0`. Napomenu o `memory_limit=-1` provedite samo zajedno s ograničenjem memorije za uslugu putem cgroupa, primjerice pomoću `MemoryMax` u systemd dopuni, a ne putem `RLIMIT_AS` ili `RLIMIT_DATA`. Nakon toga Apache potpuno ponovno pokrenite. Sve mjere u pregledu: [Hitne mjere bez zakrpe](https://phpsos.de/hr/php2shell/sofortmassnahmen-ohne-patch/).

## Put dalje od mod_php-a

Nakon akutne zakrpe isplati se prijeći na PHP-FPM. Tada PHP radi u vlastitim procesima, odvojeno od web-poslužitelja. Svaka web-stranica može dobiti vlastiti pool s vlastitim korisnikom, ograničenja se mogu postaviti po poolu, a ponovna pokretanja pogađaju samo PHP. Apache PHP-FPM povezuje putem `mod_proxy_fcgi` i tada umjesto prefork-a može koristiti suvremeniji MPM poput event.

Prelazak planirajte u testnom okruženju: izradite poolove po web-stranici, prilagodite prava nad datotekama novim korisnicima, unose u `.htaccess` s `php_value` prenesite u postavke poola, provedite testove opterećenja. Kako izgleda uredna izvedba, pokazuje članak [Zaštita Nginxa s PHP-FPM-om](https://phpsos.de/hr/server/nginx-php-fpm/); načela vrijede i za Apache s PHP-FPM-om.

Neovisno o načinu rada vrijedi: zakrpa ne uklanja već ubačen zlonamjerni softver. Sačuvajte zapisnike od 20. 10. 2026. i provjerite poslužitelj zbog tragova.

Kod potrage za tragovima na mod_php poslužiteljima isplati se pogledati zajedničkog korisnika. Budući da sve web-stranice rade pod Apache korisnikom, primjerice `www-data` ili `apache`, napadač koji je preuzeo jednu web-stranicu u pravilu može čitati i mijenjati i datoteke drugih. Zato ne provjeravajte samo web-stranicu koja Vam se čini sumnjivom, nego sve Document Rootove na poslužitelju. Obratite posebnu pozornost na PHP datoteke s nedavnim datumom izmjene u direktorijima za upload i predmemoriju, na programski kod koji pripada Apache korisniku i na nepoznate unose u crontabu tog korisnika. Ako nešto pronađete, najprije osigurajte stanje i nemojte brzopleto brisati kako bi se uzrok kasnije mogao rekonstruirati.

## Kako PHP SOS konkretno pomaže?

- Provjeravamo način rada, MPM i stanje paketa te ocjenjujemo je li Vaš poslužitelj stvarno zakrpan.
- Putem [usluge PHP zakrpa](https://phpsos.de/hr/leistungen/php-patch-service/) instaliramo ažuriranje, Apache potpuno ponovno pokrećemo i dokumentiramo dokaz.
- Do zakrpe privremene mjere postavljamo tako da se ne mogu nadjačati i ograničavamo memoriju na razini usluge.
- U okviru [ojačavanja poslužitelja](https://phpsos.de/hr/leistungen/server-haertung/) planiramo i testiramo prelazak na PHP-FPM s odvojenim poolovima.


## Česta pitanja

**Kako prepoznati koristi li moj poslužitelj mod_php?**  
Ako je Apache učitao PHP modul, u popisu modula pojavljuje se kao php_module ili s brojem verzije u nazivu. Osim toga, ispis phpinfo pod Server API prikazuje unos Apache 2.0 Handler. Takvu testnu datoteku odmah ponovno izbrišite.

**Zašto je mod_php kod PHP2Shella posebno kritičan?**  
Prema PHP timu tamo je rizik najviši; exploit je pokazan prije nego što se uopće izvrši kod aplikacije. Zato ni dobro održavana aplikacija ne štiti. Brzo ažuriranje stoga ima najviši prioritet.

**Je li nakon ažuriranja dovoljan reload Apachea?**  
Siguran je potpuni restart usluge, jer je PHP kao modul smješten u Apache procesima. Nakon toga provjerite vrijeme pokretanja svih Apache procesa. Procesi stariji od ažuriranja ne smiju ostati.

**Je li prelazak na PHP-FPM zahtjevan?**  
Najčešće se dobro može isplanirati: instalirati PHP-FPM, izraditi poolove, Apache prebaciti na proxy_fcgi i s prefork prijeći na drugi MPM. To prethodno testirajte na kopiji okruženja.

## Izvori

- [php.net: sigurnosne objave](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)