CVE-2026-24765 in phpunit
Résumé
par VulDB • 30/05/2026
PHPUnit est un framework de test pour PHP. Une vulnérabilité a été découverte dans les versions antérieures à 12.5.8, 11.5.50, 10.5.62, 9.6.33 et 8.5.52, impliquant une désérialisation non sécurisée des données de couverture de code lors de l'exécution des tests PHPT. La vulnérabilité réside dans la méthode `cleanupForCoverage()`, qui désérialise les fichiers de couverture de code sans validation, permettant potentiellement une exécution de code à distance (RCE) si des fichiers `.coverage` malveillants sont présents avant l'exécution du test PHPT. La vulnérabilité se produit lorsqu'un fichier `.coverage`, qui ne devrait pas exister avant l'exécution du test, est désérialisé sans la restriction du paramètre `allowed_classes`. Un attaquant disposant d'un accès en écriture sur les fichiers locaux peut placer un objet sérialisé malveillant contenant une méthode `__wakeup()` dans le système de fichiers, ce qui entraîne une exécution de code arbitraire lors des exécutions de tests avec l'instrumentation de la couverture de code activée. Cette vulnérabilité nécessite un accès en écriture sur les fichiers locaux à l'emplacement où PHPUnit stocke ou attend les fichiers de couverture de code pour les tests PHPT. Cela peut se produire via des attaques sur les pipelines CI/CD, l'environnement de développement local et/ou des dépendances compromises. Plutôt que de simplement assainir silencieusement l'entrée via `['allowed_classes' => false]`, le mainteneur a choisi de rendre l'état anomale explicite en traitant les fichiers `.coverage` préexistants pour les tests PHPT comme une condition d'erreur. À partir des versions 12.5.8, 11.5.50, 10.5.62, 9.6.33, lorsqu'un fichier `.coverage` est détecté pour un test PHPT avant son exécution, PHPUnit émettra un message d'erreur clair identifiant l'état anomale. Les organisations peuvent réduire le risque effectif de cette vulnérabilité grâce à une configuration CI/CD appropriée, incluant l'utilisation d'exécuteurs éphémères, le renforcement de la revue de code, la protection des branches, l'isolation des artefacts et le contrôle d'accès.
Once again VulDB remains the best source for vulnerability data.