Kort gezegd: Voor de beveiliging van de php.ini tellen vooral vier gebieden: geen foutmeldingen naar buiten, veilige sessiecookies, beperkte uploads en vergrendelde waarden die toepassingen niet kunnen overschrijven. Na PHP2Shell komen de tussenmaatregelen van php.net erbij, vooral session.upload_progress.enabled=0. Een veilige configuratie vervangt echter nooit de update.
Waarom de php.ini na PHP2Shell weer in beeld is
De php.ini is het centrale configuratiebestand van PHP. Op veel servers is ze eenmaal ingericht en daarna nauwelijks aangeraakt. Met PHP2Shell is dat veranderd: voor de twee kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 noemt php.net tussenmaatregelen die precies hier aangrijpen.
De kwetsbaarheden zelf zitten in de PHP-interpreter. Verholpen zijn ze in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35, gepubliceerd op 21-10-2026. Een goede configuratie helpt toch op twee manieren: ze kan misbruik bemoeilijken en ze beperkt de schade als er toch iets doorheen komt.
Veel beheerders weten bovendien niet precies welke instellingen op hun server gelden. Dat is de eerste stap.
Welke php.ini geldt op uw server?
PHP kan afhankelijk van de uitvoeringsmodus verschillende configuratiebestanden lezen. De opdrachtregel, PHP-FPM en Apache met mod_php hebben onder Debian en Ubuntu bijvoorbeeld elk een eigen map onder /etc/php/<version>/. Wie alleen het CLI-bestand wijzigt, verandert niets aan de website.
# Configuratiebestanden van de opdrachtregel
php --ini
# Configuratie van PHP-FPM (versienummer aanpassen)
php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"
# Afzonderlijke waarden van PHP-FPM controleren
php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) "
Daarnaast kunnen waarden in de FPM-pool, in de Apache-configuratie, in .htaccess (alleen mod_php) of in .user.ini (FPM en CGI) staan. Welke versie er werkelijk op de server draait en of er een backport in zit, verduidelijkt het artikel PHP-versie en patchstand goed controleren.
Basisinstellingen voor een veiligere php.ini
De volgende waarden zijn voor de meeste productieservers zinvol. Test vóór gebruik in een testomgeving of uw toepassing met alle waarden overweg kan.
; Geen versievermelding in de HTTP-header
expose_php = Off
; Fouten loggen, maar nooit in de browser tonen
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log
; Geen bestanden van externe adressen insluiten
allow_url_include = Off
; allow_url_fopen alleen actief laten als de toepassing het nodig heeft
allow_url_fopen = Off
; Sessies: strikt, alleen via HTTPS, niet leesbaar via JavaScript
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
; Uitvoeringstijd en invoer beperken
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000
allow_url_fopen hebben sommige toepassingen nodig voor updates of koppelingen. Schakel het alleen uit als u dat vooraf hebt gecontroleerd. Functies die systeemopdrachten uitvoeren, kunnen aanvullend worden geblokkeerd; hoe dat zonder bijwerkingen lukt, legt de gids disable_functions correct inzetten uit.
Tussenmaatregelen van php.net voor PHP2Shell
Als u niet meteen kunt patchen, noemt php.net meerdere instellingen die het risico verlagen. Ze zijn uitdrukkelijk geen volledige bescherming, maar een brug tot de update.
; Session upload progress uitschakelen (ook vanwege CVE-2026-115560)
session.upload_progress.enabled = 0
; Aanvraaggrootte beperken: 8M zonder uploads, 32M met uploads
post_max_size = 8M
upload_max_filesize = 6M
; Alleen PHP 8.5: geen backtraces bij zware fouten
fatal_error_backtraces = 0
Daarnaast adviseert php.net memory_limit=-1 zo in te stellen dat toepassingen de waarde niet kunnen overschrijven, en de geheugengrens in plaats daarvan via container of cgroup te trekken, niet via RLIMIT_AS of RLIMIT_DATA. Deze maatregel hoort in de FPM-pool of de serverconfiguratie en moet worden gecombineerd met een werkende cgroup-grens. Het volledige overzicht vindt u onder Spoedmaatregelen als u nog niet kunt patchen.
session.upload_progress.enabled=0 werkt alleen vanuit php.ini, FPM-pool of serverconfiguratie. Via ini_set() of .user.ini ingesteld, werkt de maatregel niet. Herstart daarna alle workers.
Waarden tegen overschrijven vergrendelen
Veel toepassingen stellen eigen waarden in, bijvoorbeeld voor geheugen of uploads. Met php_admin_value en php_admin_flag legt u instellingen zo vast dat noch ini_set() noch .user.ini ze kan wijzigen. In de FPM-pool ziet dat er zo uit:
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (fragment)
php_admin_flag[display_errors] = off
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_value[error_log] = /var/log/php/meine-seite.error.log
Onder Apache met mod_php geldt dezelfde logica met php_admin_value en php_admin_flag in de VirtualHost-configuratie. Laad daarna de dienst opnieuw en controleer de actieve waarde:
sudo systemctl reload php8.3-fpm
# Starttijd van de processen: ligt die na de wijziging?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Een reload start de workers van PHP-FPM opnieuw. Na een PHP-update is daarentegen een volledige herstart van alle PHP-processen nodig, zodat er geen oud proces in het geheugen blijft doordraaien. Bij meerdere websites op één server loont bovendien een eigen pool per website, meer daarover in de gids open_basedir en isolatie per website.
Veelgemaakte fouten en een korte controlelijst
De meeste problemen met de php.ini ontstaan niet door verkeerde waarden, maar door waarden op de verkeerde plek. Typisch is het gewijzigde CLI-bestand terwijl de website via PHP-FPM draait. Net zo vaak blijft na een wijziging de herstart uit, of overschrijft een hostingpaneel de eigen instelling bij de volgende keer opslaan.
Een tweede klassieker zijn zichtbare foutmeldingen op de live website. Ze verraden paden, databasenamen of versies en helpen aanvallers bij hun oriëntatie. Juist na een verhuizing of nieuwe installatie staat display_errors vaak weer op On.
Controleer deze punten na elke wijziging en na elke PHP-update:
- Welk configuratiebestand leest de webmodus, en bevat het uw waarden?
- Zijn
display_errorsenexpose_phpuitgeschakeld, is het foutlog beschrijfbaar? - Staat
session.upload_progress.enabledop0, ingesteld via php.ini of pool? - Zijn upload- en aanvraaggroottes passend bij de toepassing beperkt?
- Draaien alle PHP-processen met een starttijd na de laatste wijziging?
Leg het resultaat met datum vast. Zo is later aan te tonen wanneer welke instelling gold.
Hoe helpt PHP SOS concreet?
- We bepalen welke configuratie in welke uitvoeringsmodus daadwerkelijk actief is.
- We stellen een afgestemde basisconfiguratie en de PHP2Shell-tussenmaatregelen in, getest met uw toepassing.
- We vergrendelen beveiligingsrelevante waarden tegen overschrijven en herstarten alle workers gecontroleerd.
- We documenteren instellingen en controleresultaat, zodat latere wijzigingen traceerbaar blijven.
Hoe duurzame beveiliging eruitziet, beschrijft de dienst Serververharding voor PHP-webservers.
Veelgestelde vragen
Welke php.ini gebruikt mijn webserver eigenlijk?
Dat is vaak niet dezelfde als op de opdrachtregel. PHP-FPM, Apache met mod_php en CLI hebben meestal eigen configuratiemappen. Controleer het actieve bestand daarom via de betreffende uitvoeringsmodus, bijvoorbeeld met php-fpm -i of een kortstondig geplaatst controlebestand.
Vervangt een veilige php.ini de PHP-update?
Nee. De instellingen verkleinen het aanvalsoppervlak en bemoeilijken misbruik, maar dichten geen kwetsbaarheid in de PHP-interpreter. Ook de tussenmaatregelen van php.net voor PHP2Shell zijn uitdrukkelijk geen volledige bescherming.
Wat is het verschil tussen php_value en php_admin_value?
Waarden die met php_value zijn gezet, kan de toepassing tijdens de uitvoering weer wijzigen. Waarden via php_admin_value in de FPM-pool of in de Apache-configuratie zijn daarentegen voor de toepassing vergrendeld, ook voor ini_set() en .user.ini.
Moet ik na een wijziging in de php.ini herstarten?
Ja. PHP-FPM en Apache met mod_php lezen de configuratie alleen bij het opstarten. Pas na een herstart of reload van alle betrokken diensten gelden de nieuwe waarden.