Palo Alto corrige une RCE root dans l’interface de gestion de PAN-OS, déjà ciblée dans la nature
Le 14 octobre 2026, Palo Alto Networks corrige CVE-2026-0322, une injection de code dans l’interface de gestion de PAN-OS qui donne la main root à un attaquant authentifié, et confirme une exploitation déjà observée. Patchez avant le 17 octobre et vérifiez que votre interface de gestion n’est pas exposée à Internet.
14 octobre 2026. Palo Alto Networks publie le correctif de CVE-2026-0322, une exécution de code à distance dans l’interface de gestion de PAN-OS. 14 octobre 2026. La CISA inscrit la faille à son catalogue KEV, avec une échéance de correction fédérale au 17 octobre. Exploitation. Le constructeur confirme qu’une exploitation « très limitée » est déjà observée et publie trois adresses IP comme indicateurs de compromission. Pourquoi c’est important : la faille exige d’être authentifié, ce qui la fait passer pour bénigne — sauf que l’interface de gestion d’un pare-feu est la surface que les équipes exposent le plus souvent sans le savoir, et qu’une fois dedans, l’attaquant est root.
Une RCE « authentifiée » qui mène au root
CVE-2026-0322 est classée CWE-94, injection de code. Un attaquant authentifié disposant d’un accès réseau à l’interface de gestion peut exécuter du code arbitraire avec les privilèges root sur le pare-feu. Le vecteur CVSS 4.0 raconte à lui seul la faille : PR:H (privilèges élevés requis), mais VC:H, VI:H et VA:H — confidentialité, intégrité et disponibilité entièrement compromises sur l’appareil — et E:A, une exploitation déjà attestée. Le score de base est de 8,6 (élevé), et Palo Alto lui affecte l’urgence maximale, « HIGHEST », malgré la barrière d’authentification. Aucune configuration particulière n’est requise pour être vulnérable : une appliance exposée l’est par défaut.
La faille touche les branches PAN-OS 10.2, 11.1, 11.2, 12.1 et 12.2, sur les appliances PA-Series, les VM-Series et Panorama (virtuel et M-Series). Cloud NGFW et Prisma Access ne sont pas concernés. Le périmètre est donc large : c’est toute la gamme de firewalls sur site qui doit passer par un correctif de branche, chaque version ayant son propre numéro de patch — 12.2.4, 12.1.4-h12, 11.2.4-h22, 10.2.7-h38, et ainsi de suite. La branche 11.2 n’obtient sa version finale 11.2.16 que le 15 octobre, jour même de la publication de ce correctif, un décalage classique quand le correctif sort en même temps que l’avis.
La faille a été découverte en interne, par Suraj Siddharudh, et signalée par Palo Alto sans passer par un tiers. C’est un détail qui compte : une découverte interne publiée le même jour que l’inscription KEV signale un cycle de correction comprimé, où le correctif et la chasse se jouent dans la même semaine.
Pourquoi « authentifié » ne rassure pas
Le qualificatif « authentifié » est le piège de cette CVE. Sur le papier, exiger un compte réduit la criticité : la barre d’entrée est plus haute que pour une faille exploitable sans compte. Dans la pratique, l’interface de gestion des pare-feu est exactement la surface que les équipes laissent fuiter, souvent par confort.
Les causes sont connues. Une interface de gestion accessible depuis le MGT port dédié est parfois raccordée au mauvais VLAN, un profil de gestion est activé sur une interface de données pour dépanner puis jamais retiré, ou une règle de pare-feu autorise un sous-réseau entier au lieu d’une station d’administration. Chaque incident de ce type — et Palo Alto en a vu plusieurs ces dernières années sur cette même surface — commence par « on pensait que c’était fermé ».
Le second facteur, c’est l’exposition des identifiants eux-mêmes. Une RCE « authentifiée » part du principe que l’attaquant possède déjà un compte valide sur l’interface de gestion. Or les comptes d’administration de pare-feu sont notoirement réutilisés, stockés dans des gestionnaires de mots de passe partagés, ou laissés sur des postes de travail compromis. La compromission d’un poste d’administrateur réseau transforme immédiatement cette faille « à privilèges élevés » en root sur l’appareil qui protège tout le reste.
Palo Alto ne s’y trompe pas : l’avis précise que le risque est « le plus élevé lorsque vous autorisez l’accès à l’interface de gestion depuis des adresses IP externes sur Internet », et recommande de la limiter à une jump box unique. La conséquence est directe : pour la plupart des organisations, le correctif logiciel ne suffit pas. La vraie mesure, c’est de vérifier l’exposition réelle de l’interface de gestion, pas seulement d’appliquer un patch.
Ce que corrige Palo Alto, et ce qui manque
Il n’existe aucune solution de contournement : ni règle, ni désactivation partielle. La seule remédiation est la montée de version vers une branche corrigée. Palo Alto propose une couverture partielle via Threat Prevention, avec les signatures 510046 et 510047 (contenu 9159-10287 et suivants), mais à une condition lourde : ces signatures exigent le déchiffrement SSL du trafic vers l’interface de gestion, et le routage du trafic du MGT port à travers un port de données pour que le moteur puisse l’inspecter. C’est une couverture « limitée » — l’avis le dit explicitement, des variantes d’attaque peuvent passer entre les mailles — donc un palliatif, pas une alternative au patch.
Sur l’exploitation, Palo Alto reste précis sans dramatiser : une exploitation « très limitée » a été observée, ciblant l’interface de gestion, et trois adresses IP sont associées aux tentatives — 66.42.72.14, 208.83.239.114 et 149.248.47.234. Publier des indicateurs aussi tôt, dans le même avis que le correctif, est inhabituel et doit être lu comme un signal : les équipes ont intérêt à chercher ces adresses dans leurs journaux d’accès à l’interface de gestion sans attendre.
L’inscription au catalogue KEV de la CISA, le jour même, est le second signal. Ce catalogue ne liste que les vulnérabilités exploitées de façon avérée, et il est adossé à une directive contraignante pour les agences fédérales américaines : l’échéance du 17 octobre donne trois jours pleins. Pour le secteur privé, c’est le même calendrier qui devrait s’appliquer — une faille sur un pare-feu en exploitation active ne se traite pas à la prochaine fenêtre de maintenance.
Comment vérifier l’exposition avant même de patcher
Le correctif prend du temps à déployer sur un grand parc ; la vérification d’exposition, elle, se fait en minutes. Trois contrôles suffisent à écarter le pire des scénarios.
D’abord, identifiez qui peut joindre l’interface de gestion. Sur chaque appliance, relevez les adresses et sous-réseaux autorisés à atteindre le port de gestion, puis comparez-les à la liste des postes d’administration légitimes. Tout ce qui dépasse une jump box unique est un excès à corriger immédiatement, indépendamment du patch.
Ensuite, cherchez les trois adresses IP publiées dans les journaux d’accès et d’authentification. Une occurrence de 66.42.72.14, 208.83.239.114 ou 149.248.47.234 ne prouve pas la compromission, mais elle la rend plausible, et justifie une investigation forensique de l’appliance plutôt qu’un simple redémarrage.
Enfin, si l’interface est joignable depuis Internet, changez l’hypothèse de travail : considérez l’appliance comme potentiellement compromise jusqu’à preuve du contraire. Une RCE root ne laisse pas forcément de trace dans les journaux de l’appareil lui-même — un attaquant qui est déjà root peut les altérer. La vérification se fait alors hors de l’appliance, sur les flux réseau et les collecteurs centralisés.
Verdict
Traitez cette CVE comme une urgence de trois jours, pas comme une faille « authentifiée » de second rang. Si vous exploitez des firewalls PAN-OS sur site, appliquez le correctif de votre branche avant le 17 octobre, l’échéance KEV de la CISA, en priorité sur les appliances dont l’interface de gestion est joignable depuis un réseau autre que le VLAN d’administration. Dans le même temps, vérifiez l’exposition réelle : listez les adresses autorisées à joindre le port de gestion, fermez tout ce qui dépasse la jump box, et traquez les trois adresses IP publiées dans vos journaux. Si votre interface de gestion est exposée à Internet, considérez l’appliance comme potentiellement compromise jusqu’à preuve du contraire — une RCE root ne laisse pas forcément de trace dans les journaux de l’appliance elle-même. Le correctif protège l’avenir ; c’est la vérification de l’exposition qui protège le présent.