# Comment le projet PHP traite les failles de sécurité

> Comment le projet PHP traite les failles : signalement via GitHub ou security@php.net, classification, correctif et conclusions pour les exploitants.

Source : https://phpsos.de/fr/php/php-sicherheitsprozess/  
É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 :** les failles de sécurité de PHP sont signalées de façon confidentielle, de préférence via le formulaire d'advisory privé du dépôt GitHub `php/php-src`, sinon à security@php.net. Les développeurs de PHP classent la découverte comme élevée, moyenne ou faible ; les erreurs graves sont corrigées dans un dépôt de sécurité distinct et ne sont publiées qu'avec la version, accompagnées d'un GitHub Security Advisory et, le plus souvent, d'un numéro CVE. Avec PHP2Shell, ce processus s'est déroulé à toute vitesse : pré-annonce le 20 octobre 2026, correctifs le 21 octobre 2026, avis complémentaire le 23 octobre 2026.

## Qui s'occupe de la sécurité chez PHP ?

PHP est un projet open source. La politique de sécurité du wiki le décrit comme un projet de bénévoles sans budget pour des primes. Pour chaque version, il existe des release managers qui assument la responsabilité des publications. S'y ajoute la PHP Foundation, qui, selon sa propre présentation, mandate une équipe de développeurs à temps partiel et à temps plein travaillant à la maintenance, à la sécurité et aux nouvelles fonctionnalités de PHP.

Pour les entreprises, cela signifie : il n'y a pas d'éditeur avec contrat, hotline ou délais de réaction garantis. Qui a besoin d'engagements fermes les obtient de sa distribution Linux, de son hébergeur ou d'un fournisseur de support à long terme, non du projet PHP lui-même. Vous devriez connaître cette chaîne d'approvisionnement.

## Comment une faille est signalée

La voie est décrite dans la politique de sécurité sur GitHub :

1. **Signaler :** via le formulaire privé des Security Advisories du dépôt `php/php-src`. Qui ne peut pas l'utiliser ou souhaite aborder un sujet qui n'est pas un rapport d'erreur écrit à security@php.net.
2. **Décrire brièvement :** on souhaite un court exemple qui montre l'erreur, pas un long rapport sur les conséquences possibles. L'équipe peut ainsi trier plus vite.
3. **Confidentialité :** le signalement reste privé jusqu'à sa publication.
4. **Mention :** les personnes qui signalent sont citées comme contributeurs, selon le système de crédits de MITRE.

L'ancienne page du wiki mentionne en outre le traqueur de bogues classique avec le type « Security ». La voie par GitHub fait aujourd'hui foi.

## Ce que le projet PHP classe comme faille de sécurité

Tout plantage n'est pas une faille de sécurité. Le wiki cite quatre critères : une erreur permet des actions non autorisées, franchit des frontières de sécurité, ouvre l'accès à des données tierces ou nuit gravement à la disponibilité ou aux performances. La classification comporte trois niveaux :

| Niveau | Signification selon la politique | Numéro CVE |
|---|---|---|
| Élevé | des tiers peuvent compromettre la plupart des installations, exécuter du code ou lire des fichiers | en règle générale oui |
| Moyen | effet similaire, mais seulement dans des conditions plus rares, par exemple une extension ou une configuration rare | le plus souvent oui |
| Faible | théoriquement possible, pratiquement très difficile à exploiter | le plus souvent non |

La liste de ce qui n'est expressément pas une faille de sécurité est tout aussi instructive : code malveillant exécuté volontairement, contournements de `open_basedir` et de `disable_functions`, entrées malveillantes transmises à `unserialize()`, utilisation de FFI et arrêt ordinaire pour manque de mémoire où `memory_limit` s'applique et où seule la requête en cours se termine. Pour les exploitants, cela signifie : [disable_functions](https://phpsos.de/fr/ratgeber/disable-functions/) est un durcissement judicieux, mais pas un rempart.

## Du correctif à la publication

Les correctifs pour les failles élevées et moyennes sont, selon le wiki, intégrés dans un dépôt de sécurité distinct avant la création de la version. Les erreurs classées comme faibles suivent le circuit des corrections de bogues normales. La faille est publiée selon le principe de la divulgation responsable : d'abord le correctif, ensuite les détails. Selon le wiki, les versions paraissent le plus souvent le jeudi, souvent dans le cadre des publications mensuelles régulières.

Avec la version paraît un GitHub Security Advisory avec son propre identifiant (GHSA) et un niveau de gravité. Dans le dépôt, plusieurs advisories sur les stream wrappers, FastCGI et les filtres, avec des niveaux de gravité de faible à élevé, sont par exemple parus le 24 septembre 2026. Les paquets source sur php.net sont proposés avec des sommes de contrôle SHA-256 et des signatures GPG des release managers ; les tags Git sont signés. La page sur les [versions de PHP et le cycle de publication](https://phpsos.de/fr/php/release-zyklus/) montre quelles branches de versions reçoivent encore des correctifs de sécurité.

## PHP2Shell comme exemple de cas d'urgence

PHP2Shell montre comment le processus se déroule sous pression :

- **20 octobre 2026 :** php.net annonce une version de sécurité critique pour le 21 octobre 2026 à 14 h 00 UTC et se réserve le droit de publier plus tôt si des détails devenaient publics ou si des attaques apparaissaient. Selon plusieurs rapports, des détails étaient effectivement connus avant l'expiration du délai de blocage ; le contexte est éclairé par [Pourquoi la faille PHP est devenue connue avant le correctif](https://phpsos.de/fr/blog/php-luecke-vorzeitig-bekannt/).
- **21 octobre 2026 :** PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 paraissent, avec les advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) et GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), toutes deux classées comme critiques. Selon php.net, les distributions Linux et les fournisseurs de support à long terme avaient reçu les correctifs à l'avance. Pour 7.4, 8.0 et 8.1, il existe des rétroportages minimaux.
- **23 octobre 2026 :** un avis informatif sur CVE-2026-115560 recommande `session.upload_progress.enabled=0` ; l'advisory complet suivra avec la prochaine version.

## Ce que les exploitants en déduisent

1. **S'abonner aux sources :** php.net, les advisories GitHub de `php/php-src` et les avis de sécurité de votre distribution.
2. **Connaître la chaîne d'approvisionnement :** qui fournit votre paquet PHP, et avec quelle rapidité les rétroportages y arrivent-ils ?
3. **Planifier la fenêtre de temps :** des versions critiques peuvent arriver en dehors du rythme habituel ; une fenêtre de correctifs doit être possible à court terme.
4. **Prévoir le redémarrage :** une mise à jour n'agit que lorsque tous les processus PHP ont été redémarrés.
5. **Conserver la preuve :** documenter la version, le niveau des paquets et l'horodatage.

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

Avec le [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/), nous prenons en charge la part qui vous revient :

- **Suivre les annonces :** nous surveillons php.net, les advisories et les annonces des distributions et évaluons si vos systèmes sont concernés.
- **Appliquer le correctif :** mise à jour depuis la source adéquate, redémarrage de tous les processus, contrôle de la version en cours d'exécution.
- **Sécuriser la transition :** là où la mise à jour est bloquée, nous appliquons les mesures transitoires officielles.
- **Documenter :** vous recevez une preuve avec les versions, les niveaux de paquets et les horodatages.


## Questions fréquentes

**Comment signaler une faille de sécurité dans PHP ?**  
De préférence via le formulaire de signalement privé des Security Advisories du dépôt GitHub php/php-src. Qui ne peut pas l'utiliser écrit à security@php.net. Le signalement reste confidentiel jusqu'à sa publication.

**Le projet PHP verse-t-il une prime pour les failles découvertes ?**  
Non. Selon la politique de sécurité, PHP est un projet de bénévoles sans argent pour des programmes de bug bounty. Les personnes qui signalent sont toutefois citées comme contributeurs.

**Un contournement de disable_functions est-il une faille de sécurité ?**  
Pas selon la politique du projet PHP. Les contournements de open_basedir et de disable_functions ne sont pas considérés comme un problème de sécurité de PHP. Ces réglages relèvent du durcissement, mais ne constituent pas une frontière de sécurité fiable.

**Où apprendre l'existence de nouvelles failles de sécurité PHP ?**  
Sur la page d'accueil de php.net avec les annonces de versions, et dans les Security Advisories du dépôt GitHub php/php-src. Qui obtient PHP via sa distribution suit en plus ses avis de sécurité.

**Pourquoi PHP2Shell a-t-il été publié un mercredi ?**  
Selon le wiki, les versions paraissent le plus souvent le jeudi. Pour PHP2Shell, php.net a annoncé le 20 octobre 2026 une version de sécurité pour le mercredi 21 octobre 2026 à 14 h 00 UTC, en se réservant le droit de publier plus tôt si des détails devenaient publics.

## Sources

- [php-src : politique de sécurité et advisories (GitHub)](https://github.com/php/php-src/security)
- [Wiki PHP : politique de sécurité](https://wiki.php.net/security)
- [php.net : annonces du 20 au 23 octobre 2026](https://www.php.net/)
- [php.net : versions prises en charge](https://www.php.net/supported-versions.php)