Réparer soi-même la faille critique PHP : guide pas à pas
Deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619 (CVSS 9,2), permettent une exécution de code à distance sans authentification sur toutes les versions de PHP depuis la 5.4. Le correctif s’applique au niveau du serveur, pas dans votre code. Ce guide vous accompagne si vous administrez vous-même votre serveur.
Vous travaillez sur un serveur de production : prenez un snapshot ou une sauvegarde avant, prévoyez une fenêtre de maintenance, et testez sur un environnement de recette si vous en avez un.
🎯 Versions corrigées du 21 octobre 2026
Les correctifs sont publiés le 21 octobre 2026 à 14 h 00 UTC. Voici les versions minimales corrigées pour chaque branche. Comparez avec votre version pour savoir si vous êtes à jour.
| Branche | Version minimale corrigée | Statut |
|---|---|---|
| 8.5 | 8.5.12 | ✅ Corrigée |
| 8.4 | 8.4.27 | ✅ Corrigée |
| 8.3 | 8.3.36 | ✅ Corrigée |
| 8.2 | 8.2.35 | ✅ Corrigée |
| 8.1 | Aucune | ❌ Fin de vie : migrer |
| ≤ 8.0 | Aucune | ❌ Fin de vie : migrer |
Votre version actuelle
php -vExemple de sortie : PHP 8.4.26 (cli)
✅ Vous êtes à jour si…
Votre version est égale ou supérieure à la version minimale de votre branche (ex : 8.4.27, 8.4.28, 8.5.12…).
❌ Vous êtes vulnérable si…
Votre patch est inférieur au minimum (ex : 8.4.26 au lieu de 8.4.27), ou votre branche est 8.1 ou antérieure.
Comment lire un numéro de version : 8.4.27 = branche 8.4, patch 27. C’est le dernier chiffre qui compte pour savoir si le correctif est appliqué.
01
Identifier la version de PHP
En SSH :
php -vSans accès SSH : la page phpinfo(), ou directement votre panel d’hébergement (Plesk, cPanel, interface OVH/Infomaniak…).
| Branche | Statut (21 oct. 2026) | Correctifs jusqu’au | Correctif CVE-2026-109618 / 109619 |
|---|---|---|---|
| 8.5 | Active | 31 déc. 2029 | Oui |
| 8.4 | Active | 31 déc. 2028 | Oui |
| 8.3 | Sécurité seule | 31 déc. 2027 | Oui |
| 8.2 | Sécurité seule | 31 déc. 2026 | Oui |
| 8.1 | Fin de vie | depuis le 31 déc. 2025 | Non |
| 8.0 et avant | Fin de vie | depuis 2015 | Non |
Source : php.net, « Supported Versions » et « Unsupported Branches ».
02
Mesures d’atténuation en attendant le correctif
Le correctif officiel n’est publié qu’à 14 h 00 UTC. En attendant, ces mesures réduisent la surface d’attaque, sans remplacer la mise à jour.
Désactiver la progression des uploads en session (php.ini) : mettez session.upload_progress.enabled à Off dans votre php.ini. Ça ferme une des voies d’exploitation de « PHP2Shell », sans corriger la faille.
session.upload_progress.enabled = OffRedémarrez ensuite PHP (php-fpm / Apache) pour appliquer le réglage.
Règles WAF Cloudflare (gratuites) : Cloudflare a déployé des règles de pare-feu applicatif (WAF) disponibles gratuitement pour tous ses clients. Si votre site passe par Cloudflare, connectez-vous au tableau de bord, section Sécurité → WAF → Règles gérées, et activez les règles liées à « PHP2Shell ». Vos sites seront partiellement protégés en attendant le patch serveur.
Plesk et les anciennes versions de PHP : si votre serveur est géré avec Plesk, vérifiez dans votre licence si vous avez droit à des correctifs de sécurité pour des versions de PHP pourtant non supportées officiellement. Plesk propose parfois des patchs backportés : connectez-vous au panel, section Mises à jour, et cherchez une mise à jour PHP même si votre version est marquée « fin de vie ».
Ces mesures sont des pansements, pas des remèdes. La meilleure protection reste l’application du correctif officiel dès 14 h 00 UTC.
03
Appliquer le correctif officiel
Les versions corrigées sont publiées le 21 octobre 2026 à 14 h 00 UTC (16 h 00, heure de Paris). Avant cela, isolez vos applications d’Internet (recommandation CERT-EU). Selon votre système :
Debian / Ubuntu :
sudo apt update && sudo apt upgrade php*RHEL / CentOS / Rocky / Alma :
sudo yum update php*Panel (Plesk, cPanel) : attendez la mise à jour publiée par l’éditeur, ou appliquez-la manuellement depuis le panel.
Windows (IIS, XAMPP, WAMP) : téléchargez la version corrigée sur windows.php.net, remplacez le dossier PHP, redémarrez IIS.
04
Redémarrer les services
La nouvelle version n’est chargée qu’après redémarrage :
sudo systemctl restart php8.4-fpm apache2 nginxAdaptez le nom du service à votre version (php8.2-fpm, php8.3-fpm…) et à votre serveur web. Sur un panel, un redémarrage du service PHP suffit.
05
Vérifier l’installation
php -vLa version affichée doit être la version corrigée. Testez ensuite une page réelle de votre site et consultez les logs d’erreurs (/var/log/apache2/error.log, /var/log/php-fpm/, journalctl -u php-fpm…).
06
Votre version est en fin de vie (8.1 ou moins) ?
PHP 8.1 est en fin de vie depuis le 31 décembre 2025, tout comme 8.0, 7.4 et les branches antérieures. Aucun correctif ne sortira pour ces versions : il faudra migrer vers PHP 8.2 ou supérieur. C’est plus lourd qu’un patch (compatibilité des extensions, tests, fenêtre de maintenance), mais ça se prépare calmement.
Quelques conseils pour aborder sereinement
- ♥Un snapshot d’abord. Avant toute manipulation, prenez un snapshot de votre serveur ou une sauvegarde complète. C’est votre filet de sécurité si quelque chose tourne mal.
- ♥Privilégiez les heures creuses. Un redémarrage de PHP interrompt brièvement les requêtes. Planifiez la mise à jour tôt le matin ou en pleine nuit, quand le trafic est faible.
- ♥Testez sur un environnement de recette. Si vous en avez un, appliquez d’abord le patch sur un serveur de test identique. Mieux vaut découvrir un problème sur un clone que sur la production.
- ♥Gardez un œil sur les logs. Après la mise à jour, consultez les logs d’erreurs pendant quelques minutes. Une alerte précoce vaut mieux qu’un site indisponible.
- ♥Prévoyez un plan B. Notez la procédure de rollback (restauration du snapshot, downgrade de version) avant de commencer. Savoir comment revenir en arrière rassure.
- ♥Vous n’êtes pas seul. La communauté PHP est très active. En cas de doute, les forums, le Discord AFUP ou les groupes Slack sont là pour vous guider.
Pas à l’aise en ligne de commande ?
Sur un serveur de production, une mise à jour mal menée casse un site en pleine journée. Si vous n’êtes pas sûr de vous, faites appel à un expert : nous patchons votre serveur sous 2 h pour 899 € HT, tests et rapport compris, migration EOL incluse si besoin.