Comment auditer vos firewalls Palo Alto contre CVE-2026-0300 en 7 etapes

Le 6 mai 2026, Palo Alto Networks a confirme l existence de CVE-2026-0300, un zero-day critique (CVSS-BT 9.3) dans le User-ID Authentication Portal de PAN-OS. Un attaquant non authentifie peut executer du code arbitraire avec des privileges root sur les firewalls PA-Series et VM-Series. La CISA a ajoute la vulnerabilite au catalogue KEV le meme jour, avec une deadline de mitigation au 9 mai 2026 pour les agences federales americaines. Les patches ne seront disponibles qu entre le 13 et le 28 mai 2026. Pour une analyse detaillee de la vulnerabilite, consultez notre article CVE-2026-0300 PAN-OS : zero-day RCE root sur firewalls Palo Alto.

Ce guide pratique vous donne les 7 etapes concretes pour auditer votre parc de firewalls Palo Alto, appliquer les mitigations et preparer le patching. Chaque etape inclut les commandes CLI, les verifications a effectuer et les criteres de validation.

— Etape 1 : inventorier tous les firewalls Palo Alto du parc

Objectif : identifier en moins de 2 heures chaque firewall PA-Series et VM-Series de votre infrastructure, avec sa version PAN-OS exacte. Cette etape est le prealable indispensable a toute action de mitigation.

Si vous utilisez Panorama (la console de management centralisee de Palo Alto), l inventaire est immediat. Connectez-vous a Panorama et accedez a Panorama > Managed Devices > Summary. Vous obtiendrez la liste complete des firewalls manages, avec leurs versions PAN-OS, modeles et etats de connectivite. Exportez cette liste en CSV pour la tracer.

Sans Panorama, connectez-vous en SSH a chaque firewall et executez la commande show system info. Relevez les champs « sw-version » (version PAN-OS), « model » (PA-Series ou VM-Series) et « hostname ». Pour un parc de 10 a 50 firewalls, cette operation prend 30 minutes a 2 heures. Automatisez avec un script Ansible ou Python (bibliotheque pan-os-python) si le parc est plus grand.

Critere de validation : vous disposez d un tableur avec chaque firewall, son modele, sa version PAN-OS exacte, son role (perimetre Internet, segmentation interne, DMZ) et son exposition reseau. Marquez en rouge les firewalls executant les versions PAN-OS 12.1, 11.2, 11.1 ou 10.2 — ce sont ceux affectes par CVE-2026-0300.

— Etape 2 : verifier l etat du User-ID Authentication Portal sur chaque firewall

Objectif : determiner pour chaque firewall affecte si le User-ID Authentication Portal (Captive Portal) est active, et si oui, sur quelles interfaces et depuis quels reseaux il est accessible.

Via la CLI PAN-OS, executez les commandes suivantes sur chaque firewall affecte. La commande show running global-protect-gateway affiche l etat des composants GlobalProtect et du portail d authentification. La commande show user-id-agent config all montre la configuration complete des agents User-ID. Cherchez toute reference au « Authentication Portal » ou « Captive Portal » dans la sortie.

Via l interface web, naviguez vers Device > User Identification > Authentication Portal Settings. Verifiez si le portail est active (case cochee) et sur quelles interfaces il ecoute. Notez egalement les zones de securite associees : si le portail est configure pour la zone « untrust » (Internet), le firewall est en exposition maximale (CVSS-BT 9.3). Si c est uniquement la zone « trust » (reseau interne), le risque est reduit mais reste critique (CVSS-BT 8.7).

Point d attention : le portail peut etre active dans la configuration meme si aucune regle de securite ne l utilise explicitement. Un portail active mais « non reference » reste un service ecoute accessible. Verifiez egalement si des regles de type « captive-portal » existent dans la policy de securite (Policies > Security). Un firewall peut avoir le portail active sans que l equipe operationnelle en ait conscience, notamment apres une migration ou un upgrade.

Critere de validation : pour chaque firewall, vous savez si le Captive Portal est active (oui/non), sur quelles interfaces il ecoute, dans quelles zones de securite, et s il est accessible depuis Internet. Classez les firewalls en trois categories : expose Internet (P0), interne uniquement (P1), portail desactive (P2).

— Etape 3 : appliquer la mitigation sur chaque firewall affecte

Objectif : reduire la surface d attaque a zero en moins de 4 heures pour les firewalls P0 (internet-facing) et en moins de 8 heures pour les firewalls P1 (internes).

Option A : restreindre l acces au portail par adresse IP source. C est la mitigation recommandee par Palo Alto Networks si le Captive Portal est necessaire au fonctionnement de votre architecture. Dans l interface web, allez dans Device > User Identification > Authentication Portal Settings et configurez une liste d adresses IP sources autorisees limitee a vos reseaux internes de confiance. Seuls les utilisateurs provenant de ces reseaux pourront acceder au portail. Les connexions depuis d autres sources seront rejetees avant d atteindre le code vulnerable.

Option B : desactiver completement le portail. Si le User-ID Authentication Portal n est pas utilise dans votre architecture (beaucoup d entreprises utilisent d autres mecanismes d authentification comme GlobalProtect, SAML ou des agents User-ID), desactivez-le completement. Dans Device > User Identification > Authentication Portal Settings, decochez la case d activation. Commitez la configuration. Cette option elimine totalement la surface d attaque.

Important : ces deux operations sont des modifications de configuration a chaud qui ne necessitent pas de redemarrage du firewall ni d interruption de service. Cependant, la restriction ou la desactivation du portail impactera les utilisateurs qui l utilisent pour s authentifier. Communiquez en amont avec les equipes metier. Documentez l heure exacte de l application de la mitigation sur chaque firewall pour le reporting de conformite NIS2.

Critere de validation : pour chaque firewall, le Captive Portal est soit restreint aux IPs internes de confiance, soit desactive. Testez en tentant d acceder au portail depuis une adresse IP non autorisee : la connexion doit etre rejetee. Conservez une capture d ecran de la configuration et du test comme preuve de mitigation.

— Etape 4 : analyser les logs pour detecter une exploitation anterieure

Objectif : determiner si vos firewalls ont ete exploites via CVE-2026-0300 avant l application de la mitigation. Cette etape est critique pour savoir si vous etes dans un scenario de remediation (mitigation) ou de reponse a incident (compromission confirmee).

Logs du Captive Portal. Connectez-vous en CLI et analysez les logs du portail d authentification. Recherchez les requetes avec des champs de donnees anormalement longs (superieur a 4 Ko), des tentatives de connexion repetees depuis des adresses IP inconnues, et des patterns de requetes POST inhabituels vers les URLs du Captive Portal. La commande less mp-log authd.log vous donnera acces aux logs d authentification detailles.

Logs systeme. Recherchez des anomalies dans les logs systeme du firewall : redemarrages inexpliques, erreurs de segmentation (segfault), crashes du processus du portail web, ou modifications de configuration non tracees dans les logs de commit. La commande less mp-log ms.log et show jobs all vous aideront a identifier des comportements anormaux. Un buffer overflow reussi peut provoquer un crash du processus avant que l attaquant ne stabilise l exploitation.

Logs reseau du management plane. Si vous capturez le trafic du segment de management de vos firewalls (bonnes pratiques), analysez les 30 derniers jours. Recherchez des connexions sortantes depuis l adresse IP de management vers des destinations non attendues, en particulier sur des ports non standards. Un firewall compromis au niveau root peut etablir des reverse shells ou des tunnels C2 depuis le management plane.

Critere de validation : vous avez analyse les logs de chaque firewall sur les 30 derniers jours. Deux resultats possibles : aucun indicateur de compromission detecte (passez a l etape 5) ou indicateurs suspects trouves (passez en mode reponse a incident et contactez votre CERT ou WebGuard).

— Etape 5 : verifier l integrite de la configuration et des comptes

Objectif : s assurer qu un attaquant n a pas modifie la configuration du firewall, ajoute des comptes administrateur backdoor ou altere les certificats de confiance. Un acces root donne un controle total sur la configuration PAN-OS.

Comparaison de configuration. Exportez la configuration actuelle du firewall via scp export configuration from running-config.xml et comparez-la avec votre derniere sauvegarde connue comme saine. Utilisez un outil de diff textuel pour identifier toute modification. Portez une attention particuliere aux regles de securite, aux profils de decryption SSL, aux objets adresse et aux routes statiques. Un attaquant sophistique ajoutera des regles d autorisation discretes plutot que de modifier les regles existantes.

Comptes administrateur. Executez show admins all en CLI et comparez la liste avec votre reference. Recherchez des comptes inconnus, des comptes desactives qui ont ete reactives, ou des modifications de role (un compte en lecture seule promu superuser). Verifiez egalement les cles SSH autorisees sur le compte admin et les certificats clients configures pour l authentification.

Certificats CA. Verifiez la liste des certificats CA de confiance installes sur le firewall via Device > Certificate Management > Certificates. Un attaquant root peut ajouter un certificat CA pour intercepter le trafic SSL/TLS via le profil de decryption. Comparez avec votre liste de reference. Tout certificat CA non reconnu doit etre considere comme un indicateur de compromission majeur.

Critere de validation : la configuration, les comptes administrateur et les certificats correspondent a vos references. Aucune modification non autorisee detectee. Si des anomalies sont identifiees, passez immediatement en mode reponse a incident.

— Etape 6 : planifier le patching echelonne

Objectif : preparer le deploiement des patches PAN-OS des leur disponibilite (a partir du 13 mai 2026) avec un plan de maintenance structure et des procedures de rollback.

Calendrier de disponibilite des patches (annonce par Palo Alto Networks) : PAN-OS 12.1 et 11.2 le 13 mai, PAN-OS 11.1 le 18 mai, PAN-OS 10.2 le 28 mai. Planifiez vos fenetres de maintenance en consequence. Si vous exploitez des firewalls dans des versions differentes, vous aurez potentiellement trois fenetres de maintenance a planifier sur 3 semaines.

Pour les firewalls en haute disponibilite (HA), le patching suit un processus specifique. Commencez par le firewall passif : appliquez le patch, verifiez le bon fonctionnement, puis basculez le trafic vers le firewall patche. Patchez ensuite le second firewall. Cela permet de maintenir la continuite de service. Prevoyez 30 a 60 minutes par paire HA. Pour les firewalls standalone, prevoyez une interruption de service de 15 a 30 minutes pour le redemarrage post-patch.

Procedure de rollback : avant d appliquer le patch, sauvegardez la configuration actuelle et notez la version PAN-OS en cours. En cas de probleme post-patch (incompatibilite, regression fonctionnelle), vous pourrez revenir a la version precedente via request system software install version [version-precedente]. Testez la procedure de rollback sur un firewall de pre-production ou de lab si possible.

Critere de validation : vous disposez d un plan de patching documente avec les fenetres de maintenance validees par les equipes metier, les procedures de rollback testees, et les firewalls priorises par niveau d exposition (internet-facing en premier).

— Etape 7 : durcir la configuration du Captive Portal post-patch

Objectif : au-dela du patch, renforcer la configuration du User-ID Authentication Portal pour reduire la surface d attaque en cas de future vulnerabilite et ameliorer la posture de securite globale du firewall.

Principe du moindre privilege pour le portail. Meme apres le patch, maintenez la restriction d acces au Captive Portal par adresse IP source. Le portail ne doit etre accessible que depuis les reseaux strictement necessaires. Si seuls les utilisateurs du VLAN bureautique doivent s authentifier via le Captive Portal, limitez l acces a ce VLAN uniquement. N exposez jamais le Captive Portal directement sur Internet si vous pouvez l eviter.

Monitoring du portail. Configurez une regle de log dediee pour toutes les connexions au Captive Portal. Envoyez ces logs vers votre SIEM avec des alertes sur les tentatives de connexion echouees repetees, les requetes malformees et les acces depuis des adresses IP non autorisees. Cela vous donnera une visibilite immediate en cas de future tentative d exploitation.

Alternatives au Captive Portal. Evaluez si vous pouvez remplacer le Captive Portal par des mecanismes d authentification moins exposes. Les agents User-ID installes sur les controleurs de domaine Active Directory identifient les utilisateurs sans portail web expose. L authentification SAML via un IdP (Identity Provider) comme Azure AD/Entra ID ou Okta est egalement une alternative plus securisee. La suppression du Captive Portal elimine definitivement cette surface d attaque.

Documentation et conformite. Documentez l ensemble de l audit (etapes 1 a 7) dans un rapport structure. Ce rapport servira de preuve de diligence pour la conformite NIS2 (article 21 sur la gestion des vulnerabilites) et pour vos assureurs cyber. Incluez les horodatages de chaque action, les captures d ecran des configurations avant/apres, et les resultats de l analyse forensique. Conservez ce dossier minimum 12 mois.

Critere de validation : le patch est applique sur tous les firewalls, la configuration du Captive Portal est durcie (acces restreint, monitoring actif), les alternatives au Captive Portal ont ete evaluees, et l ensemble de l audit est documente pour la conformite.

— FAQ