# Après PHP2Shell : pourquoi d'autres avis sont probables

> Après PHP2Shell, d'autres avis PHP sont probables. À quoi le reconnaître, quelles sources suivre et comment votre équipe réagit de façon préparée.

Source : https://phpsos.de/fr/blog/weitere-php-meldungen/  
É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 :** après PHP2Shell, d'autres avis sur PHP sont probables, car un troisième avis est déjà paru deux jours après le correctif, un avis complet reste attendu et les distributions livrent leurs paquets de façon échelonnée. Qui met en place dès maintenant une procédure fixe pour la surveillance, l'évaluation, la mise à jour et le redémarrage réagira à la prochaine nouvelle faille de sécurité PHP en heures plutôt qu'en jours.

## Le correctif n'était pas la fin de l'histoire

Le 21 octobre 2026, le projet PHP a fermé les deux failles critiques CVE-2026-109618 et CVE-2026-109619 avec les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. De nombreux responsables ont ensuite coché la case. Deux jours plus tard, le 23 octobre, un nouvel avis de php.net est toutefois paru sur CVE-2026-115560.

Ce troisième avis ne concerne qu'une configuration de session inhabituelle. Mais il montre un schéma connu des grands cas de sécurité : lorsqu'un composant se retrouve soudain sous les projecteurs, de nombreux spécialistes regardent de plus près en même temps. Si d'autres failles en naîtront, personne ne le sait aujourd'hui. Mais il est probable que l'actualité ne s'arrête pas.

Pour vous, exploitant, cela signifie : prévoyez des avis de suite au lieu d'être surpris par chacun. Le déroulement des événements jusqu'ici est résumé dans notre [chronologie de PHP2Shell](https://phpsos.de/fr/ratgeber/php2shell-chronologie/).

## Pourquoi d'autres avis sont probables

L'évaluation suivante repose sur des faits publiquement connus. Elle n'est pas une prévision de failles concrètes.

1. **Un avis complet reste en suspens.** php.net traite CVE-2026-115560 dans le cycle de publication régulier et a annoncé qu'il publierait l'avis complet avec la prochaine version. D'ici là, `session.upload_progress.enabled=0` fait office de remède.
2. **Les détails étaient publics très tôt.** Selon plusieurs rapports, des détails sont devenus connus avant la fin de l'embargo. Selon des rapports, watchTowr a reproduit CVE-2026-109618 selon ses propres indications. De tels travaux conduisent souvent à des questions de suite sur des passages de code voisins.
3. **Les distributions livrent de façon échelonnée.** Ubuntu a approvisionné le 21 octobre les versions actuelles avec USN-8948-1 et a fourni ensuite avec USN-8948-2 des corrections pour 14.04 à 20.04 via Ubuntu Pro. Red Hat a écrit dans son bulletin que certaines mises à jour étaient disponibles, d'autres en cours.
4. **La version de développement est concernée.** Selon php.net, PHP 8.6.0 RC4 contient aussi les corrections. Qui teste des préversions doit également mettre à niveau ces environnements.
5. **Les anciennes versions restent ouvertes.** Pour PHP 8.1 et plus ancien, il n'existe que des rétroportages minimaux du code source. Chaque fournisseur qui livre de telles versions communique son état de façon autonome et à ses propres moments.

## Comment une nouvelle faille de sécurité PHP vous parvient

Les avis arrivent par différentes voies et avec une fiabilité variable. L'ordre est presque toujours le même : d'abord le projet PHP, puis les distributions et hébergeurs, ensuite les autorités et les médias.

| Source | Ce que vous y apprenez | Fiabilité |
|---|---|---|
| php.net | branches concernées, versions corrigées, mesures transitoires | source primaire |
| Ubuntu, Debian, Red Hat | niveaux de paquets par version, moment de la livraison | source primaire pour votre système |
| Hébergeurs et éditeurs de panneaux | état de leurs propres builds PHP | contraignant seulement par écrit |
| BSI, CERT-Bund | évaluation de la situation, niveau d'alerte, recommandations | classement par une autorité |
| Presse spécialisée et sociétés de sécurité | observations d'attaques, chiffres, contexte | utile, à présenter comme un rapport |

La différence entre « il existe un correctif » et « mon système a le correctif » est importante. La première affirmation figure sur php.net. La seconde, vous devez la prouver vous-même pour chaque serveur.

> **Astuce:**
> Abonnez-vous aux avis de php.net et de votre distribution par RSS ou liste de diffusion et transférez-les vers une boîte aux lettres commune ou un canal lu par plus d'une personne. Les congés et la maladie sont les raisons les plus fréquentes de mises à jour tardives.

## Ce que vous devriez préparer avant le prochain avis

L'expérience de PHP2Shell montre où le temps se perd : dans la recherche des serveurs, dans la clarification des responsabilités et dans le redémarrage oublié. Tout cela peut être réglé à l'avance.

- **Inventaire :** une liste de tous les serveurs et sites avec branche PHP, mode d'exécution (PHP-FPM, mod_php, LiteSpeed) et source des paquets. Sans cette liste, chaque avis commence par une recherche. Comment y parvenir, l'article [Inventaire de tous les sites web et serveurs](https://phpsos.de/fr/blog/inventar-websites-server/) le décrit.
- **Responsabilité :** pour chaque système, il est établi qui corrige, qui redémarre et qui valide. Chez les hébergeurs et agences, cela relève du contrat.
- **Grille d'évaluation :** trois questions suffisent pour un premier classement. Notre branche est-elle concernée ? Utilisons-nous la fonction ou le mode d'exécution concerné ? Existe-t-il un correctif ou seulement des mesures transitoires ?
- **Voie de test :** un environnement de préproduction dans lequel une mise à jour de PHP peut être vérifiée en peu de temps.
- **Preuve :** un format fixe dans lequel sont consignés le niveau des paquets, la correspondance dans le changelog et l'heure du redémarrage.

Comment une telle procédure fonctionne comme une routine plutôt que comme une intervention d'urgence, c'est ce que décrit [La gestion des correctifs comme processus](https://phpsos.de/fr/blog/patch-management-prozess/). Le contexte de la manière dont le projet PHP traite les failles figure sur la page [Comment le projet PHP traite les failles de sécurité](https://phpsos.de/fr/php/php-sicherheitsprozess/).

## Sa propre configuration comme système d'alerte précoce

Une partie des avis de suite ne concerne que certains paramètres. CVE-2026-115560 en est un exemple : php.net cite comme condition qu'une application modifie le sérialiseur de session à l'exécution pendant que l'upload progress est actif. Les applications qui ne le font jamais ne sont, selon php.net, pas concernées.

Qui connaît sa configuration effective peut classer plus vite de tels avis. Consignez donc, pour chaque branche, quelles valeurs sont définies côté serveur et quelles applications peuvent les écraser. Un simple recoupement des paramètres actifs aide déjà :

```bash
# Valeurs effectives en ligne de commande (la configuration web peut différer)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"

# Valeurs définies dans les pools FPM (chemin variable selon la distribution)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
```

La ligne de commande ne montre pas nécessairement ce qui s'applique dans le contexte web. La configuration du pool ou du VirtualHost et, brièvement et de façon protégée, une page phpinfo apportent la clarté.

Autre avantage : qui sait quelles valeurs transitoires de la semaine PHP2Shell sont encore en place peut les réexaminer sciemment après la prochaine version régulière. Certains paramètres, comme un upload progress désactivé, peuvent rester judicieux durablement. D'autres, comme des limites d'envoi très serrées, devraient être réajustés au besoin réel après concertation avec les services métiers.

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

- Nous suivons les avis de php.net, des distributions et du BSI et évaluons les nouvelles informations pour vos systèmes concrets.
- Nous établissons avec vous l'inventaire de toutes les installations PHP et définissons les responsabilités par serveur.
- Dans le cadre d'un [contrat de maintenance de sécurité](https://phpsos.de/fr/leistungen/security-wartungsvertrag/), nous installons les mises à jour, redémarrons tous les processus et documentons l'état.
- Pour les avis sans correctif, nous appliquons des mesures transitoires non écrasables et les vérifions ensuite.


## Questions fréquentes

**Y a-t-il déjà une nouvelle faille de sécurité PHP après PHP2Shell ?**  
Le 23 octobre 2026, php.net a publié un avis sur CVE-2026-115560. L'exécution de code n'y est possible qu'avec une configuration de session inhabituelle. Un avis complet doit suivre avec la prochaine version régulière.

**Dois-je agir immédiatement après chaque nouvel avis ?**  
Tous les avis n'exigent pas la même urgence. Les critères déterminants sont la gravité, la mesure dans laquelle votre configuration est concernée et la disponibilité d'un correctif. Une procédure définie aide à évaluer cela en minutes plutôt qu'en jours.

**Où apprendre en premier l'existence de nouvelles failles PHP ?**  
Les sources primaires sont les avis de php.net et les consignes de sécurité de votre distribution, par exemple les Ubuntu Security Notices, le Debian Security Tracker ou Red Hat. Le BSI informe par des alertes. Les articles de presse sont utiles, mais souvent plus tardifs et moins précis.

**Pourquoi les distributions publient-elles parfois des jours après php.net ?**  
Les distributions doivent reprendre la correction dans leurs propres paquets, les construire et les tester. Pour les versions plus anciennes, cela peut prendre plus de temps ou ne se faire que via des offres supplémentaires. Il vaut donc la peine de suivre les deux sources séparément.

## Sources

- [php.net : avis et consignes de sécurité](https://www.php.net/)
- [Ubuntu Security Notice USN-8948-2](https://ubuntu.com/security/notices/USN-8948-2)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [BSI](https://www.bsi.bund.de/)