Zaštita Apachea s mod_php

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.

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.

# 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.

# 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.

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.

# 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.

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; 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 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 planiramo i testiramo prelazak na PHP-FPM s odvojenim poolovima.

Česta pitanja

Izvori

• php.net: sigurnosne objave
• PHP 8 ChangeLog
• BSI
• OWASP Cheat Sheets