Kort sagt: For administratorer uden udviklerbaggrund er fem grundlæggende ting nok til at drive PHP sikkert: PHP består af flere programmer (kommandolinje, PHP-FPM, Apache-modul) med hver sin version; indstillinger virker i niveauer fra php.ini til applikationen; PHP-FPM fordeler forespørgsler på workers i pools; en opdatering virker først efter genstart af alle processer; og logs er den vigtigste henvisning, når noget ikke stemmer. Den, der kender disse punkter, kan lukke sårbarheder som PHP2Shell hurtigt og dokumenterbart.
Hvad PHP består af på en server
PHP er ikke et enkelt program. På en typisk Linux-server findes flere varianter, der hver er tilsluttet via en server-grænseflade (SAPI):
| Variant | Typisk navn | Hvortil |
|---|---|---|
| Kommandolinje (CLI) | php, php8.3 |
cronjobs, Composer, vedligeholdelsesscripts |
| PHP-FPM | php-fpm, php-fpm8.3 |
webforespørgsler bag Nginx eller Apache |
| Apache-modul | mod_php, libphp |
webforespørgsler direkte i Apache-processen |
| CGI | php-cgi |
ældre opbygninger |
Hver variant kan have en anden version og en anden php.ini. På mange servere kører der desuden flere PHP-versioner parallelt, f.eks. 8.2 og 8.4. Ved en opdatering skal hver enkelt betragtes for sig. Hvordan grænsefladerne arbejder, forklarer PHP-FPM forklaret.
Hvilken variant der faktisk betjener jeres websites, finder I ud af via de kørende processer og webserverkonfigurationen:
ps -eo pid,user,lstart,cmd | grep -E "php|httpd|apache2" | grep -v grep
apachectl -M 2>/dev/null | grep -i php # indlæser Apache et PHP-modul?
ls /run/php/ 2>/dev/null # FPM-sockets, ofte pr. version og pool
Kolonnen med starttidspunktet er senere vigtig ved genstarten: Alle PHP-processer skal være startet efter opdateringstidspunktet. Kører processer under forskellige brugere, peger det på adskilte pools, hvilket er godt. Dukker der et PHP-modul op i Apache, selv om alle websites skal køre via FPM, er det en henvisning til en arvelast, som bør fjernes. For hostingoverflader som Plesk eller cPanel gælder det samme princip, blot at overfladen viser versionerne og handlerne pr. website; afgørende forbliver dog, hvad der faktisk kører som proces.
De vigtigste kommandoer for administratorer
php -v # kommandolinjens version
php --ini # indlæst php.ini og yderligere læste mapper
php --ini=diff # fra PHP 8.5: afvigelser fra standarden
php -m # indkompilerede og indlæste moduler
php --ri session # en udvidelses indstillinger
php -l datei.php # syntakskontrol uden udførelse
php-fpm8.3 -v # FPM-binærens version (navn alt efter distribution)
php-fpm8.3 -t # test FPM-konfigurationen uden at genstarte
systemctl status php8.3-fpm
To henvisninger fra manualen: php -l finder syntaksfejl, men ikke fejl, der først opstår ved udførelsen. Og php -i kalder phpinfo(); outputtet hører ikke hjemme i offentlige filer i webmappen.
Sådan virker PHP-indstillinger
En indstilling kan sættes flere steder. Hvem der må ændre hvad hvor, regulerer ændringstilstanden for hvert direktiv:
- php.ini og conf.d: grundkonfiguration pr. variant, læst ved start.
- FPM-pool:
php_valueogphp_admin_valuepr. pool. Værdier sat medphp_admin_valuekan applikationen ifølge manualen ikke overskrive medini_set(). - Mappeniveau:
.user.inived FPM eller.htaccessved mod_php, kun for direktiver i tilstandenINI_PERDIRellerINI_ALL. - Applikation:
ini_set()under kørslen, kun for direktiver i tilstandenINI_ALL.
Et eksempel: memory_limit har tilstanden INI_ALL, kan altså ændres af applikationen. post_max_size har INI_PERDIR og kan ikke ændres med ini_set(). Derfor kræver php.net ved PHP2Shell-foranstaltningerne, at værdier sættes, så applikationer ikke kan overskrive dem. Detaljer om niveauerne forklarer php.ini forklaret.
PHP-FPM-pools kort fortalt
En pool er en gruppe af workers med egen bruger, egen socket og egne indstillinger. De vigtigste direktiver ifølge manualen:
[shop]
user = shop
group = shop
listen = /run/php/shop.sock
pm = dynamic ; static, dynamic eller ondemand
pm.max_children = 20 ; højst 20 samtidige forespørgsler
pm.max_requests = 500 ; forny workeren efter 500 forespørgsler
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/shop-slow.log
php_admin_value[error_log] = /var/log/php-fpm/shop-error.log
php_admin_flag[log_errors] = on
En egen pool pr. website med egen bruger adskiller websites fra hinanden. security.limit_extensions står som standard på .php .phar og forhindrer, at FPM udfører andre filendelser end PHP. clear_env er som standard slået til og holder miljøvariabler væk fra workeren.
Logs: hvor administratorer skal se hen
PHP skriver fejl til det mål, der er fastlagt med error_log, PHP-FPM desuden til sin egen log og ved langsomme forespørgsler til slowloggen med backtrace. Dertil kommer webserverens adgangs- og fejllogs. Sørg for, at display_errors er slået fra i produktion og log_errors slået til: Fejl hører til i loggen, ikke på websiden. Logs bør desuden roteres og opbevares i et fastlagt tidsrum, så de stadig er der i alvorlige tilfælde. Efter PHP2Shell anbefaler fagpressen at opbevare serverlogs fra 20.10.2026. Et stærkt varselssignal er en PHP-FPM- eller webserverproces, der starter en shell; hvordan I genkender det, står under Varselssignal: Webserveren starter en shell.
Tjekliste for administratorer efter PHP2Shell
- List alle PHP-varianter og -versioner på serveren, også de ubrugte.
- Kontrollér pakkestatus; ved distributionens backports gennemsøges changelog efter CVE-2026-109618 og CVE-2026-109619.
- Opdatér til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 hhv. den bekræftede backport.
- Genstart PHP-FPM, Apache og LiteSpeed og kontrollér processernes starttidspunkter.
- Modprøve med
php -r 'var_dump(ini_get("memory_hard_limit_percent"));';bool(false)betyder ifølge manualen en berørt version. - Sikr logs og gennemgå dem for uregelmæssigheder.
Hvordan I dokumenterer version og patch-status pålideligt, beskriver Kontrollér PHP-version og patch-status rigtigt.
Hvordan hjælper PHP SOS konkret?
I sikkerhedsvedligeholdelsesaftalen overtager vi PHP-grundplejen sammen med jeres team:
- Inventar: alle PHP-varianter, versioner, pools og konfigurationssteder pr. server.
- Konfiguration: sikkerhedsrelevante værdier sat med
php_admin_value, pools adskilt pr. website. - Opdateringer: indspilning, genstart, kontrol og dokumentation ved hver sikkerhedsudgivelse.
- Videregive viden: Vi forklarer jeres administratorer, hvad vi har ændret, og hvorfor.
Ofte stillede spørgsmål
Hvorfor viser php -v en anden version end websitet?
Kommandolinje, PHP-FPM og Apache-modul er adskilte programmer med egen version og egen php.ini. php -v viser kun kommandolinjen. For websitet tæller versionen af den binær, der faktisk behandler forespørgsler.
Hvilken php.ini gælder på min server?
Det viser php --ini for kommandolinjen. For PHP-FPM findes der oftest en egen php.ini og yderligere pool-filer. Siden PHP 8.5 viser php --ini=diff, hvilke værdier der afviger fra standarden.
Hvad er forskellen på php_value og php_admin_value?
Begge sætter indstillinger i en FPM-pool. Værdier med php_admin_value kan applikationen ifølge manualen ikke overskrive med ini_set(). Til sikkerhedsrelevante indstillinger er php_admin_value derfor det rette valg.
Er en opdatering uden genstart nok?
Nej. Kørende PHP-processer beholder den gamle kode i hukommelsen. Efter en opdatering skal PHP-FPM, Apache med mod_php eller LiteSpeed genstartes, ellers kører den sårbare version videre.