En bref : avec PHP disable_functions, vous bloquez les fonctions par lesquelles PHP exécute des commandes système, comme exec, shell_exec ou proc_open. Cela complique l'étape suivante pour les attaquants après une intrusion. Le réglage ne fonctionne qu'à partir de php.ini ou du pool FPM, doit être adapté à l'application et ne remplace pas une mise à jour.
Pourquoi disable_functions est judicieux précisément maintenant
PHP2Shell concerne l'exécution de code malveillant à distance sans authentification. Les deux failles CVE-2026-109618 et CVE-2026-109619 se trouvent dans l'interpréteur PHP lui-même, corrigées dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. La mise à jour est le seul moyen de les combler.
Le renforcement intervient à un niveau plus loin. Qui peut une fois exécuter du code sur un serveur veut généralement aller plus loin : lancer des commandes système, télécharger des outils, installer une porte dérobée durable. Beaucoup de ces étapes passent par quelques fonctions PHP. Si elles sont bloquées, le chemin devient plus pénible et plus visible.
disable_functions n'est donc pas un substitut aux correctifs, mais un maillon pour le cas où quelque chose passerait malgré toutes les précautions. Cela vaut aussi bien pour les failles futures que pour PHP2Shell.
Ce que PHP disable_functions apporte et ce qu'il n'apporte pas
Le réglage retire les fonctions indiquées de l'environnement d'exécution. Si un script appelle une fonction bloquée, PHP s'interrompt avec une erreur. Le blocage s'applique à tout code qui s'exécute dans ce processus PHP, donc aussi au code introduit.
Vous devriez connaître les limites :
- Le réglage n'est pas un espace de protection étanche. Des extensions PHP, des erreurs dans l'interpréteur ou des programmes extérieurs à PHP peuvent le contourner.
- Il n'empêche pas un attaquant de lire ou d'écrire des fichiers auxquels l'utilisateur PHP a accès. Ce sont les droits des fichiers et l'isolation qui en sont chargés.
- Il ne fonctionne qu'à partir de php.ini ou comme
php_admin_value. Il ne peut pas être défini avecini_set(),.user.iniou.htaccess.
disable_functions apporte le plus lorsqu'il est combiné à un php.ini propre, à des utilisateurs distincts par site et à des droits de fichiers restrictifs. Les bases figurent dans le guide Configurer php.ini de façon sécurisée.
Quelles fonctions bloquer
Pour les sites typiques sans besoin de commandes système, la liste suivante a fait ses preuves. Elle comprend des fonctions pour lancer des processus et pour piloter des processus en cours.
| Groupe | Fonctions | Usage légitime typique |
|---|---|---|
| Exécuter des commandes | exec, shell_exec, system, passthru |
Traitement d'images, sauvegardes par script |
| Ouvrir des processus | proc_open, popen |
Composer, outils PDF, envoi d'e-mails |
| Piloter des processus | proc_nice, proc_terminate, proc_get_status |
Files d'attente, tâches de fond |
| Gestion des processus | pcntl_exec, pcntl_fork |
généralement seulement en ligne de commande |
| Signaux et droits | posix_kill, posix_setuid |
rarement en exploitation web |
En configuration, cela donne :
; php.ini du mode d'exécution web, p. ex. /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
Si la liste ne s'applique pas à tous les sites du serveur, définissez-la par pool FPM. Après le rechargement, vérifiez quelle liste s'applique réellement dans ce pool :
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (extrait)
php_admin_value[disable_functions] = exec,shell_exec,system,passthru,proc_open,popen
Tester l'application au préalable : éviter les pannes
Qui définit la liste sans vérification risque de voir soudain ne plus fonctionner le redimensionnement d'images, les factures PDF ou l'envoi d'e-mails. Recherchez donc au préalable dans le code les fonctions concernées :
# Où et combien de fois les fonctions sont-elles utilisées dans le code ?
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
Des résultats ne signifient pas automatiquement que la fonction est nécessaire en exploitation. De nombreuses bibliothèques vérifient d'abord si une fonction est disponible et se rabattent sinon sur une alternative. Ce qui est décisif, c'est un test dans un environnement de préproduction avec tous les processus importants : commande, facture, envoi de formulaires, upload d'images, tâches planifiées.
Si une application exige impérativement l'une de ces fonctions, consultez la configuration requise de l'éditeur sur sa page officielle. Souvent, la tâche peut être déplacée vers un pool séparé ou un script en ligne de commande non accessible depuis le web.
Activer le réglage et contrôler son effet
Après la modification, PHP doit relire la configuration. Vérifiez ensuite la valeur dans le mode d'exécution de votre site, pas en ligne de commande :
sudo systemctl reload php8.3-fpm
php-fpm8.3 -i | grep "^disable_functions"
# Rechercher dans le journal d'erreurs des appels de fonctions bloquées
sudo grep -i "has been disabled" /var/log/php/*.log | tail -20
Les messages du journal d'erreurs restent précieux par la suite. Si des appels de fonctions bloquées y apparaissent soudain alors que votre application ne les utilise pas, cela peut indiquer du code introduit. La marche à suivre alors est décrite dans le guide Détecter et supprimer les webshells.
Erreurs typiques lors de l'utilisation de disable_functions
En pratique, le renforcement échoue rarement pour des raisons techniques, mais sur des détails. Ces erreurs sont particulièrement répandues :
- Mauvais fichier modifié : la liste ne figure que dans le php.ini de la ligne de commande, le site tourne via PHP-FPM et reste sans protection.
- Pas de redémarrage : le fichier est correct, mais les processus en cours travaillent encore avec l'ancienne configuration.
- Blocage trop large : des fonctions comme
ini_setoumailsont bloquées en même temps et des processus importants s'interrompent sans qu'on le remarque. Les erreurs ne se remarquent alors souvent que des jours plus tard, par exemple parce que les confirmations de commande n'arrivent plus. - Défini une fois, jamais vérifié : après un déménagement, un changement de version de PHP ou une réinstallation via le panneau d'hébergement, la liste a disparu.
- Faux sentiment de sécurité : le blocage est compris comme un substitut aux mises à jour. Or il ne comble aucune faille de l'interpréteur.
Intégrez donc le contrôle de la valeur active à votre routine après chaque mise à jour de PHP. Un coup d'œil bref suffit, ne coûte presque pas de temps et évite qu'un renforcement se perde silencieusement.
Avec plusieurs sites sur un serveur : créez pour chaque site un pool distinct avec sa propre liste. En complément, open_basedir limite les répertoires auxquels PHP peut accéder.
Comment PHP SOS aide-t-il concrètement ?
- Nous examinons le code et les processus de votre application quant à l'utilisation de fonctions critiques.
- Nous définissons pour chaque site une liste de blocage adaptée et la testons avant la mise en production.
- Nous combinons le blocage avec des pools, des droits de fichiers et la journalisation en un concept de renforcement cohérent.
- Nous documentons les réglages et surveillons le journal d'erreurs à la recherche d'appels suspects.
La prestation Renforcement de serveur pour serveurs web PHP décrit le déroulement de l'ensemble.
Questions fréquentes
Puis-je définir disable_functions avec ini_set() ou .htaccess ?
Non. Le réglage ne fonctionne qu'à partir de php.ini ou comme php_admin_value dans le pool FPM ou dans la configuration d'Apache. Il ne peut pas être défini à l'exécution, et l'application ne peut pas non plus réactiver des fonctions bloquées.
disable_functions protège-t-il contre PHP2Shell ?
Non. PHP2Shell concerne l'interpréteur PHP lui-même ; la faille n'est comblée que par la mise à jour. Des fonctions bloquées peuvent toutefois restreindre la marge de manœuvre d'un attaquant après une exploitation réussie.
Pourquoi php -i affiche-t-il une autre liste que mon site ?
La ligne de commande lit souvent son propre php.ini. Pour le site, c'est la configuration de PHP-FPM, de mod_php ou de LiteSpeed qui compte. Vérifiez donc la valeur dans le mode d'exécution par lequel votre site tourne.
Quelles applications ont besoin de proc_open ou d'exec ?
Cela dépend de l'application. Sont typiques le traitement d'images via des programmes externes, la génération de PDF, l'envoi d'e-mails via sendmail ou des outils comme Composer. Vérifiez-le dans le code et dans la configuration requise de l'éditeur.