écran d'ordinateur portable affichant un code coloré

Correctif PHP CVE 2026 109618 pour Forge Ubuntu (PHP2Shell)


Avertissement : utilisez-le à vos propres risques. Cet article décrit la procédure qui a fonctionné sur nos serveurs Ubuntu gérés avec Laravel Forge. Votre configuration peut différer. Chaque commande ci-dessous modifie des paquets sur un serveur de production ; il est donc impératif de créer un instantané ou une sauvegarde au préalable, de tester la procédure sur un serveur de préproduction si possible, et de lire attentivement chaque commande avant de l'exécuter. Nous n'offrons aucune garantie et déclinons toute responsabilité en cas de dommages, d'indisponibilité du service ou de perte de données.

Dernière mise à jour : 22 octobre 2026.

Ce qui s'est passé

Le 21 octobre 2026, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ces versions corrigent deux vulnérabilités critiques qui peuvent permettre exécution de code à distance non authentifiée. L'équipe de sécurité PHP a attribué la note de 9,2 à ces deux correctifs sur l'échelle CVSS v4.0. Des informations ont fuité la veille de la publication ; appliquez donc le correctif dès que possible.

  • CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), RCE via corruption OOM : la gestion de la mémoire insuffisante peut interrompre PHP alors que les données de la requête ne sont que partiellement initialisées.
  • CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), RCE via un état global obsolète : l'état d'une requête peut survivre après que sa mémoire soit libérée, et une requête ultérieure sur le même worker peut l'utiliser.

Toute installation PHP traitant des requêtes web est vulnérable : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. PHP considère mod_php comme présentant le risque le plus élevé. PHP 8.1 et les versions antérieures ne bénéficient d'aucun correctif officiel de la part du projet PHP.

🤓😎 De plus en plus de personnes reçoivent nos conseils en geekerie, confidentialité, développement et style de vie

Vous souhaitez recevoir les derniers articles de blog sur la technologie, la confidentialité, le développement et le style de vie ? Abonnez-vous à notre newsletter.

Premièrement : les lignes “ Ign ” ne sont pas votre problème.

Sur les serveurs Forge, mise à jour apt peut imprimer des lignes comme celles-ci :

Ign:18 https://ppa.launchpadcontent.net/laravelphp/forge/ubuntu noble InRelease Hit:19 https://ppa.launchpadcontent.net/ondrej/php/ubuntu noble InRelease

Ign Cela signifie qu'apt n'a pas pu récupérer l'index du PPA Laravel Forge et l'a ignoré. Il s'agit d'un avertissement, et non d'une erreur, qui disparaît généralement lorsque Launchpad est moins sollicité. Plus important encore, PHP lui-même ne provient pas de ce PPA. Le PPA Forge ne contient que quelques extensions (php-imagick, php-memcached, php-msgpack). PHP provient du dépôt d'Ondřej Surý (ondrej/php), c'est donc celui-là qu'il faut examiner.

Étape 1 : Déterminez ce que vous courez

lsb_release -cs # jammy = Ubuntu 22.04, noble = Ubuntu 24.04 ls /etc/php # quelles versions de PHP sont installées sudo apt update apt-cache policy php8.3-fpm php8.4-fpm | grep -E '^php|Installed|Candidate''

Ajoutez chaque version de PHP dont vous disposez à la dernière commande. Votre système est à jour lorsque la version installée est : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou plus récent). Si Installé et Candidat Les deux indiquent une version antérieure ; votre dépôt ne propose pas encore le correctif. Dans ce cas, veuillez consulter l’étape 2, puis l’étape 3B.

Étape 2 : Ajoutez les solutions de repli pendant que vous attendez

Ces paramètres réduisent l'exposition à certains vecteurs d'attaque. Ils le font. pas Sécurisez un serveur ; seule la mise à jour le permet. Placez-les dans un fichier de remplacement au lieu de les modifier. php.ini, car Forge peut réécrire php.ini:

for v in 8.3 8.4; do printf 'session.upload_progress.enabled = 0\nsession.use_strict_mode = 1\n' \ | sudo tee /etc/php/$v/fpm/conf.d/99-php2shell-mitigation.ini sudo systemctl restart php$v-fpm done # Vérification (devrait afficher 0 et 1) : php-fpm8.3 -i | grep -E 'upload_progress.enabled|use_strict_mode''

Changement 8.3 8.4 aux versions présentes sur votre serveur. Vous pouvez conserver ce fichier après l'application du correctif : PHP recommande le mode de session strict pour tous les sites, et peu d'applications utilisent la fonctionnalité de suivi de la progression des chargements.

Étape 3A : Mise à niveau à partir du PPA ondrej (s’il contient le correctif)

Le jour de la sortie, le PPA Launchpad d'Ondřej était en retard. Il a depuis publié les versions corrigées pour Ubuntu 22.04 et 24.04. politique de cache apt affiche la version corrigée comme candidate, mettez à jour uniquement les paquets PHP :

sudo apt-get install -s --only-upgrade 'php*' | grep -E '^Inst' # Exécution à blanc d'abord sudo apt-get install --only-upgrade 'php*''

Conservez les citations autour ''php*'', Ainsi, votre shell ne développera pas l'astérisque. Passez ensuite à l'étape 4.

Étape 3B : Passez à packages.sury.org (si le PPA est toujours en retard)

Ondřej publie également ses colis sur packages.sury.org, Ce dépôt contenait en premier les versions corrigées. Le PPA Launchpad est de toute façon en cours d'intégration, donc changer maintenant ne constitue pas un détour. pas Activer les deux en même temps : deux sources pour les mêmes paquets donnent des candidats à la mise à niveau confus.

1. Déplacez le PPA ondrej pour le mettre de côté (le déplacer au lieu de le supprimer vous permet de revenir en arrière). Laissez le laravelphp/forge PPA seul.

grep -rl 'ondrej/php' /etc/apt/sources.list.d/ # Déplacez le ou les fichiers listés, par exemple : sudo mv /etc/apt/sources.list.d/ondrej-ubuntu-php-noble.sources /root/

2. Ajoutez packages.sury.org. $(lsb_release -cs) Cette partie se remplit avec votre propre version d'Ubuntu. Ne pas saisir noble ou confiture manuellement; voir l'erreur ci-dessous.

sudo curl -fsSLo /usr/share/keyrings/deb.sury.org-php.gpg https://packages.sury.org/php/apt.gpg printf 'Types: deb\nURIs: https://packages.sury.org/php/\nSuites: %s\nComponents: main\nSigned-By: /usr/share/keyrings/deb.sury.org-php.gpg\n' "$(lsb_release -cs)" \ | sudo tee /etc/apt/sources.list.d/php.sources sudo apt update apt-cache policy php8.3-fpm php8.4-fpm | grep -E '^php|Installed|Candidate''

Le candidat devrait maintenant être une version fixe telle que 8.3.36-1+0~20261021… venant de packages.sury.org/php. Si c'est le cas, effectuez un essai à blanc et passez à la version supérieure à partir de l'étape 3A.

L'erreur “ dépendances non satisfaites ” (libc6, libssl3t64, libicu74)

Si la mise à niveau échoue avec un message d'erreur similaire à celui-ci :

php8.3-cli : Dépend de : libc6 (>= 2.38) mais 2.35-0ubuntu3.15 doit être installé Dépend de : libssl3t64 (>= 3.0.0) mais il n'est pas installable E : Impossible de corriger les problèmes, vous avez des paquets cassés.

Le dépôt pointe alors vers une version d'Ubuntu incorrecte. libc6 2.35 Cela signifie que le serveur exécute Ubuntu 22.04 (Jammy), mais apt propose des versions pour 24.04 (Noble). Rien n'a été installé ; apt s'est arrêté avant toute modification. Corrigez la suite et réessayez.

sudo sed -i "s/^Suites: .*/Suites: $(lsb_release -cs)/" /etc/apt/sources.list.d/php.sources sudo apt update

Étape 4 : Redémarrez tout et vérifiez

Un processus en cours d'exécution conserve l'ancienne version de PHP en mémoire jusqu'à son redémarrage. La simple mise à jour du paquet ne suffit pas.

sudo systemctl restart php8.3-fpm php8.4-fpm php artisan queue:restart # sur chaque site Laravel ; redémarrez également les daemons Horizon / Octane / Supervisor # Apache avec mod_php nécessite un redémarrage complet (un rechargement ne suffit pas) : # sudo systemctl restart apache2 # Vérifiez les versions installées : dpkg -l 'php8.[34]-fpm' | awk '/^ii/{print $2, $3}' # Listez les processus exécutant encore l'ancienne version de PHP (une sortie vide = tout est normal) : sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps

Le dépôt packages.sury.org est-il sûr ?

Il est aussi fiable que le PPA Launchpad, car il est géré par le même responsable et propose les mêmes paquets. Ondřej Surý est un développeur Debian et assure la maintenance de PHP sur Debian. Si votre serveur utilisait déjà ce PPA, il est recommandé de l'utiliser. ppa:ondrej/php (Chaque serveur Forge le fait), vous lui faites déjà confiance. Les paquets sont signés, et le Signé par Cette ligne limite sa clé à ce seul dépôt.

Attention : il s’agit d’un dépôt tiers géré par des bénévoles, non pris en charge par Canonical. De plus, la clé est téléchargée depuis le même domaine que les paquets. Pour vérifier, comparez le résultat de gpg --show-keys /usr/share/keyrings/deb.sury.org-php.gpg avec l'empreinte digitale publiée par Ondřej. Pour un serveur non patché présentant une faille d'exécution de code à distance divulguée, le risque est bien plus grand de ne rien faire.

Remarques à l'attention des utilisateurs de Laravel Forge

  • Si vous installez ultérieurement une nouvelle version de PHP via le panneau Forge, Forge peut ajouter ppa:ondrej/php à nouveau. Vérifiez auprès de grep -rl ondrej /etc/apt/sources.list.d/ et déplacez-le si vous êtes passé à packages.sury.org.
  • Les serveurs Forge exécutent souvent plusieurs versions de PHP. Appliquez les correctifs et redémarrez-les toutes, et pas seulement la version par défaut en ligne de commande.
  • Utilisez des fichiers de dépôt dans conf.d pour vos propres paramètres, afin qu'ils survivent à la réécriture de Forge php.ini.

Sources

Encore une fois : à utiliser à vos propres risques. Ce compte-rendu décrit notre expérience et ne constitue pas un avis professionnel. Consultez les recommandations officielles de PHP et vos sources de paquets, effectuez une sauvegarde au préalable et testez avant de modifier vos serveurs de production.

Dernière mise à jour : 22 octobre 2026

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

fr_FRFrançais
Défiler vers le haut