Faille PAN-OS : comprendre l’attaque PHP2Shell
Une chaîne PHP2Shell et une faille du noyau ont compromis 25 serveurs PAN-OS. Comprenez le mode opératoire et les priorités de défense.
PAN-OS : comment une faille de pare-feu a ouvert la voie à Active Directory
Un pare-feu exposé sur Internet est censé filtrer les accès. Mais quand son interface d'administration est, elle aussi, joignable depuis le réseau public, elle peut devenir un point d'entrée vers des systèmes bien plus sensibles. Fin octobre 2026, une opération attribuée à cette logique illustre le danger : des chercheurs ont décrit une chaîne d'exploitation qui aurait permis de prendre le contrôle de 25 serveurs utilisant PAN-OS, le système de pare-feu de Palo Alto Networks.
Parmi ces appareils, deux semblent liés à un environnement associé au gouvernement américain. D'après les éléments rapportés, l'attaquant aurait compromis un pare-feu, créé un tunnel vers le réseau interne, pris le contrôle d'un serveur de gestion, puis lancé des actions contre Active Directory. Le détail de certaines tentatives reste toutefois flou.
Au fond, l'incident ne tient pas uniquement à une vulnérabilité logicielle. Il montre comment une interface de périmètre exposée peut connecter, en quelques étapes, des comptes, des services et des systèmes d'identité. Voici ce que l'enquête permet d'établir, ce qu'elle ne permet pas de conclure, et ce que les équipes de sécurité peuvent faire concrètement.
Ce que révèle la compromission des pare-feu PAN-OS
Une campagne préparée, pas juste une tentative opportuniste
Les éléments publiés par l'équipe de recherche Dream décrivent une chaîne qui combine deux failles : PHP2Shell, référencée CVE-2026-109618 et CVE-2026-109619, puis une élévation de privilèges du noyau Linux, appelée Fragnesia et référencée CVE-2026-46300. La cible : certaines versions de PAN-OS et le serveur web d'administration, qui sert aussi de portail pour GlobalProtect.
Les chercheurs disent avoir retrouvé des profils associés à différentes versions, des journaux d'exploitation, des listes de cibles et une quarantaine de scripts de post-exploitation. Le fait d'observer des profils « calibrés » et d'autres plus approximatifs, dérivés des binaires, laisse penser à un travail en plusieurs niveaux : tout n'était pas forcément testé de la même façon dans la pratique.
Côté Palo Alto Networks, l'équipe Unit 42 affirme avoir vérifié indépendamment les outils et les résultats publiés. Le fournisseur annonce aussi la mise à disposition de versions corrigées pour les branches concernées. Pour une organisation, la première étape reste simple : comparer ses versions installées aux avis de sécurité officiels. L'enquête, même détaillée, ne remplace pas ce travail pour déterminer quel correctif s'applique à chaque appareil.
Des chiffres à lire avec prudence
Les chercheurs décrivent une sélection progressive : environ 19 000 appareils repérés, près de 5 000 identifiés via un sondage de version, puis 240 retenus selon leur localisation et leur compatibilité avec les profils d'exploitation. Ils indiquent ensuite 24 pare-feu compromis pendant la phase automatisée, puis un serveur de gestion compromis après un pivot, soit 25 serveurs au total.
Mais ce décompte ne veut pas dire que tout le monde a subi la même chose, ni que l'activité était identique pour chaque système « retenu ». Pour 22 pare-feu compromis, l'activité observée se serait limitée à l'installation d'un webshell. Et deux appareils associés à la même organisation auraient servi de point de départ à des actions plus poussées.
Autre détail intéressant : les chercheurs disent avoir observé des outils d'intelligence artificielle et des modèles linguistiques chinois dans l'infrastructure de l'attaquant. Ils ne concluent toutefois pas que ces outils aient servi à produire l'exploit ou les scripts. Les indices linguistiques, horaires et techniques orientent plutôt vers un environnement chinois, sans que cela permette d'attribuer l'opération à un acteur précis ni d'affirmer une implication étatique.
Comment la chaîne PHP2Shell a-t-elle obtenu un accès root ?
Première étape : exécuter des commandes à distance
La faille PHP2Shell viserait le mécanisme de suivi de progression des téléversements de session PHP, sur le serveur web d'administration de PAN-OS. D'après l'analyse publiée, l'attaquant aurait développé une implémentation propre, non publique, adaptée aux versions ciblées. Pas besoin d'identifiants : l'exploitation pouvait être déclenchée via une requête HTTPS vers l'interface exposée.
Concrètement, cette première étape manipulerait la mémoire du processus PHP. Des requêtes spécialement construites mettraient le processus sous forte pression mémoire, puis exploiteraient un état de session incohérent pour obtenir des informations sur l'état de la mémoire. Ces informations serviraient ensuite à préparer une corruption ciblée et à faire exécuter une commande par le processus web.
Attention au vocabulaire : cette première exécution ne donnerait pas directement les droits administrateur. Elle se fait, d'après le rapport, sous le compte système du serveur web, décrit comme l'utilisateur « nobody ». C'est un point important : c'est déjà une gravité très élevée (exécution de code à distance), mais ça ne veut pas dire que l'attaquant contrôle tout le système. Ici, des mécanismes de confinement - notamment SELinux - limiteraient les actions possibles avec ce compte.
Deuxième étape : passer de l'utilisateur web à root
Pour dépasser ce confinement, les chercheurs indiquent que la chaîne enchaînerait PHP2Shell avec Fragnesia, une vulnérabilité du noyau Linux dans le sous-système XFRM ESP-in-TCP. Selon leur analyse, cette seconde faille permettrait de modifier un fichier de configuration PAM associé à la commande su, puis d'obtenir un accès root sans mot de passe.
L'objectif défensif n'est pas de reproduire la manœuvre, mais de comprendre ce que change une chaîne de vulnérabilités. Un contrôle d'accès qui limite un processus web peut être contourné si une faille du noyau permet de sortir du confinement. La question ne se résume donc pas à « le serveur web peut-il écrire dans des fichiers système ? ». Il faut aussi se demander si une seconde faiblesse ouvre la voie à une escalade.
Les chercheurs précisent aussi que les deux vulnérabilités seraient chaînées dans une même requête d'exploitation. Le passage d'une connexion HTTPS non authentifiée à un webshell persistant aurait pu prendre moins de quinze minutes. Ce délai correspond à ce cas précis, pas à une règle générale. Mais il souligne un point : avec une interface exposée, compter sur une surveillance manuelle peu fréquente ne suffit pas toujours à arrêter l'enchaînement.
Pourquoi le versionnement complique - sans empêcher - l'exploitation
La chaîne dépendrait de paramètres propres aux versions de PAN-OS : bibliothèques, structures mémoire, adresses internes. Les artefacts incluent onze profils JSON, avec notamment des informations de version et des paramètres mémoire. Certains profils auraient été testés sur une machine virtuelle ; d'autres seraient provisoires, dérivés des binaires.
Résultat : un appareil vulnérable n'est pas forcément exploité à chaque tentative, car la compatibilité dépend du build, de la configuration et de la précision des profils. Cela dit, ce n'est pas une « protection » fiable. Les profils peuvent être améliorés, et les chercheurs rapportent que plusieurs versions étaient visées.
Comment l'attaque est-elle passée du pare-feu au réseau interne ?
Du scan public à la sélection des cibles
Les artefacts décrivent une campagne en plusieurs étapes. D'abord, un service de recherche d'actifs Internet repère des pare-feu accessibles. Ensuite, un scanner vérifie leur disponibilité et leur version. Les opérateurs filtrent ensuite pour retenir des appareils situés aux États-Unis, au Japon, à Taïwan et en Corée du Sud, puis compatibles avec les profils disponibles.
Sur les 240 cibles retenues, un outil automatisé tenterait l'exploitation par groupes de cinq appareils. Quand la compromission réussit, l'opération installe un webshell sur le serveur, vérifie l'accès root et consigne le résultat. Cette automatisation explique qu'on puisse traiter beaucoup de systèmes sans que chaque machine devienne immédiatement le point de départ d'une post-exploitation plus large.
La plupart des appareils compromis resteraient en attente : les chercheurs n'y observent ni tunnel ni outils supplémentaires. Autrement dit, ces machines servent de « réserve opérationnelle ». Un webshell persistant donne un accès de retour, même si aucune activité visible ne suit tout de suite.
Le pivot vers les systèmes d'identité
Le changement d'échelle arriverait après qu'un pare-feu ait révélé des informations sur l'organisation à laquelle il appartenait. Sa configuration expose une topologie interne : contrôleurs de domaine, serveur central de gestion des pare-feu, fournisseur d'identité Keycloak et services VPN. Les chercheurs y voient des indices d'un environnement lié au gouvernement, sans pouvoir qualifier précisément l'entité concernée.
Après le dysfonctionnement d'un premier appareil, l'attaquant aurait compromis un second pare-feu de la même organisation. Ensuite, il met en place un tunnel SSH inversé, configuré pour redémarrer après reboot, avec des accès vers plusieurs services internes. Le tunnel permet d'atteindre le serveur de gestion et les contrôleurs de domaine depuis l'infrastructure de l'attaquant.
Moins de 90 minutes après la compromission du second pare-feu, le serveur central de gestion aurait été exploité à son tour via la même chaîne. Là, le contexte est plus délicat : cette machine gère les équipements et dispose de la connectivité LDAP nécessaire à l'authentification des utilisateurs VPN. En clair : compromettre un plan de gestion peut concentrer des risques qui dépassent largement le pare-feu initial.
Ce qui est confirmé et ce qui reste inconnu
Sur le serveur de gestion, les chercheurs disent avoir observé le déchiffrement du mot de passe d'un compte de service LDAP, puis l'énumération des utilisateurs et des groupes Active Directory. Ils décrivent aussi des scripts visant à tenter une pulvérisation de mots de passe, la création de comptes persistants, l'analyse d'options d'élévation via les permissions AD, et l'extraction de clés SAML.
Mais ils notent aussi que certaines tentatives ne se retrouvent pas dans les artefacts récupérés. On ne peut donc pas affirmer que des comptes ont été créés, que des identifiants valides ont été trouvés, ni que des clés SAML ont été extraites. Cette incertitude ne sert pas à minimiser l'incident : elle signifie plutôt qu'il faut traiter les données et identifiants accessibles comme potentiellement exposés, jusqu'à ce que l'enquête réduise clairement le périmètre.
Par ailleurs, les éléments confirmés incluent des clés privées présentes sur les pare-feu, une cartographie réseau détaillée, des listes d'utilisateurs et de groupes, ainsi que des webshells sur plusieurs appareils. Le rapport indique enfin que certains accès pouvaient encore être actifs au moment de sa publication. Pour une organisation concernée, le bon réflexe est donc de raisonner en termes de compromission, pas seulement en « mise à jour à appliquer ».
Que doivent faire les équipes de sécurité ?
1. Établir l'exposition et appliquer les correctifs
Commencez par dresser l'inventaire de tous les appareils PAN-OS, y compris ceux qu'on ne voit pas dans l'inventaire « courant » : environnements de secours, équipements de laboratoire, systèmes gérés par un prestataire, ou interfaces de gestion exposées par erreur. Pour chaque équipement, notez : version exacte, exposition Internet, interfaces activées et règles d'accès.
Ensuite, faites la correspondance avec les avis de sécurité du fournisseur et appliquez les versions correctives recommandées pour la branche concernée. Si vous ne pouvez pas corriger tout de suite, réduisez l'exposition : coupez l'accès direct depuis Internet, limitez l'administration à un réseau de gestion contrôlé et imposez des restrictions adaptées. Une mise à jour n'annule pas automatiquement une compromission déjà en cours.
2. Rechercher les traces d'accès et de persistance
Côté journaux, regardez ce que vous avez côté équipements, réseau, supervision et détection. Cherchez en priorité : connexions inhabituelles vers les interfaces d'administration, requêtes anormales au serveur web, processus ou fichiers inattendus, modifications de services au démarrage, et connexions sortantes persistantes.
Pensez aussi « au-delà du premier appareil ». L'analyse doit inclure les équipements de gestion et les systèmes accessibles depuis les pare-feu compromis. Une enquête limitée à l'équipement exposé risque de rater le tunnel et les mouvements latéraux.
Enfin, préservez les journaux et les images utiles avant toute action susceptible de les écraser. Si vous confirmez un webshell ou une activité suspecte, isolez l'équipement selon vos procédures d'intervention.
3. Révoquer les secrets et contrôler Active Directory
Faites l'inventaire des secrets qui pouvaient être lus depuis les appareils concernés : comptes LDAP, clés privées, certificats, identifiants d'administration, secrets SAML, clés de réplication ou d'authentification. Révoquez ou remplacez ce qui a pu être exposé, puis vérifiez les usages récents.
Changer le mot de passe d'un compte ne suffit pas si une clé ou un jeton continue de permettre une authentification alternative.
Côté Active Directory, cherchez : nouveaux comptes utilisateurs ou machines, changements de groupes, connexions inhabituelles, tentatives répétées d'authentification, et modifications de permissions. Vérifiez aussi les mécanismes de verrouillage et les chemins entre comptes de service et ressources sensibles.
Gardez en tête : vos contrôles doivent s'appuyer sur ce que les journaux montrent. L'absence d'alerte n'est pas une preuve d'absence d'activité.
4. Réduire le risque structurel
En règle générale, l'interface de gestion d'un pare-feu ne devrait pas être directement accessible depuis Internet. L'accès via un réseau d'administration dédié, un VPN contrôlé ou un bastion réduit la surface d'exposition - à condition que ces points d'accès soient eux-mêmes surveillés et maintenus. Séparez au maximum les plans d'administration et les réseaux utilisateurs.
Enfin, testez votre chaîne de réponse : qui détecte qu'un pare-feu est exposé, qui peut le retirer du réseau, qui révoque les secrets, et qui décide d'isoler le serveur de gestion.
Pour les organisations françaises et européennes, pensez aussi à la préparation aux obligations internes de notification et d'escalade, surtout si des données personnelles ou des services essentiels sont potentiellement en jeu. L'idée n'est pas de présumer une violation de données, mais d'être capable de qualifier rapidement les faits.
À retenir : corriger une porte connue, c'est bien. Enquêter, c'est indispensable pour savoir si quelqu'un est déjà entré. Après une exploitation potentielle, les deux actions vont ensemble.
Conclusion : traiter l'exposition comme un incident potentiel
Cette opération montre comment une interface d'administration exposée peut devenir le premier maillon d'une compromission plus large. Une exécution de code sur un pare-feu s'accompagne d'une élévation de privilèges, puis d'un tunnel vers le réseau interne, jusqu'à des actions visant Active Directory. En clair : le risque ne se limite pas au nombre d'équipements vulnérables. Il dépend aussi de ce que ces équipements contiennent - accès, secrets et capacités de pivot.
Pour les équipes de sécurité, l'ordre de priorité est assez simple : identifier les appareils concernés, appliquer les correctifs, supprimer l'exposition directe des interfaces d'administration, puis rechercher les signes de persistance. Si une compromission est plausible, l'analyse doit s'étendre aux systèmes internes et aux identifiants accessibles.
La règle opérationnelle est directe : après une exploitation potentielle, ne vous arrêtez pas à « on a mis à jour ». Vérifiez ce qui a été fait, révoquez ce qui a pu être exposé et réduisez la possibilité qu'un équipement périphérique serve de rampe d'accès vers l'infrastructure d'identité.