<p>Le CERT-FR a publié le 4 août 2026 un avis sur une vulnérabilité (CVE-2026-18574) affectant Check Point Security Management. Elle autorise...
Dans la plupart des petites entreprises, le pare-feu est un boîtier posé dans un local technique, dont on ne parle plus une fois l'installation terminée. Ce qu'on oublie, c'est qu'il obéit à une console: un serveur d'administration qui détient les règles de filtrage. Cette console est un actif sensible, et c'est précisément elle qui est visée par l'avis publié cette semaine.
Le CERT-FR a publié le 4 août 2026 un avis (référence CERTFR-2026-AVI-0965) concernant une vulnérabilité affectant Check Point Security Management et Multi-Domain Security Management. La faille, identifiée sous la référence CVE-2026-18574, permet une exécution de code arbitraire à distance ainsi qu'un contournement de la politique de sécurité. Traduit en termes concrets: un attaquant peut faire exécuter ses propres instructions au serveur d'administration, et lui faire ignorer les règles qu'il est censé appliquer.
Les versions concernées, telles qu'indiquées dans l'avis et dans le bulletin de l'éditeur, sont les suivantes: R81.20 antérieures au Take 161, R82 antérieures au Take 122 et R82.10 antérieures au Take 40.
Check Point précise par ailleurs que les versions R80 à R81.10, aujourd'hui obsolètes, sont également touchées. L'avis du CERT-FR ne mentionne aucune exploitation constatée à la date de sa publication. Ce statut est susceptible d'évoluer: c'est la page de l'avis qui fait référence, pas cet article. Une compromission de pare-feu ne ressemble pas à une panne. C'est ce qui la rend gênante.
Rien ne paraît anormal côté utilisateurs. Les postes fonctionnent, la messagerie fonctionne, Internet fonctionne. Une règle de filtrage modifiée ne produit aucun symptôme visible. Le pare-feu est le point de passage de tout le trafic. Qui contrôle la console peut ouvrir un accès vers l'intérieur du réseau, ou laisser sortir des données vers l'extérieur.
Beaucoup de PME ne savent pas quelle version elles utilisent. Lorsque le pare-feu est géré par un prestataire, l'information existe, mais elle n'est pas chez le client. Sans la demander, on ne peut pas savoir si l'on est concerné. Les versions obsolètes sont fréquentes. Un équipement qui fonctionne depuis six ans n'incite pas à la migration. C'est pourtant sur ces versions que l'écart de sécurité se creuse le plus vite.
Ce qu'il faut faire
La démarche est simple, mais elle demande une réponse écrite de la part de qui administre l'équipement.
Demander la version exacte. Si votre pare-feu est un Check Point, obtenez de votre prestataire la version du Security Management et la date prévue d'application du correctif — au minimum R81.20 Take 161, R82 Take 122 ou R82.10 Take 40. Traiter le cas des versions obsolètes. En R80.x ou R81.x, la rustine ne règle pas le fond du problème. Demandez un plan de migration chiffré et daté.
Vérifier l'exposition de l'interface d'administration. Elle ne doit pas être joignable depuis Internet, mais restreinte à un réseau d'administration ou accessible via VPN. Activer l'authentification à deux facteurs sur tous les comptes administrateurs de l'équipement.
Relire le journal des modifications de règles sur les trente derniers jours après la mise à jour, à la recherche d'un changement que personne ne peut expliquer. Planifier l'intervention hors heures ouvrées, avec une sauvegarde de configuration préalable et un point de retour arrière identifié.
Les références de versions et de Takes citées ici le sont à titre indicatif: elles doivent être validées sur le bulletin de l'éditeur et sur votre infrastructure avant toute application en production. Une faille de pare-feu ne se remarque pas depuis un poste de travail: il faut aller la chercher. Un courriel à votre prestataire demandant la version installée et la date du correctif suffit à savoir où vous en êtes. Si la réponse tarde ou reste vague, c'est en soi une information utile sur la façon dont votre périmètre réseau est suivi. CERT-FR, avis CERTFR-2026-AVI-0965, « Vulnérabilité dans Check Point Security Management », publié le 4 août 2026. Check Point, bulletin de sécurité sk185222, publié le 2 août 2026.
Synthèse rédactionnelle originale de TICLIC, établie à partir de la veille du 6 août 2026. Les éléments techniques proviennent de l'avis du CERT-FR et du bulletin de l'éditeur, deux sources concordantes. Aucune recherche web externe n'a été menée lors de la rédaction; le statut d'exploitation de la vulnérabilité est celui connu au 6 août 2026 et doit être revérifié sur la page de l'avis, qui est tenue à jour.