Les bases de PHP pour les administrateurs

En bref : pour les administrateurs sans profil développeur, cinq bases suffisent pour exploiter PHP en sécurité : PHP se compose de plusieurs programmes (ligne de commande, PHP-FPM, module Apache), chacun avec sa propre version ; les réglages agissent par niveaux, du php.ini à l'application ; PHP-FPM répartit les requêtes sur des workers dans des pools ; une mise à jour n'agit qu'après le redémarrage de tous les processus ; et les logs sont l'indice le plus important quand quelque chose ne va pas. Qui connaît ces points peut combler rapidement et de façon démontrable des failles comme PHP2Shell.

De quoi PHP se compose sur un serveur

PHP n'est pas un programme unique. Sur un serveur Linux typique, on trouve plusieurs variantes, chacune reliée via une interface serveur (SAPI) :

Chaque variante peut avoir une autre version et un autre php.ini. Sur de nombreux serveurs, plusieurs versions de PHP tournent en outre en parallèle, par exemple 8.2 et 8.4. Lors d'une mise à jour, chacune doit être considérée séparément. Le fonctionnement des interfaces est expliqué dans PHP-FPM expliqué.

Vous trouvez quelle variante dessert réellement vos sites web grâce aux processus en cours et à la configuration du serveur web :

ps -eo pid,user,lstart,cmd | grep -E "php|httpd|apache2" | grep -v grep
apachectl -M 2>/dev/null | grep -i php     # Apache charge-t-il un module PHP ?
ls /run/php/ 2>/dev/null                    # sockets FPM, souvent par version et par pool

La colonne de l'heure de démarrage sera importante plus tard lors du redémarrage : tous les processus PHP doivent avoir été démarrés après le moment de la mise à jour. Si des processus tournent sous différents utilisateurs, cela indique des pools séparés, ce qui est bon. Si un module PHP apparaît dans Apache alors que tous les sites sont censés passer par FPM, c'est le signe d'un héritage à retirer. Pour les interfaces d'hébergement comme Plesk ou cPanel, le même principe s'applique, sauf que l'interface affiche les versions et les handlers par site web ; ce qui fait foi reste toutefois ce qui tourne réellement comme processus.

Les commandes les plus importantes pour les admins

php -v                    # version de la ligne de commande
php --ini                 # php.ini chargé et répertoires lus en plus
php --ini=diff            # à partir de PHP 8.5 : écarts par rapport à la valeur par défaut
php -m                    # modules compilés et chargés
php --ri session          # réglages d'une extension
php -l datei.php          # vérification de syntaxe sans exécution
php-fpm8.3 -v             # version du binaire FPM (nom selon la distribution)
php-fpm8.3 -t             # tester la configuration FPM sans redémarrer
systemctl status php8.3-fpm

Deux remarques tirées du manuel : php -l trouve les erreurs de syntaxe, mais pas les erreurs qui n'apparaissent qu'à l'exécution. Et php -i appelle phpinfo() ; la sortie n'a pas sa place dans des fichiers publics du répertoire web.

Comment les réglages de PHP agissent

Un réglage peut être défini à plusieurs endroits. Qui peut modifier quoi et où est déterminé par le mode de modification de chaque directive :

1. php.ini et conf.d : configuration de base par variante, lue au démarrage.
2. Pool FPM : php_value et php_admin_value par pool. Selon le manuel, l'application ne peut pas redéfinir par ini_set() les valeurs fixées avec php_admin_value.
3. Niveau répertoire : .user.ini pour FPM ou .htaccess pour mod_php, uniquement pour les directives en mode INI_PERDIR ou INI_ALL.
4. Application : ini_set() à l'exécution, uniquement pour les directives en mode INI_ALL.

Un exemple : memory_limit a le mode INI_ALL, peut donc être modifié par l'application. post_max_size a INI_PERDIR et ne peut pas être modifié par ini_set(). C'est pourquoi php.net exige, pour les mesures transitoires PHP2Shell, de définir les valeurs de façon que les applications ne puissent pas les redéfinir. Les détails sur les niveaux sont expliqués dans Le php.ini expliqué.

Les pools PHP-FPM en bref

Un pool est un groupe de workers avec son propre utilisateur, son propre socket et ses propres réglages. Les directives les plus importantes selon le manuel :

[shop]
user = shop
group = shop
listen = /run/php/shop.sock
pm = dynamic                 ; static, dynamic ou ondemand
pm.max_children = 20         ; au plus 20 requêtes simultanées
pm.max_requests = 500        ; renouveler le worker après 500 requêtes
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

Un pool dédié par site web, avec son propre utilisateur, sépare les sites les uns des autres. security.limit_extensions est par défaut sur .php .phar et empêche FPM d'exécuter d'autres extensions de fichier que PHP. clear_env est activé par défaut et tient les variables d'environnement à l'écart du worker.

Logs : où les administrateurs doivent regarder

PHP écrit les erreurs vers la destination définie avec error_log, PHP-FPM en plus dans son propre log et, pour les requêtes lentes, dans le slowlog avec trace d'appels. S'y ajoutent les logs d'accès et d'erreurs du serveur web. Veillez à ce que display_errors soit désactivé en production et log_errors activé : les erreurs vont dans le log, pas sur la page web. Les logs devraient en outre être archivés par rotation et conservés pendant une durée définie, afin d'être encore disponibles en cas d'urgence. Après PHP2Shell, la presse spécialisée recommande de conserver les logs du serveur à partir du 20 octobre 2026. Un processus PHP-FPM ou serveur web qui lance un shell est un signal d'alerte fort ; la manière de le détecter est décrite sous Signal d'alerte : le serveur web lance un shell.

Liste de contrôle pour les admins après PHP2Shell

1. Lister toutes les variantes et versions de PHP sur le serveur, y compris celles qui ne sont pas utilisées.
2. Vérifier le niveau des paquets ; pour les rétroportages de la distribution, chercher CVE-2026-109618 et CVE-2026-109619 dans le journal des modifications.
3. Mettre à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou vers le rétroportage confirmé.
4. Redémarrer PHP-FPM, Apache et LiteSpeed et contrôler les heures de démarrage des processus.
5. Contre-vérification avec php -r 'var_dump(ini_get("memory_hard_limit_percent"));' ; bool(false) signifie, selon le manuel, une version concernée.
6. Sauvegarder les logs et les examiner à la recherche d'anomalies.

La manière de prouver de façon fiable la version et le niveau de correctifs est décrite dans Vérifier correctement la version de PHP et le niveau de correctifs.

Comment PHP SOS aide-t-il concrètement ?

Dans le contrat de maintenance de sécurité, nous assurons avec votre équipe l'entretien de base de PHP :

• Inventaire : toutes les variantes de PHP, versions, pools et emplacements de configuration par serveur.
• Configuration : valeurs importantes pour la sécurité définies avec php_admin_value, pools séparés par site web.
• Mises à jour : installation, redémarrage, contrôle et documentation à chaque version de sécurité.
• Transmettre le savoir : nous expliquons à vos administrateurs ce que nous avons modifié et pourquoi.

Questions fréquentes

Sources

• Manuel PHP : options de la ligne de commande
• Manuel PHP : configuration de FPM
• Manuel PHP : directives du cœur
• php.net : avis de sécurité