# Service de correctifs PHP : mise à jour installée, avec redémarrage et attestation

> Faire installer la mise à jour PHP : nous appliquons les versions corrigées, redémarrons tous les workers et attestons l'état par écrit. Pour entreprises et agences.

Source : https://phpsos.de/fr/leistungen/php-patch-service/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** qui veut faire installer une mise à jour PHP a besoin de plus que de nouveaux paquets : l'état exact des paquets, le redémarrage de tous les processus PHP et une preuve de cela sont déterminants. C'est précisément ce que fournit notre service de correctifs PHP. Vous recevez une attestation écrite par serveur, que vous pouvez présenter en interne ou à des tiers.

## Pourquoi une mise à jour PHP seule ne suffit souvent pas

Depuis le 21 octobre 2026, des correctifs existent pour les failles PHP2Shell CVE-2026-109618 et CVE-2026-109619. Le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) recommande la mise à jour immédiate. En pratique, nous voyons trois pierres d'achoppement typiques.

Premièrement, le numéro de version n'indique pas toujours l'état réel. Les distributions et les hébergeurs appliquent parfois des backports ; Plesk continue alors par exemple d'afficher 8.2.34 alors que l'état des paquets est corrigé. Deuxièmement, après l'installation, d'anciens processus PHP continuent souvent de tourner. De nouveaux fichiers sur le disque ne protègent pas tant que les anciens workers travaillent en mémoire. Troisièmement, plusieurs versions de PHP fonctionnent souvent en parallèle sur un serveur, et l'une d'elles est oubliée.

## Faire installer la mise à jour PHP : les versions corrigées

| Branche | Corrigée à partir de | État précédent | Remarque |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | vérifier en plus `fatal_error_backtraces` |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | la prise en charge s'achève le 31 décembre 2026 |
| PHP 8.1 et antérieures | aucune mise à jour officielle | – | seulement des backports minimaux du code source pour 7.4, 8.0, 8.1 |

Pour les paquets issus de distributions ou d'hébergeurs, ce n'est pas le chiffre après « PHP » qui compte, mais l'état des paquets que le fournisseur confirme comme corrigé. Comment le vérifier vous-même, vous le trouverez sous [Bien vérifier la version de PHP et l'état des correctifs](https://phpsos.de/fr/php2shell/php-version-pruefen/).

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

1. **Inventaire :** nous recensons toutes les installations PHP du serveur, le mode d'exécution (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) et quelle version utilise chaque site web.
2. **Installer la mise à jour :** nous installons les versions corrigées à partir de la source de paquets de votre distribution, de votre panneau d'administration ou du projet officiel. Pour les conteneurs, nous construisons de nouvelles images avec vous.
3. **Redémarrage de tous les processus :** nous redémarrons entièrement PHP-FPM, Apache, LiteSpeed ou les workers concernés et contrôlons qu'aucun processus n'est plus ancien que la mise à jour. Le contexte figure sur [Redémarrer PHP-FPM et tous les workers](https://phpsos.de/fr/php2shell/php-fpm-neustart/).
4. **Contrôle du fonctionnement :** nous ouvrons les pages et fonctions les plus importantes, par exemple la page d'accueil, la connexion, les formulaires et la caisse, et vérifions les journaux d'erreurs.
5. **Attestation :** vous recevez par serveur un procès-verbal avec la version, l'état des paquets, l'heure du redémarrage et les points ouverts.

Une étape de contrôle typique après le redémarrage ressemble à ceci :

```bash
# Version de la CLI PHP et du binaire FPM (chemin selon le système)
php -v
php-fpm8.3 -v
# Heure de démarrage des processus FPM : doit être postérieure à la mise à jour
ps -o pid,lstart,cmd -C php-fpm8.3
```

## Cas particuliers : panneaux d'administration, conteneurs et plusieurs versions de PHP

Sur les serveurs avec **Plesk ou cPanel**, les versions de PHP proviennent souvent des sources de paquets du panneau et non de la distribution. Nous y vérifions chaque version installée individuellement, y compris celles qui ne sont actuellement attribuées à aucun site web. Les versions inutilisées et obsolètes, nous les supprimons après concertation, afin qu'elles ne soient pas réactivées par erreur.

Dans les environnements **Docker et Kubernetes**, une mise à jour sur l'hôte ne suffit pas. PHP se trouve dans l'image, et seule une image reconstruite sur une base corrigée, déployée sur tous les conteneurs en cours d'exécution, referme la faille. Nous vérifions aussi si d'anciennes images sont encore utilisées dans des registres ou des déploiements. Les détails figurent sous [Corriger PHP dans les conteneurs Docker](https://phpsos.de/fr/php2shell/docker-container-patchen/).

Avec **mod_php**, PHP s'exécute directement dans le processus Apache. L'équipe PHP y estime le risque le plus élevé. Après la mise à jour, Apache lui-même doit donc être redémarré complètement ; un simple rechargement de la configuration ne suffit pas dans tous les cas.

## Ce que vous recevez de notre part

- un procès-verbal de correctifs par serveur : paquets installés, versions, source, heure
- la preuve que tous les processus PHP ont été redémarrés
- une liste des sites web et fonctions vérifiés
- des indications sur les systèmes qui n'ont pas pu être corrigés, avec justification
- une recommandation pour la suite, par exemple pour PHP 8.2 en raison de la fin proche de la prise en charge

## Ce dont nous avons besoin de votre part

- **Accès :** SSH avec droits d'administrateur ou accès au panneau d'administration (Plesk, cPanel ou similaire)
- **Fenêtre de maintenance :** quand un bref redémarrage est autorisé
- **Interlocuteur :** pour les questions et pour la validation après le contrôle du fonctionnement
- **Sauvegardes :** la confirmation qu'une sauvegarde récente existe, ou la mission d'en créer une au préalable
- **Indications sur les développements spécifiques :** extensions PHP particulières ou configurations dont il faut tenir compte

Avec un hébergement mutualisé sans accès propre au serveur, nous ne pouvons pas appliquer les correctifs nous-mêmes. Nous vous aidons alors à poser les bonnes questions à l'hébergeur et à évaluer la réponse.

## Ce que nous ne promettons pas

Le service de correctifs referme la faille connue. Il ne répond pas à la question de savoir si le serveur était déjà compromis avant la mise à jour, et ne supprime aucun logiciel malveillant introduit. Si vous voulez le savoir, l'[assistance immédiate PHP2Shell](https://phpsos.de/fr/leistungen/php2shell-soforthilfe/) avec recherche de traces est la mission appropriée.

Pour PHP 8.1 et les versions antérieures, il n'existe plus de mises à jour officielles. Nous mettons ici en œuvre des mesures transitoires et recommandons la [migration vers une version prise en charge](https://phpsos.de/fr/leistungen/php-migration-legacy/). Nous ne donnons pas de garantie de compatibilité pour votre CMS de mémoire, mais la vérifions à partir des exigences système de l'éditeur.


## Questions fréquentes

**Pourquoi mon serveur affiche-t-il encore l'ancienne version de PHP après la mise à jour ?**  
Il peut y avoir deux raisons. Soit la distribution a appliqué un backport : le numéro de version reste alors identique alors que l'état des paquets est corrigé. Soit d'anciens processus PHP tournent encore en mémoire et doivent être redémarrés.

**Quelles versions de PHP referment PHP2Shell ?**  
La faille est corrigée dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiés le 21 octobre 2026. Pour les paquets de distribution, c'est l'état des paquets que le fournisseur confirme comme corrigé qui compte.

**La mise à jour peut-elle paralyser mon site web ?**  
Une mise à jour au sein de la même version majeure, par exemple de 8.3.35 à 8.3.36, est en règle générale sans risque. Un bref redémarrage des processus PHP est toutefois nécessaire. Nous convenons du créneau avec vous et vérifions les pages ensuite.

**Tout est-il réglé avec le correctif ?**  
Pour la faille elle-même, oui, dès que tous les processus ont été redémarrés. Le correctif ne montre pas si quelqu'un s'est introduit avant lui. Cela exige une vérification distincte.

## Sources

- [php.net : avis de sécurité](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net : versions prises en charge](https://www.php.net/supported-versions.php)
- [BSI : office fédéral allemand de la sécurité des technologies de l'information](https://www.bsi.bund.de/)