PAN-OS GlobalProtect : CVE-2026-0257 désormais exploitée

Une vulnérabilité de contournement d’authentification affectant PAN-OS et Prisma Access lorsque la fonctionnalité GlobalProtect est exposée sur Internet est désormais signalée comme exploitée en conditions réelles. La faille est suivie sous l’identifiant CVE-2026-0257. Selon l’advisory officiel de Palo Alto Networks, le problème permet à un attaquant non authentifié de contourner certaines étapes d’authentification sur le portail ou la passerelle VPN GlobalProtect dans des conditions précises, avec pour conséquence potentielle un accès non autorisé à des ressources distantes.

Le point important pour les équipes d’exploitation et les RSSI n’est pas seulement le score théorique. Une vulnérabilité initialement classée de sévérité moyenne peut devenir hautement prioritaire dès lors qu’elle touche une passerelle VPN exposée, accessible depuis Internet, souvent positionnée à la frontière du SI et reliée à des réseaux internes sensibles. Dans ce contexte, la surface d’attaque est directe, l’exploitation peut être industrialisée, et la valeur opérationnelle pour un attaquant est élevée : accès distant, pivot réseau, collecte d’identifiants, rebond vers des services internes, voire préparation d’une compromission plus large.

La source médiatique ayant mis en avant l’exploitation active est BleepingComputer, dans sa publication consacrée à l’exploitation de la faille sur des déploiements GlobalProtect. La source technique de référence reste toutefois l’advisory officiel de Palo Alto Networks, qui précise les produits concernés, les versions vulnérables, les versions corrigées et les mesures d’atténuation. En environnement francophone, ce type d’alerte mérite une attention particulière pour les organisations hébergeant leurs services chez OVH, Scaleway ou o2switch, ainsi que pour les infrastructures hybrides où la passerelle VPN protège l’accès aux applications métiers, aux bastions d’administration et aux environnements cloud.

Si un score CVSS a pu apparaître comme modéré dans les premières communications, le niveau de risque opérationnel augmente fortement dès que trois conditions sont réunies : service exposé, exploit public ou exploitation observée, et positionnement stratégique du service. Un portail VPN coche souvent ces trois cases. Il faut donc traiter CVE-2026-0257 comme une priorité de patching et de vérification post-correctif, avec un travail parallèle sur l’inventaire, les journaux d’accès, les comptes récemment utilisés et les règles de segmentation réseau.

Versions affectées

D’après l’advisory officiel de Palo Alto Networks relatif à CVE-2026-0257, les produits concernés sont les déploiements PAN-OS et Prisma Access utilisant GlobalProtect. Les versions exactes dépendent de la branche logicielle et du rôle joué par l’équipement, notamment portal et gateway. Les administrateurs doivent impérativement vérifier l’advisory du constructeur pour recouper leur branche de maintenance avec la première version corrigée disponible.

En pratique, les environnements potentiellement touchés sont ceux qui réunissent les critères suivants :

un firewall ou service PAN-OS avec GlobalProtect Portal activé ;
un firewall ou service PAN-OS avec GlobalProtect Gateway activé ;
une exposition directe sur Internet via 443/TCP ou un port d’administration/VPN publié ;
un service Prisma Access utilisant les composants GlobalProtect concernés par l’avis de sécurité.

Les branches vulnérables sont celles mentionnées par Palo Alto Networks comme affectées par CVE-2026-0257. Comme les branches de maintenance PAN-OS évoluent rapidement, il faut raisonner de façon opérationnelle :

toute instance GlobalProtect non encore mise à niveau vers la première version corrigée de sa branche doit être considérée comme à risque ;
toute instance en fin de support ou hors fenêtre de maintenance doit être traitée comme prioritaire si elle reste exposée sur Internet ;
les plateformes Prisma Access doivent être vérifiées via les canaux de mise à jour et de statut fournis par Palo Alto Networks.

Pour identifier précisément la version en production sur un équipement PAN-OS, l’interface en ligne de commande permet de confirmer l’état logiciel :

> show system info | match sw-version

Sur certains équipements, il est également utile de vérifier l’activation et le rôle GlobalProtect :

> show running global-protect-gateway > show running global-protect-portal

Si l’accès CLI n’est pas disponible, la version peut être consultée depuis l’interface d’administration web, généralement dans Dashboard ou Device > Software. Pour les environnements managés de grande taille, il faut croiser l’inventaire avec la CMDB, les exports Panorama et les scans d’exposition Internet.

Les versions corrigées sont celles indiquées dans l’advisory officiel Palo Alto. En l’absence d’une politique de mise à jour homogène, une erreur fréquente consiste à supposer qu’une branche majeure récente est automatiquement protégée. Ce n’est pas toujours le cas. Une branche 11.x ou 10.x peut rester vulnérable tant qu’elle n’a pas reçu le maintenance release intégrant le correctif. Il faut donc viser la version explicitement corrigée et non une simple version “récente”.

Pour les organisations ayant plusieurs profils d’exposition, la priorisation recommandée est la suivante :

Priorité 1 : portails et passerelles GlobalProtect exposés à Internet avec accès aux réseaux de production ;
Priorité 2 : GlobalProtect exposé mais limité à des zones segmentées ou à des usages partenaires ;
Priorité 3 : instances non exposées directement, accessibles uniquement via réseau privé ou chaîne d’accès intermédiaire ;
Priorité 4 : environnements de recette ou de secours non routables depuis Internet.

Pour les RSSI, il faut également intégrer la notion de fenêtre d’exploitation. Dès lors qu’une exploitation active est rapportée publiquement, le délai entre la publication et les tentatives automatisées peut être très court. Les passerelles VPN visibles dans les moteurs de recherche de services exposés ou les bases de scan Internet deviennent des cibles évidentes.

Vecteur d’attaque

CVE-2026-0257 concerne un contournement d’authentification sur GlobalProtect. Le scénario le plus critique vise les portails et passerelles VPN exposés, accessibles avant authentification depuis Internet. Dans un modèle classique, GlobalProtect joue le rôle de point d’entrée distant pour les utilisateurs, parfois avec authentification multifactorielle, attribution de certificats, vérifications de posture et distribution de configuration. Toute faiblesse dans la chaîne d’authentification ou dans la validation d’état d’une session peut donc avoir des conséquences disproportionnées.

Concrètement, un attaquant distant cherche à interagir avec les points d’entrée GlobalProtect afin d’obtenir un comportement normalement réservé à un utilisateur légitime. Selon la configuration et la manière dont le composant vulnérable traite certaines requêtes, il peut devenir possible de court-circuiter une étape d’authentification, de récupérer une session exploitable ou d’accéder à des ressources censées être protégées. Même si le contournement ne donne pas immédiatement un shell sur l’équipement, il peut suffire à établir une présence initiale dans l’environnement cible.

Dans un contexte d’attaque réel, la chaîne peut ressembler à ceci :

repérage de passerelles GlobalProtect exposées via scan Internet ;
identification de la version PAN-OS ou du comportement caractéristique du portail ;
envoi de requêtes HTTP ou HTTPS forgées vers les endpoints GlobalProtect ;
obtention d’un état applicatif anormalement favorable, contournant l’authentification attendue ;
ouverture d’un accès distant ou récupération d’artefacts permettant un accès ultérieur ;
pivot vers des segments internes accessibles via la politique VPN ;
collecte d’identifiants, reconnaissance Active Directory, balayage SMB/RDP/SSH, puis mouvement latéral.

Le risque réel dépend fortement de la configuration de l’environnement. Une passerelle VPN accordant un accès large à un réseau bureautique, aux outils d’administration ou à un bastion représente une cible de premier choix. À l’inverse, une passerelle très segmentée, limitée à quelques applications publiées et protégée par des contrôles réseau stricts, réduit la portée immédiate de l’exploitation. Cela ne rend pas la faille acceptable pour autant : cela limite seulement l’impact potentiel.

Le fait que la faille soit exploitée “dans la nature” change le niveau d’urgence pour plusieurs raisons :

les attaquants n’ont plus besoin d’investir dans la recherche initiale, le mode opératoire circule déjà ;
les passerelles VPN sont des cibles très visibles et faciles à inventorier à grande échelle ;
le retour sur investissement d’une compromission est élevé, car l’accès distant ouvre souvent la porte au SI interne ;
les logs applicatifs sont parfois insuffisamment centralisés, ce qui retarde la détection.

Sur le plan de l’impact, il faut distinguer plusieurs niveaux :

Accès non autorisé à des applications ou réseaux publiés via GlobalProtect ;
Usurpation de contexte utilisateur si une session ou un jeton est obtenu ;
Pivot réseau vers des ressources internes exposées aux utilisateurs VPN ;
Compromission du SI si l’accès permet d’atteindre des annuaires, serveurs d’administration, hyperviseurs, outils de sauvegarde ou environnements cloud hybrides ;
Préparation d’une attaque ultérieure avec persistence, exfiltration ou déploiement de rançongiciel.

Dans les environnements français, il faut garder à l’esprit que de nombreuses PME et ETI utilisent leur VPN comme point d’entrée universel pour la bureautique, l’ERP, les accès RDP et les outils d’exploitation. Une faiblesse sur ce maillon peut donc avoir des conséquences transverses. Le risque est encore plus marqué lorsque l’équipement protège l’accès à des ressources hébergées chez OVHcloud, Scaleway ou dans des infrastructures mutualisées, car l’attaque peut servir de tremplin vers des assets critiques externalisés.

La comparaison avec des campagnes passées sur des appliances de sécurité est instructive. Les vulnérabilités touchant les équipements de bordure ont souvent un effet de sidération parce qu’elles cassent l’hypothèse de confiance placée dans le point d’entrée lui-même. On l’a déjà observé avec des failles affectant d’autres VPN ou firewalls d’entreprise : une sévérité “moyenne” sur le papier peut se traduire par une sévérité opérationnelle élevée si le service est exposé, stratégique et massivement déployé.

Un exemple simplifié de requête à surveiller côté reverse proxy ou collecte réseau peut ressembler à ceci, sans préjuger du détail exact de l’exploit :

POST /global-protect/login.esp HTTP/1.1 Host: vpn.exemple.fr User-Agent: python-requests/2.x Content-Type: application/x-www-form-urlencoded X-Forwarded-For: 127.0.0.1 user=test&passwd=test&inputStr=...

Ce type de trace n’est pas en soi une preuve d’exploitation. En revanche, une combinaison de requêtes atypiques, d’agents utilisateurs inhabituels, de codes HTTP inattendus, de succès d’authentification sans MFA visible ou d’ouvertures de session depuis des IP non cohérentes doit déclencher une investigation.

Pour les équipes SOC, il faut aussi surveiller les conséquences secondaires : création de tunnels VPN à des horaires inhabituels, accès à des sous-réseaux rarement utilisés, requêtes LDAP ou Kerberos anormales après une connexion GlobalProtect, et augmentation brutale des tentatives SMB, WinRM, RDP ou SSH depuis des pools d’adresses attribuées au VPN.

Impact

L’impact principal de CVE-2026-0257 est l’accès non autorisé via l’infrastructure GlobalProtect. Cela peut sembler limité si l’on s’arrête à la seule notion de “bypass d’authentification”, mais sur une passerelle VPN, cette capacité suffit souvent à transformer une exposition Internet en accès interne. L’effet de levier est donc important.

Dans un environnement peu segmenté, un attaquant peut obtenir :

une visibilité sur les plages d’adresses internes ;
un accès à des applications métiers non exposées publiquement ;
un point d’entrée pour le mouvement latéral ;
un canal de communication chiffré difficile à distinguer d’un trafic distant légitime ;
des opportunités de collecte d’identifiants ou de secrets applicatifs.

Les conséquences métier peuvent être rapides :

interruption de service si l’attaquant perturbe les accès distants ;
atteinte à la confidentialité en cas d’accès aux partages, bases ou applications internes ;
atteinte à l’intégrité si des consoles d’administration deviennent accessibles ;
risque réglementaire si des données personnelles ou sensibles sont exposées.

Pour un RSSI, la bonne lecture du risque n’est pas seulement technique. Il faut considérer l’équipement VPN comme un contrôle de sécurité critique. Lorsqu’une faille exploitable touche ce contrôle, la confiance dans la frontière d’accès distant est dégradée. Cela justifie un traitement accéléré, un suivi de crise allégé si nécessaire, et une vérification des traces sur une période remontant au moins à la première date connue d’exploitation active mentionnée par les sources publiques.

Comment patcher

La remédiation prioritaire consiste à mettre à jour PAN-OS ou Prisma Access vers la première version corrigée indiquée par Palo Alto Networks pour la branche en production. La source à suivre est l’advisory officiel de l’éditeur, qui détaille les versions affectées et les versions corrigées pour CVE-2026-0257. Il ne s’agit pas d’une vulnérabilité que l’on doit laisser en attente du prochain cycle de maintenance mensuel si la passerelle est exposée sur Internet.

Sur un firewall PAN-OS administré localement, la séquence standard passe par l’interface web ou la CLI. Avant toute mise à niveau, il faut :

exporter une sauvegarde de configuration ;
vérifier l’espace disque et l’état HA si l’équipement est en cluster ;
contrôler la compatibilité des plugins et du contenu dynamique ;
planifier une fenêtre de maintenance adaptée à l’usage VPN ;
prévoir un rollback documenté si la branche cible l’exige.

Exemples de commandes CLI utiles pour préparer la mise à jour :

> request system software check > show system info > request system software info

Sur certaines versions, le téléchargement et l’installation peuvent être pilotés ainsi :

> request system software download version 11.1.x-hy > request system software install version 11.1.x-hy

La chaîne exacte dépend de la branche cible. Il faut remplacer 11.1.x-hy par la version corrigée officielle correspondant à votre train de maintenance. Si l’équipement est géré par Panorama, la mise à jour doit être coordonnée avec la politique de déploiement centralisée et la haute disponibilité éventuelle.

Après installation, il faut vérifier :

la version effective :

> show system info | match sw-version

l’état des composants GlobalProtect ;
la disponibilité du portail et de la passerelle ;
les journaux d’authentification ;
les éventuelles anomalies de certificat, de MFA ou de SAML.

Pour Prisma Access, la remédiation dépend du mode de service et du calendrier de mise à disposition des correctifs côté éditeur. Les clients doivent vérifier les communications officielles, les notifications de maintenance et les tableaux de bord de statut. Dans certains cas, l’action côté client portera surtout sur la validation de l’exposition, l’application des mesures d’atténuation et le contrôle des logs après déploiement du correctif par le fournisseur.

Il n’existe pas de commande apt, dnf ou composer applicable ici, car il s’agit d’un produit de sécurité propriétaire. La bonne pratique est de documenter explicitement l’absence de gestionnaire de paquets standard et de centraliser la remédiation dans le runbook équipement. Un exemple de fiche d’exploitation interne peut mentionner :

Produit : PAN-OS / GlobalProtect CVE : CVE-2026-0257 Action : upgrade vers version corrigée Palo Alto Canal : Device > Software ou CLI request system software ... Validation : test portail, test gateway, journaux auth, version effective

Calendrier de patch recommandé :

Sous 24 heures : inventaire complet des portails et passerelles exposés ;
Sous 48 heures : mise à jour des équipements Internet-facing les plus critiques ;
Sous 72 heures : revue des logs historiques et rotation des accès si suspicion ;
Sous une semaine : traitement des environnements secondaires, PRA, lab et sites distants.

Si votre organisation dépend fortement de l’accès distant et ne peut pas interrompre le service, une stratégie raisonnable consiste à basculer un nœud HA, patcher le pair passif, valider le fonctionnement, puis effectuer le basculement contrôlé. Dans tous les cas, la fenêtre de risque doit être réduite au maximum.

Détection

Lorsqu’une faille de contournement d’authentification sur VPN est annoncée comme exploitée, la détection doit couvrir à la fois les tentatives d’exploitation et les signes d’accès réussi. Les équipes doivent collecter et corréler les journaux de GlobalProtect, de system, d’authentification, de pare-feu, ainsi que les traces réseau ou proxy si elles existent.

Les points de contrôle prioritaires sont les suivants :

succès de connexion VPN sans séquence MFA attendue ;
création de session depuis des adresses IP inhabituelles ou géographiquement incohérentes ;
pics de requêtes sur les endpoints GlobalProtect avant authentification ;
codes de réponse HTTP anormaux sur les URLs du portail ;
agents utilisateurs rares, scripts ou bibliothèques HTTP automatisées ;
augmentation des connexions internes depuis les pools d’adresses VPN ;
accès à des ressources d’administration peu après une connexion GlobalProtect ;
écarts entre les logs SAML, IdP ou MFA et les journaux de session VPN.

Quelques indicateurs de compromission ou de tentative, à adapter à votre environnement :

requêtes répétées vers des chemins GlobalProtect avec paramètres inhabituels ;
présence de headers non attendus comme X-Forwarded-For ou X-Real-IP dans des contextes atypiques ;
séquences très rapides de tentatives sur plusieurs endpoints /global-protect/ ;
connexion VPN réussie depuis une IP n’ayant jamais été utilisée par le compte concerné ;
apparition d’un trafic interne de reconnaissance juste après l’établissement du tunnel ;
création ou utilisation de sessions de courte durée mais répétées.

Exemples de chemins à surveiller dans les journaux web ou applicatifs, selon la configuration :

/global-protect/login.esp /ssl-vpn/login.esp /global-protect/getconfig.esp /global-protect/prelogin.esp

Dans un SIEM, une règle de détection simple peut corréler une requête anormale sur un endpoint GlobalProtect avec une session VPN réussie dans les minutes suivantes. Une logique complémentaire consiste à alerter lorsqu’un utilisateur obtient un accès VPN alors qu’aucun événement MFA correspondant n’est observé côté fournisseur d’identité.

Exemple de pseudo-corrélation :

IF http.path CONTAINS "/global-protect/" AND user_agent MATCHES "python|curl|Go-http-client|libwww" AND source.ip NOT IN allowlist_admin_scan THEN raise medium_alert

Et une corrélation de niveau supérieur :

IF vpn.session = success AND mfa.event ABSENT within 5m AND source.ip is new for user THEN raise high_alert

Les journaux PAN-OS à examiner en priorité comprennent :

System logs pour les événements de service et d’authentification ;
GlobalProtect logs pour les connexions portail et gateway ;
Traffic logs pour les flux établis depuis les pools VPN vers l’interne ;
Threat logs si des signatures ou comportements corrélés sont déclenchés.

Si une suspicion existe, les actions immédiates recommandées sont :

exporter les logs avant rotation ;
identifier les comptes ayant obtenu un accès via GlobalProtect sur la période suspecte ;
réinitialiser ou renforcer les comptes concernés, notamment ceux à privilèges ;
révoquer les sessions actives et forcer une réauthentification ;
examiner les flux internes initiés depuis les adresses VPN ;
vérifier l’intégrité des systèmes atteints après la connexion ;
contrôler les accès aux bastions, annuaires, sauvegardes et consoles d’administration.

Dans le contexte français, si des indices sérieux de compromission sont relevés, il est pertinent d’aligner la réponse avec les procédures de gestion d’incident internes et, selon la criticité, de consulter les ressources de CERT-FR pour les bonnes pratiques de traitement, de confinement et de notification.

Mitigation

Si le correctif ne peut pas être appliqué immédiatement, des mesures d’atténuation doivent être mises en place sans attendre. Elles ne remplacent pas la mise à jour, mais peuvent réduire la probabilité d’exploitation ou limiter l’impact.

Réduire l’exposition Internet : limiter l’accès au portail ou à la gateway à des plages IP connues si l’usage le permet ;
Désactiver temporairement les composants non indispensables de GlobalProtect ;
Renforcer la segmentation des réseaux accessibles via VPN ;
Restreindre les comptes autorisés et revoir les groupes d’accès ;
Vérifier le MFA et les intégrations SAML/IdP ;
Surveiller en temps réel les journaux d’authentification et les sessions ;
Mettre en quarantaine les ressources d’administration non nécessaires depuis le VPN.

Mesures techniques concrètes :

restreindre les règles de sécurité vers les sous-réseaux d’administration ;
interdire l’accès VPN direct aux contrôleurs de domaine, hyperviseurs, outils de sauvegarde et consoles cloud ;
imposer un passage par un bastion dédié ;
appliquer des profils de détection et de journalisation plus stricts sur les flux issus des pools GlobalProtect ;
réduire la durée de vie des sessions et forcer la réauthentification sur les usages sensibles.

Si la passerelle est publiée derrière un service intermédiaire, il peut être utile de filtrer certains comportements HTTP anormaux ou de limiter les requêtes automatiques. Cette approche reste toutefois imparfaite : un contournement d’authentification au niveau applicatif ne se neutralise pas toujours proprement avec un simple filtrage réseau.

Pour les équipes d’exploitation, une mitigation efficace consiste aussi à resserrer temporairement le périmètre fonctionnel du VPN. Beaucoup d’organisations laissent des accès historiques ouverts par habitude. En situation d’alerte, il faut revenir au besoin minimal : applications indispensables, groupes restreints, horaires surveillés, administration séparée.

Exemple de bonnes pratiques immédiates :

désactiver les accès “any to internal” hérités de configurations anciennes ;
revoir les routes poussées aux clients GlobalProtect ;
segmenter les populations utilisateurs, prestataires et administrateurs ;
forcer l’usage d’un bastion MFA pour toute administration distante ;
journaliser finement les connexions réussies et les échecs anormaux.

Cette alerte rappelle un point récurrent : la frontière VPN doit être traitée comme un actif critique, au même titre qu’un annuaire ou un bastion. Une faille exploitée sur ce type d’équipement justifie un correctif prioritaire, une revue d’exposition Internet et un contrôle des traces sur plusieurs jours. Pour compléter ce travail par des mesures durables de durcissement, segmentation et hygiène d’administration, les équipes peuvent consulter les ressources de la catégorie /categorie/pratiques, utile pour transformer une réaction d’urgence en amélioration structurelle de la sécurité.

Serveurs

Retour aux actualités