Préserver avant de modifier

Notez heure de découverte, domaine, instance, runtime, symptômes et dernier état fiable. Exportez journaux originaux et fuseaux, audits cloud et instantanés autorisés disponibles. Restreignez les copies et calculez leurs empreintes. N’envoyez pas de cookies, jetons ou données clients aux scanners publics. Ne videz pas les journaux et ne supprimez pas les fichiers suspects avant préservation.

Contenir une compromission probable

En cas d’activité suspecte, restreignez l’accès ou retirez les instances du répartiteur en préservant les preuves utiles. Impliquez hébergeur ou équipe d’intervention. Inventoriez tous les PHP, corrigez les deux CVE, remplacez les workers et examinez les voisins. WAF et mesures temporaires n’éliminent pas accès acquis, identifiants volés ni persistance. Ne retardez pas le confinement.

Restaurer un état fiable

Après compromission confirmée, reconstruisez depuis des images fiables et restaurez des données vérifiées ; supprimer un webshell ne suffit pas. Retirez comptes et persistance, changez les secrets touchés depuis un poste sain et invalidez les sessions après confinement. Vérifiez runtime Web, réplicas et fonctions. Surveillez connexions/authentification et traitez les notifications applicables avec l’équipe.

Sources primaires et lectures complémentaires

PHP security teamLire l’original ↗CVE-2026-109618Lire l’original ↗CVE-2026-109619Lire l’original ↗

Analyses et guides pratiques

>_

Outils PHP2Shell

Vérifiez un site public, examinez des paramètres et journaux locaux ou trouvez des outils ouverts. Chaque résultat expose ses preuves et limites.

01

Comprendre PHP2Shell simplement

PHP est le moteur de WordPress, Laravel et des plugins. Mettre à jour un plugin ne met pas PHP à jour. Deux failles mémoire peuvent transformer un nettoyage anormal de requête en divulgation ou exécution de code. Le contrôle public fournit des indices ; l’hébergeur doit confirmer le runtime Web et son correctif.

02

Tentative ou intrusion réussie ?

Une requête multipart étrange ou une alerte WAF peut signaler une tentative. OOM, SIGSEGV/SIGABRT et pics HTTP 500 ont aussi des causes ordinaires. Processus enfants PHP, connexions, fichiers ou comptes inattendus exigent enquête. Une fuite mémoire peut ne laisser ni webshell ni fichier ; un scan propre ne l’exclut pas.

03

Préserver avant de modifier

Notez heure de découverte, domaine, instance, runtime, symptômes et dernier état fiable. Exportez journaux originaux et fuseaux, audits cloud et instantanés autorisés disponibles. Restreignez les copies et calculez leurs empreintes. N’envoyez pas de cookies, jetons ou données clients aux scanners publics. Ne videz pas les journaux et ne supprimez pas les fichiers suspects avant préservation.

04

Lire Wiz et Calif avec précision

Les recherches décrivent des erreurs survivant aux requêtes. L’avis CVE-2026-109618 démontre une RCE mod_php ; l’exposition FPM repose sur le code, sans exploit FPM complet pour ce CVE. CVE-2026-109619 confirme séparément un chemin FPM lié à l’application et au suivi des téléversements. Vérifiez les preuves de chaque SAPI dans son GHSA.

05

Cloudflare : examiner aussi la réponse

Cloudflare décrit une détection combinant requête et réponse d’origine, pouvant bloquer une réponse suspecte avant divulgation. Utile même sans lancement de shell. Le calendrier historique ne garantit pas votre couverture : vérifiez règles, routage, exclusions et événements. Les accès directs à l’origine et hôtes hors proxy doivent aussi être corrigés.