# Kāpēc mod_php rada augstāko risku

> Kāpēc PHP komanda PHP2Shell risku Apache ar mod_php vērtē kā augstāko, kā atpazīt mod_php un ko tagad ielāpot un pārslēgt.

Avots: https://phpsos.de/lv/php2shell/mod-php-risiko/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

**Īsi:** PHP2Shell skar visus ierastos darbības režīmus, taču Apache ar mod_php gadījumā PHP komanda risku vērtē kā augstāko. Tur exploit tika demonstrēts, vēl pirms vispār tiek izpildīts lietojumprogrammas kods. Kas darbina mod_php, tam vispirms jāatjaunina PHP un pilnībā jāpārstartē Apache.

## Kas ir mod_php?

Ar mod_php PHP ir modulis Apache tīmekļa servera iekšienē. Katrs Apache process satur pilnu PHP interpretatoru un izpilda PHP kodu tieši. Šis darbības režīms ilgi bija standarts un vecākos serveros, daudzās distributīvu pakotnēs un dažos Docker attēlos ir izplatīts līdz pat šodienai.

Alternatīva ir PHP-FPM: tur PHP darbojas kā atsevišķs pakalpojums ar savām procesiem, un Apache vai Nginx pieprasījumus tikai pārsūta tālāk. Abi varianti ir PHP2Shell skarti, tāpat kā php-cgi, FrankenPHP un LiteSpeed.

Tipiskas vides ar mod_php ir vecāki root serveri, kas gadiem darbojas nemainīti, standarta Apache instalācijas no distributīvu pakotnēm un Docker attēli ar Apache un PHP vienā konteinerā. Kas droši nezina, kuru darbības režīmu serveris izmanto, tam tas jāpārbauda, nevis jāpieņem.

## Kāpēc mod_php ievainojamība tiek uzskatīta par īpaši riskantu?

PHP komanda par PHP2Shell ir sniegusi skaidru vērtējumu: mod_php gadījumā risks ir augstākais. Pamatojums: tur tika demonstrēts exploit, kas darbojas, vēl pirms vispār tiek izpildīts lietojumprogrammas kods.

Operatoriem tam ir neērta sekas. Daudzi aizsardzības pasākumi atrodas lietojumprogrammā: drošības spraudņi WordPress, ugunsmūra moduļi veikalos, pārbaudes pašu kodā. Tie visi ir lietojumprogrammas kods. Ja ekspluatācija notiek pirms tā, tie nāk par vēlu.

Klāt nāk cieša saistība: ar mod_php PHP dala procesu ar Apache. Kas kompromitē PHP, darbojas ar tīmekļa servera tiesībām un tā atmiņā. PHP-FPM gadījumā pūlus turpretī var nodalīt ar atsevišķiem lietotājiem katrai vietnei, kas var ierobežot ielaušanās sekas.

Prioritizēšanai tas nozīmē: ja darbinat vairākus serverus, tie ar mod_php jāapstrādā pirmie, un tiem sekojoša pēdu pārbaude ir īpaši svarīga.

Ko mēs nezinām: cik no visā pasaulē saskaitītajām 22,6 miljoniem publiski pieejamo, potenciāli ievainojamo instanču izmanto mod_php. Pamatotu skaitļu par to nav publicēts.

## Vai mans serveris izmanto mod_php?

Tālāk norādītās komandas ir tikai lasošas. Pakalpojumu un komandu nosaukumi atšķiras pa distributīviem: Debian un Ubuntu izmanto `apache2`, RHEL saime `httpd`.

```bash
apachectl -M 2>/dev/null | grep -i php     # piem., php_module vai 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, moduļa pakotnes stāvoklis
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619"   # RHEL saime
```

Ja neviens PHP modulis neparādās, Apache, visticamāk, izmanto PHP-FPM caur `proxy_fcgi`. Tad pēc jēgas attiecas norādes rakstā [Nginx ar PHP-FPM nodrošināšana](https://phpsos.de/lv/server/nginx-php-fpm/).

## Kas mod_php operatoriem tagad jādara

1. **Atjaunināt PHP moduli** uz 8.5.12, 8.4.27, 8.3.36 vai 8.2.35 vai uz sava distributīva apstiprinātu backport.
2. **Pilnībā pārstartēt Apache,** nevis tikai pārlādēt. Ar mod_php vecais PHP kods ir katrā Apache procesā.

```bash
sudo systemctl restart apache2     # Debian/Ubuntu
sudo systemctl restart httpd       # RHEL saime
ps -o pid,lstart,cmd -C apache2    # pārbaudīt startēšanas laiku, RHEL: -C httpd
```

3. **Ieviest pagaidu pasākumus, ja atjauninājums vēl nav iespējams.** php.net cita starpā min stingras robežas, ko lietojumprogrammas nevar pārrakstīt:

```apache
# Servera konfigurācija vai VirtualHost, nevis .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
```

Ar `memory_limit=-1` klāt jānāk atmiņas ierobežojumam ar cgroup, nevis ar `RLIMIT_AS` vai `RLIMIT_DATA`. Šie pasākumi nav pilnīga aizsardzība; detaļas atradīsiet lapā [Tūlītēji pasākumi, ja vēl nevarat ielāpot](https://phpsos.de/lv/php2shell/sofortmassnahmen-ohne-patch/). Ja neviens no abiem nav iespējams uzreiz, BSI iesaka tīmekļa serveri uz laiku atvienot no tīkla.

> **Rīkoties nekavējoties:**
> Ja jūsu Apache ar mod_php laikā starp 17. oktobri un ielāpu bija neaizsargāts internetā, saglabājiet žurnālus no 20. oktobra un ļaujiet serveri pārbaudīt uz pēdām. Ielāps vien nepierāda, ka nekas nav noticis.

## Vidējā termiņā: prom no mod_php

Pēc ielāpa ir vērts paskatīties uz arhitektūru. Pāreja uz PHP-FPM ar Apache `mpm_event` un `proxy_fcgi` vai ar Nginx nodala PHP no tīmekļa servera, ļauj izmantot atsevišķus pūlus un lietotājus katrai vietnei un vienkāršo pārstartēšanu un versiju maiņu. Tā PHP2Shell neaizver, bet samazina turpmāko ievainojamību uzbrukuma virsmu.

Pārejai vajadzīgs plānojums. Iestatījumi, kas līdz šim ar `php_value` bija iestatīti `.htaccess`, PHP-FPM vairs nedarbojas un jāpārceļ uz pūlu. Lietotāji un tiesības mainās, augšupielāžu un kešatmiņas direktorijiem var būt vajadzīgas jaunas atļaujas. Testa vidē tas ir labi vadāms, dzīvā darbībā laika spiedienā ne. Norādes par pāreju atradīsiet rakstā [Apache ar mod_php nodrošināšana](https://phpsos.de/lv/server/apache-mod-php/).

## Kā PHP SOS palīdz konkrēti?

- **Atpazīt:** Mēs pārbaudām, kuri serveri izmanto mod_php un no kura pakotņu avota modulis nāk.
- **Ielāpot un pārstartēt:** Ar [PHP ielāpu pakalpojumu](https://phpsos.de/lv/leistungen/php-patch-service/) mēs instalējam atjauninājumu un kontrolējam, ka vairs nedarbojas vecs Apache process.
- **Nodrošināt pāreju:** Kur atjauninājums ir bloķēts, mēs php.net pasākumus iestatām servera konfigurācijā.
- **Pārslēgt:** [Servera nostiprināšanas](https://phpsos.de/lv/leistungen/server-haertung/) ietvaros plānojam un testējam pāreju uz PHP-FPM ar atsevišķiem pūliem.


## Biežāk uzdotie jautājumi

**Kā atpazīt, vai mans Apache izmanto mod_php?**  
Ar apachectl -M vai httpd -M redzat ielādētos moduļus. Ja tur ir modulis, piemēram, php_module vai php8_module, PHP darbojas tieši Apache. Debian un Ubuntu sistēmās arī a2query -m rāda, vai php modulis ir aktīvs.

**Vai mod_php gadījumā mani aizsargā drošības spraudnis WordPress?**  
Šīs ievainojamības gadījumā nē. Saskaņā ar PHP komandu mod_php gadījumā exploit tika demonstrēts, vēl pirms vispār tiek izpildīts lietojumprogrammas kods. Spraudnis ir lietojumprogrammas kods un tāpēc nāk par vēlu. Aizsargā tikai PHP atjauninājums ar Apache pārstartēšanu.

**Vai man tagad no mod_php jāpāriet uz PHP-FPM?**  
Vispirms ielāpot, tad pārslēgt. Pāreja uz PHP-FPM lielākajai daļai konfigurāciju ir lietderīga vidējā termiņā, jo PHP tad darbojas atsevišķi no tīmekļa servera. Taču PHP2Shell tā neaizver, jo PHP-FPM ir skarts tāpat.

## Avoti

- [php.net: drošības paziņojumi](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Vācijas Federālais informācijas drošības birojs](https://www.bsi.bund.de/)