NR26-10 : vulnérabilités du runtime PHP (CVE-2026-109618, CVE-2026-109619)

Vulnerability Identifier: NR26-10

Priority: Critique

Résumé :

Deux vulnérabilités critiques (CVSS 9,2) ont été divulguées dans le runtime PHP. Elles affectent les versions 5.4.0, et ultérieures de PHP qui servent des requests web. Le projet PHP a annoncé la sortie de correctifs le 21 octobre 2026.

Les services de New Relic ne sont pas impactés, et New Relic n’a identifié aucune preuve d’exploitation de ces vulnérabilités dans son environnement. L’agent PHP de New Relic s’exécute dans le propre environnement PHP des clients, et n’est pas lui-même le composant vulnérable.

Les clients qui exécutent des applications PHP, avec, ou sans l’instrumentation New Relic, devraient tout de même évaluer leurs versions de PHP.

Action recommandée :

Aucune action n’est requise en ce qui concerne vos services New Relic. Néanmoins, New Relic encourage vivement les clients qui exécutent PHP à mettre à niveau vers une sortie PHP corrigée (vers PHP 8.5.12, 8.4.27, 8.3.36, ou 8.2.35). Si vous ne pouvez pas mettre à niveau immédiatement, appliquez un ensemble de règles WAF qui couvre ces CVE, et limitez l’exposition à Internet des applications affectées jusqu’à ce que vous le puissiez.

Recommandations :

Packages de distribution :
- Les distributions Linux et les fournisseurs LTS ont reçu les correctifs à l’avance. Vérifiez auprès de votre fournisseur pour obtenir des packages mis à jour.
Versions en fin de vie (PHP 8.1 et antérieures) :
- Certaines distributions et fournisseurs LTS fournissent des correctifs rétroportés, veuillez donc contacter votre fournisseur ou mettre à niveau vers une version prise en charge. En raison de la gravité, l’équipe de sécurité PHP a également publié des rétroportages de sources minimaux pour PHP 7.4, 8.0 et 8.1 pour les organisations qui compilent à partir des sources ou qui n’ont pas de fournisseur LTS.
Utilisateur de rpms.remirepo.net :
- Ce référentiel maintenu par des bénévoles n’aura pas de mises à jour le jour de la sortie. L’équipe PHP exhorte les utilisateurs à passer aux packages de distribution ou à compiler à partir des sources.

Lorsqu’une application immédiate de correctifs n’est pas réalisable, les organisations devraient envisager d’isoler les ressources exposées à Internet des réseaux publics jusqu’à ce que le correctif soit appliqué, et vérifié.

Atténuation temporaire :

Seule une mise à jour corrige entièrement ces vulnérabilités. Les mesures ci-dessous réduisent l’exposition à des chemins d’attaque spécifiques mais ne rendent pas une installation sûre.

CVE-2026-109618 (corruption OOM):

Définissez memory_limit = -1 de manière à ce que les applications ne puissent pas l’écraser, comme php_admin_value dans le pool FPM, ou la configuration Apache. Vérifiez qu’aucun paramètre de pool, de répertoire, ou d’application ne rétablisse une limite finie. Cela supprime l’échec de limite de mémoire contrôlable, mais un échec d’allocation sous-jacent peut toujours atteindre le chemin de code vulnérable.
Définissez un post_max_size faible : 8 Mo pour les applications qui n’ont pas besoin de téléchargements de fichiers, 32 Mo si les téléchargements sont requis. Maintenez upload_max_filesize en dessous de post_max_size.
Envisagez d’appliquer des limites au niveau du serveur web ou du proxy pour la taille des requests décodées, le nombre de champs de saisie, le nombre de parties multipart, le nombre d’en-têtes, et la profondeur d’imbrication. Ces limites doivent également couvrir les requests sans Content-Length utilisable.
Utilisez une limite de mémoire de conteneur ou de cgroup comme frontière de disponibilité, de préférence avec une politique qui ne tue que le worker affecté. N’utilisez pas RLIMIT_AS ou RLIMIT_DATA à la place, car ils peuvent déclencher l’échec d’allocation vulnérable.

CVE-2026-109619 (état global obsolète):

Définissez session.upload_progress.enabled=0 et redémarrez chaque worker. Appliquez ceci dans php.ini, un pool FPM ou une configuration de serveur qui prend effet avant l’analyse de la requête. Ne vous fiez pas à ini_set() ou à FPM .user.ini. Cela bloque les chemins de session confirmés, mais pas les autres variantes.
Sur PHP 8.5, définissez fatal_error_backtraces = 0, et redémarrez chaque worker. Cela bloque uniquement le chemin de backtrace fatal confirmé.
Supprimez les paramètres par requests non valides, ou obsolètes pouvant émettre des diagnostics avant l’initialisation. Masquer les diagnostics avec error_reporting, display_errors, ou @ n’aide pas.
Corrigez les erreurs fatales et les dépassements de délai d’exécution que les attaquants peuvent atteindre, y compris les échecs de rappel, de traitement des téléchargements ou des importations, et de nettoyage.

FAQ :

Comment puis-je savoir quelle version de PHP j’utilise ?
Exécutez php -v sur l’hôte ou dans le conteneur. Pour la version PHP que New Relic voit, vérifiez les détails de l’hôte ou de l’application dans l’UI de New Relic.
L’agent PHP New Relic doit-il être mis à jour ?
Les vulnérabilités se trouvent dans le runtime PHP, et non dans l’agent. La mise à jour de PHP est le correctif requis.
J’utilise une version de PHP en fin de vie. Que dois-je faire ?
PHP 8.1, 8.0, et toutes les branches 7.x et 5.x ne recevront pas de correctifs officiels. Vérifiez si votre distribution Linux (telle qu’Ubuntu ou AlmaLinux) a effectué la sortie d’un correctif rétroporté, et planifiez une mise à niveau vers une branche prise en charge.
Comment puis-je savoir si mes systèmes ont été ciblés ?
Examinez les logs web et WAF à partir du 21 octobre 2026. Les indicateurs signalés publiquement incluent le User-Agent php2shell-verify/1.0 et les requests vers /vuln.php. Recherchez également les processus de serveur web ou PHP générant des commandes shell, et les fichiers PHP nouveaux ou modifiés dans les répertoires web.
Un WAF peut-il me protéger jusqu’à ce que j’applique un correctif ?
Un WAF peut réduire les risques. Cloudflare a publié des règles WAF d’urgence pour ces vulnérabilités, et d’autres fournisseurs peuvent offrir une protection similaire. Un WAF est une atténuation temporaire, et non un substitut à la mise à niveau de PHP.
J’ai des questions ou des préoccupations concernant ces vulnérabilités. Qui dois-je contacter ?
Si vous avez des questions sur ces vulnérabilités en ce qui concerne vos services New Relic, veuillez ouvrir un ticket de support via le support intégré à l’application, ou contacter votre représentant de compte New Relic.

Documents justificatifs :

Informations techniques sur les vulnérabilités :

Pour tout besoin d’assistance lié à cette communication, veuillez ouvrir un cas d’assistance via le support intégré à l’application.

Historique de publication : 23 octobre 2026 - NR26-10 publié