PHP2Shell : corriger l’application ne remplace pas le correctif du runtime

Une pull request peut corriger un défaut applicatif tout en laissant une vulnérabilité du runtime ouverte. Les responsables, artefacts et preuves diffèrent. Les avis PHP d’octobre illustrent cette distinction.

Les versions du 21 octobre 8.2.35, 8.3.36, 8.4.27 et 8.5.12 corrigent CVE-2026-109618 et CVE-2026-109619. Annonce PHP.

L’avis sur l’épuisement mémoire décrit un chemin Apache mod_php antérieur au code applicatif. Modifier un middleware ne protège pas un chemin exécuté avant lui. Avis OOM.

Le second décrit un état lié à une requête qui subsiste dans un worker persistant et peut affecter une requête ultérieure. Avis sur l’état global.

Ce sont des résultats du projet, non des vulnérabilités reproduites indépendamment par Plexicus. Nous proposons un processus de preuves sans affirmer que votre environnement est affecté.

Séparer les critères de clôture

Imaginons qu’une équipe de paiement renforce la validation des fichiers envoyés. La modification est examinée, les tests réussissent et le code est déployé. Cela démontre un comportement du gestionnaire. Cela n’identifie pas le paquet PHP traitant les requêtes et ne prouve pas le remplacement des anciens workers.

Créez des tâches distinctes si nécessaire. La tâche applicative précise comportement et test de régression. Celle du runtime précise avis, paquet, service et preuves du déploiement. Reliez-les pour qu’une tâche de code terminée ne clôture pas une mise à jour inachevée.

Identifier l’environnement qui traite les requêtes

Commencez par le service web. Relevez modèle d’intégration PHP, fournisseur, architecture, sources de configuration et responsable. La CLI peut donner un indice ; le service web peut employer un autre binaire ou une autre configuration.

Pour une distribution maintenue par un fournisseur, confirmez le statut auprès de celui-ci. La comparaison de version upstream seule ne suffit pas. Ne publiez pas une page de diagnostic exposant l’environnement pour recueillir ces preuves.

Délimiter les mesures temporaires

L’avis du 23 octobre recommande, pour une configuration précise, de désactiver le suivi de progression des envois de session jusqu’à la prochaine version régulière de corrections. Avis informatif.

Consultez les instructions actuelles avant d’appliquer ou retirer des réglages temporaires. Consignez valeur, périmètre, responsable et condition de retrait. Une mesure visant un chemin ne démontre pas que tous les avis sont traités. Nous ne prétendons pas que les versions d’octobre corrigent les vulnérabilités ultérieures.

Vérifier le service après modification

Installer un paquet est une étape intermédiaire. Confirmez le paquet utilisé et terminez le remplacement des workers nécessaire. Incluez instances secondaires, maintenance et images de retour arrière. Un rollback peut réintroduire l’ancien paquet.

Effectuez des régressions autorisées avec des données ordinaires : paiement, authentification, envois et sessions selon le contexte. Leur réussite démontre le fonctionnement de ces parcours, pas l’absence indépendante d’un exploit mémoire. Gardez cette distinction dans la clôture.

La place de Plexicus

Plexicus Deep Code Analysis présente le contexte des flux de code et des impacts. Remediation présente des modifications proposées avec leur contexte pour examen par l’équipe. Ces capacités peuvent organiser les défauts applicatifs associés à la réponse runtime. Elles ne garantissent ni mise à jour automatique de PHP ni découverte de chaque worker.

Examinez les preuves opérationnelles avec les résultats de code. Distinguez proposé, fusionné, déployé et vérifié. Le transfert doit expliquer ce que chaque action corrige, ce que les preuves démontrent et qui conserve une tâche.

Relier un résultat à une modification examinée ? Découvrez Plexicus Remediation ou demandez Deep Code Analysis. Partez d’un parcours applicatif et de sa frontière avec le runtime pour définir des critères d’acceptation clairs.