Comment mettre à jour PHP sur votre serveur ou votre hébergement : le guide pas à pas

Mettre à jour PHP est le seul moyen complet de corriger les failles critiques publiées le 21 octobre 2026 (CVE-2026-109618 et CVE-2026-109619, détaillées dans notre article sur la faille PHP). Le problème, c'est que la procédure dépend entièrement de la façon dont votre site est hébergé : sur un hébergement infogéré, quelqu'un le fait pour vous ; sur un VPS, personne ne le fera à votre place. Ce guide passe en revue chaque cas, puis les vérifications qui confirment que le correctif est bien actif.

Étape 0 : savoir où vous en êtes

Avant de toucher à quoi que ce soit, notez la version actuelle de chaque installation. Trois méthodes selon votre accès :

• En ligne de commande : php -v affiche la version utilisée par le terminal. Sur un serveur avec plusieurs versions installées, ls /etc/php les liste toutes, et php8.4 -v (ou php8.3 -v) interroge une version précise.
• Depuis WordPress : Outils, puis Santé du site, onglet Informations, section Serveur.
• Depuis un panneau d'hébergement : cPanel affiche la version dans « Sélectionner une version PHP » ou « MultiPHP Manager » ; Plesk dans les réglages PHP de chaque domaine.

Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Tout numéro inférieur dans la même branche est vulnérable. PHP 8.1 et plus ancien n'ont pas de correctif : passez directement à la migration vers une version supportée.

Cas 1 : hébergement WordPress infogéré ou mutualisé

Sur un hébergement infogéré (les offres WordPress clés en main) ou un mutualisé classique, c'est l'hébergeur qui met à jour PHP sur ses serveurs. Votre travail se limite à vérifier qu'il l'a fait.

1. Consultez la page de statut ou les emails de votre hébergeur. Les grands acteurs ont communiqué dès le 21 octobre.
2. Si vous n'avez rien reçu en fin de journée, ouvrez un ticket au support en demandant explicitement si la publication PHP du 21 octobre 2026 est appliquée.
3. Dans votre panneau, vérifiez quelle branche PHP est sélectionnée pour votre site. Si c'est 8.1, 8.0 ou 7.4, basculez vers 8.3 ou 8.4 après un test (voir l'article sur la migration).
4. Après la mise à jour, parcourez les pages clés du site : accueil, formulaires, panier et paiement si vous vendez en ligne.

Sur cPanel, le mode d'exécution de PHP compte aussi. Si votre serveur utilise Apache avec mod_php (parfois appelé DSO), le risque est le plus élevé ; demandez à l'hébergeur s'il peut passer en PHP-FPM, ce qui améliore aussi les performances.

Cas 2 : VPS ou serveur dédié sous Ubuntu ou Debian

Ici, personne ne mettra PHP à jour à votre place, et les mises à jour automatiques de sécurité d'Ubuntu ne couvrent pas PHP installé depuis un dépôt tiers (le dépôt d'Ondřej Surý, utilisé par la plupart des serveurs Laravel et par des outils comme Forge). La procédure :

1. Rafraîchissez les listes de paquets : sudo apt-get update.
2. Vérifiez quelle version sera installée : apt-cache policy php8.4-fpm. La ligne « Candidate » doit afficher 8.4.27 (ou l'équivalent de votre branche). Si ce n'est pas le cas, le dépôt n'a pas encore reçu les paquets : réessayez un peu plus tard.
3. Mettez à jour tous les paquets de la branche, sans en installer de nouveaux et en conservant vos fichiers de configuration : sudo apt-get install --only-upgrade -y -o Dpkg::Options::="--force-confold" $(dpkg -l 'php8.4*' | awk '/^ii/ {print $2}').
4. Répétez pour chaque version installée, y compris celles qu'aucun site n'utilise actuellement (un site peut y être basculé plus tard).
5. Vérifiez que PHP-FPM a redémarré : systemctl status php8.4-fpm. Sinon : sudo systemctl restart php8.4-fpm. Avec Apache et mod_php : sudo systemctl restart apache2.

Sur les paquets fournis par Debian ou Ubuntu eux-mêmes (sans dépôt tiers), le correctif peut être rétroporté sans changer le numéro de version affiché. apt changelog php8.2 ou le journal du paquet indique alors si les CVE-2026-109618 et 109619 sont mentionnés.

Cas 3 : serveur avec panneau cPanel ou Plesk

Les panneaux installent leurs propres builds de PHP. Sur cPanel/WHM, les versions EasyApache se mettent à jour via les mises à jour automatiques du serveur ou manuellement dans WHM (EasyApache 4, puis mise à jour des paquets). Sur Plesk, les versions fournies par Plesk se mettent à jour depuis Outils et paramètres, Mises à jour. Si vous utilisez CloudLinux, les versions PHP alternatives suivent leur propre cycle, et Imunify360 publie des règles de blocage qui, selon l'éditeur, bloquent l'exploit public sur Apache mais le journalisent seulement sur LiteSpeed. Dans tous les cas, vérifiez après coup que chaque domaine utilise une version corrigée.

Cas 4 : Docker et conteneurs

Une image de conteneur fige la version de PHP qu'elle contient. Mettre à jour le serveur hôte ne change rien : il faut reconstruire l'image à partir d'une image de base corrigée (par exemple php:8.4-fpm republiée après le 21 octobre, ou l'image officielle de votre framework), puis redéployer. Vérifiez la version dans le conteneur en cours d'exécution avec docker exec <conteneur> php -v. Si vous utilisez FrankenPHP, qui est aussi concerné, attendez l'image reconstruite avec PHP corrigé.

Étape finale : redémarrer les processus de longue durée

La mise à jour du paquet redémarre PHP-FPM, mais pas les processus PHP lancés en ligne de commande qui tournent en continu : workers de files d'attente, Laravel Horizon, Octane, Reverb, tâches planifiées longues, daemons maison. Ils gardent l'ancienne version de PHP en mémoire tant qu'ils ne sont pas relancés. Pour une application Laravel : php artisan queue:restart, php artisan horizon:terminate, php artisan octane:reload. Pour un service géré par Supervisor : supervisorctl restart all.

Vérifier que le correctif est actif

• php8.4 -v et php-fpm8.4 -v doivent tous deux afficher la version corrigée.
• Une page phpinfo() temporaire (à supprimer ensuite) confirme la version servie via le web, qui peut différer de celle du terminal.
• Sur WordPress, la rubrique Santé du site doit afficher la nouvelle version.
• Parcourez les parcours critiques : connexion, formulaire de contact, commande, espace client.
• Surveillez les journaux d'erreurs PHP et les temps de réponse pendant les 24 heures suivantes.

Si la mise à jour casse quelque chose

Une mise à jour mineure (8.4.26 vers 8.4.27) ne change pas le comportement du langage et casse très rarement un site. Si un problème apparaît, il vient en général d'une extension PHP compilée pour l'ancienne version ou d'un cache d'opcode à vider (opcache_reset() ou redémarrage de FPM). Un changement de branche (8.1 vers 8.4) est une autre affaire : des extensions ou plugins anciens peuvent échouer, d'où l'intérêt d'un environnement de test.

Déléguer les mises à jour

Si cette procédure vous paraît lourde pour un mardi après-midi, c'est exactement ce que couvre notre maintenance et accompagnement : inventaire des versions, mise à jour sur environnement de test puis production, redémarrage des services, vérification des parcours et surveillance. Vous ne savez pas qui gère votre serveur ? Écrivez-nous, nous ferons le point.