Kort gezegd: Met PHP disable_functions blokkeert u functies waarmee PHP systeemopdrachten uitvoert, zoals exec, shell_exec of proc_open. Dat bemoeilijkt aanvallers na een inbraak de volgende stap. De instelling werkt alleen vanuit php.ini of FPM-pool, moet bij de toepassing passen en vervangt geen update.
Waarom disable_functions juist nu zinvol is
Bij PHP2Shell gaat het om het op afstand en zonder aanmelding uitvoeren van schadelijke code. De twee kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 zitten in de PHP-interpreter zelf, verholpen in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. De update is de enige manier om ze te dichten.
Verharding grijpt een niveau later aan. Wie eenmaal code op een server kan uitvoeren, wil meestal verder: systeemopdrachten starten, hulpmiddelen nalaadden, een permanente achterdeur inrichten. Veel van die stappen lopen via enkele PHP-functies. Zijn die geblokkeerd, dan wordt de weg lastiger en opvallender.
disable_functions is daarom geen vervanging van patches, maar een bouwsteen voor het geval er ondanks alle voorzichtigheid toch iets doorheen komt. Dat geldt voor toekomstige kwetsbaarheden net zo goed als voor PHP2Shell.
Wat PHP disable_functions doet en wat niet
De instelling verwijdert de genoemde functies uit de uitvoeringsomgeving. Roept een script een geblokkeerde functie aan, dan breekt PHP af met een fout. De blokkade geldt voor elke code die in dat PHP-proces draait, dus ook voor binnengebrachte code.
U moet de grenzen kennen:
- De instelling is geen afgesloten beschermde ruimte. PHP-extensies, fouten in de interpreter of programma's buiten PHP kunnen haar omzeilen.
- Ze verhindert niet dat een aanvaller bestanden leest of schrijft waartoe de PHP-gebruiker toegang heeft. Daarvoor zijn bestandsrechten en isolatie verantwoordelijk.
- Ze werkt alleen vanuit de php.ini of als
php_admin_value. Metini_set(),.user.iniof.htaccessis ze niet in te stellen.
Het meeste levert disable_functions op samen met een nette php.ini, eigen gebruikers per website en restrictieve bestandsrechten. De basis daarvoor staat in de gids php.ini veilig configureren.
Welke functies u moet blokkeren
Voor typische websites zonder behoefte aan systeemopdrachten heeft de volgende lijst zich bewezen. Ze omvat functies om processen te starten en lopende processen te besturen.
| Groep | Functies | Typisch legitiem gebruik |
|---|---|---|
| Opdrachten uitvoeren | exec, shell_exec, system, passthru |
Beeldbewerking, back-ups via script |
| Processen openen | proc_open, popen |
Composer, pdf-hulpmiddelen, e-mailverzending |
| Processen besturen | proc_nice, proc_terminate, proc_get_status |
Wachtrijen, achtergrondtaken |
| Procesbeheer | pcntl_exec, pcntl_fork |
meestal alleen op de opdrachtregel |
| Signalen en rechten | posix_kill, posix_setuid |
zelden in webbedrijf |
Als configuratie ziet dat er zo uit:
; php.ini van de webmodus, bijv. /etc/php/8.3/fpm/php.ini
disable_functions = exec,shell_exec,system,passthru,proc_open,popen,proc_nice,proc_terminate,proc_get_status,pcntl_exec,pcntl_fork,posix_kill,posix_setuid
Geldt de lijst niet voor alle websites op de server, stel haar dan per FPM-pool in. Controleer na het opnieuw laden welke lijst in die pool daadwerkelijk geldt:
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (fragment)
php_admin_value[disable_functions] = exec,shell_exec,system,passthru,proc_open,popen
Toepassing vooraf controleren: zo voorkomt u uitval
Wie de lijst ongecontroleerd instelt, riskeert dat beeldverkleining, pdf-facturen of e-mailverzending ineens niet meer werken. Zoek daarom vooraf in de code naar de betrokken functies:
# Waar en hoe vaak worden de functies in de code gebruikt?
grep -rnoE "\b(exec|shell_exec|system|passthru|proc_open|popen|pcntl_exec)\s*\(" /var/www/meine-seite --include="*.php" \
| cut -d: -f1 | sort | uniq -c | sort -rn | head -30
Treffers betekenen niet automatisch dat de functie in bedrijf nodig is. Veel bibliotheken controleren eerst of een functie beschikbaar is en wijken anders uit. Beslissend is een test in een stagingomgeving met alle belangrijke processen: bestelling, factuur, formulierverzending, beeld-upload, geplande taken.
Eist een toepassing dwingend een van deze functies, controleer dan de systeemeisen van de fabrikant op diens officiële pagina. Vaak is de taak te verplaatsen naar een aparte pool of een opdrachtregelscript dat niet via het web bereikbaar is.
Instelling activeren en werking controleren
Na de wijziging moet PHP de configuratie opnieuw inlezen. Controleer daarna de waarde in de uitvoeringsmodus van uw website, niet op de opdrachtregel:
sudo systemctl reload php8.3-fpm
php-fpm8.3 -i | grep "^disable_functions"
# Foutlog controleren op aanroepen van geblokkeerde functies
sudo grep -i "has been disabled" /var/log/php/*.log | tail -20
De meldingen in het foutlog zijn ook later waardevol. Verschijnen daar plotseling aanroepen van geblokkeerde functies terwijl uw toepassing ze niet gebruikt, dan kan dat op binnengebrachte code wijzen. Hoe u dan verdergaat, beschrijft de gids Webshells herkennen en verwijderen.
Typische fouten bij het inzetten van disable_functions
In de praktijk strandt de verharding zelden op de techniek, maar op details. Deze fouten komen bijzonder vaak voor:
- Verkeerd bestand gewijzigd: De lijst staat alleen in de php.ini van de opdrachtregel, de website draait via PHP-FPM en blijft onbeschermd.
- Geen herstart: Het bestand is correct, maar de lopende processen werken nog met de oude configuratie.
- Te breed geblokkeerd: Functies als
ini_setofmailworden mee geblokkeerd en belangrijke processen vallen ongemerkt uit. Fouten vallen dan vaak pas dagen later op, bijvoorbeeld doordat bestelbevestigingen uitblijven. - Eenmaal ingesteld, nooit gecontroleerd: Na een verhuizing, een wissel van PHP-versie of een nieuwe installatie via het hostingpaneel is de lijst verdwenen.
- Vals gevoel van veiligheid: De blokkade wordt gezien als vervanging van updates. Ze dicht echter geen kwetsbaarheid in de interpreter.
Neem de controle van de actieve waarde daarom op in uw routine na elke PHP-update. Een korte blik volstaat, kost nauwelijks tijd en voorkomt dat een verharding stilletjes verloren gaat.
Bij meerdere websites op één server: maak voor elke website een eigen pool met eigen lijst. Aanvullend beperkt open_basedir de mappen waartoe PHP toegang heeft.
Hoe helpt PHP SOS concreet?
- We controleren code en processen van uw toepassing op het gebruik van kritieke functies.
- We stellen per website een passende blokkadelijst vast en testen die vóór de livegang.
- We combineren de blokkade met pools, bestandsrechten en logging tot een sluitend verhardingsconcept.
- We documenteren de instellingen en bewaken het foutlog op opvallende aanroepen.
Hoe dat als totaalpakket verloopt, beschrijft de dienst Serververharding voor PHP-webservers.
Veelgestelde vragen
Kan ik disable_functions instellen via ini_set() of .htaccess?
Nee. De instelling werkt alleen vanuit de php.ini of als php_admin_value in de FPM-pool, respectievelijk in de Apache-configuratie. Tijdens de uitvoering is ze niet in te stellen en de toepassing kan geblokkeerde functies ook niet weer vrijgeven.
Beschermt disable_functions tegen PHP2Shell?
Nee. PHP2Shell treft de PHP-interpreter zelf; de kwetsbaarheid wordt alleen door de update gedicht. Geblokkeerde functies kunnen wel de speelruimte van een aanvaller na geslaagd misbruik beperken.
Waarom toont php -i een andere lijst dan mijn website?
De opdrachtregel leest vaak een eigen php.ini. Voor de website telt de configuratie van PHP-FPM, mod_php of LiteSpeed. Controleer de waarde daarom in de uitvoeringsmodus waarmee uw website draait.
Welke toepassingen hebben proc_open of exec nodig?
Dat hangt van de toepassing af. Typisch zijn beeldbewerking via externe programma's, pdf-aanmaak, e-mailverzending via sendmail of hulpmiddelen als Composer. Controleer dat in de code en in de systeemeisen van de fabrikant.