| Nom du plugin | Spectres |
|---|---|
| Type de vulnérabilité | Élévation des privilèges |
| Numéro CVE | CVE-2026-7465 |
| Urgence | Moyen |
| Date de publication du CVE | 2026-06-02 |
| URL source | CVE-2026-7465 |
Escalade de privilèges du plugin Spectra (CVE-2026-7465) — Ce que les propriétaires de sites WordPress doivent faire maintenant
Résumé : Une vulnérabilité d'escalade de privilèges affectant le plugin WordPress Spectra (Ultimate Addons for Gutenberg) (corrigée dans la version 2.19.26) permet à un attaquant ayant un accès de niveau Contributeur d'escalader les privilèges et, dans certaines configurations, d'atteindre l'exécution de code à distance ou la prise de contrôle du site. Cet article explique ce qu'est la vulnérabilité, pourquoi elle est importante, comment la détecter et la mitiger rapidement, ainsi que des étapes pratiques de durcissement et de réponse aux incidents — du point de vue de WP-Firewall, un fournisseur de sécurité WordPress professionnel.
Contenu
- Que s'est-il passé (en bref)
- Qui est concerné ?
- Résumé technique (ce que la vulnérabilité permet)
- Scénarios d'exploitation et profil de risque
- Comment vérifier rapidement si vous êtes vulnérable
- Étapes d'atténuation immédiates (à court terme)
- Vérifications judiciaires et indicateurs de compromission (IoCs)
- Remédiation et renforcement à long terme
- Comment WP-Firewall aide à protéger votre site (configuration pratique)
- Sécurisez votre site aujourd'hui — Commencez avec le plan gratuit WP‑Firewall
- Foire aux questions
- Notes finales et liste de contrôle recommandée
Que s'est-il passé (en bref)
Une vulnérabilité dans le plugin Spectra Gutenberg Blocks / Ultimate Addons for Gutenberg (versions jusqu'à et y compris 2.19.25) a été publiée et a reçu le CVE-2026-7465. Le bug permet à un utilisateur avec des privilèges de niveau Contributeur d'effectuer des actions au-delà de ses permissions prévues — en d'autres termes, une escalade de privilèges. Dans certains contextes de déploiement, cela peut être exploité pour atteindre l'exécution de code à distance (RCE) ou des portes dérobées persistantes.
L'auteur du plugin a publié une version corrigée (2.19.26). Si votre site utilise Spectra et n'est pas encore mis à jour vers 2.19.26 ou une version ultérieure, votre site est à risque élevé.
Qui est concerné ?
- Sites exécutant le plugin Spectra (Ultimate Addons for Gutenberg) à la version 2.19.25 ou antérieure.
- Sites où des comptes utilisateurs de niveau Contributeur (ou similaire) existent — cela inclut les équipes éditoriales, les auteurs invités ou tout contributeur externe.
- Sites qui n'ont pas de pare-feu d'application web (WAF) actif ou de surveillance pouvant bloquer ou détecter les tentatives d'exploitation.
- Sites où les permissions de fichiers, les restrictions de plugins/thèmes ou le durcissement de la sécurité sont laxistes.
Note: Les administrateurs, éditeurs et rôles supérieurs sont déjà puissants ; le problème critique ici est qu'un compte à faible privilège (contributeur) peut être exploité pour obtenir un contrôle beaucoup plus grand.
Résumé technique (ce que la vulnérabilité permet)
À un niveau élevé, la vulnérabilité est un défaut d'escalade de privilèges dans la façon dont le plugin valide et traite certaines actions initiées par un utilisateur connecté. Un utilisateur de niveau contributeur peut créer des requêtes qui sont traitées de manière non sécurisée par les chemins de code du plugin, entraînant une escalade des capacités. Cette escalade peut être utilisée pour :
- Contourner les restrictions basées sur les rôles et effectuer des actions normalement réservées aux éditeurs ou aux administrateurs.
- Injecter ou modifier des données pouvant influencer le comportement du plugin, l'interface utilisateur admin ou le traitement du contenu.
- Dans des configurations de serveur spécifiques (selon les permissions de fichiers et d'autres plugins/thèmes), atteindre une injection de code persistante ou déposer des portes dérobées qui entraînent une exécution de code à distance.
Parce que cette attaque nécessite un utilisateur authentifié, les attaquants utilisent souvent ce vecteur après avoir créé ou acheté des comptes de contributeurs (par exemple, via l'enregistrement, l'ingénierie sociale) ou lorsque un compte de contributeur légitime est compromis.
Lecteurs techniques : la classification s'aligne sur les échecs d'identification/authentification (contrôle d'accès défaillant) et impacte l'intégrité et la confidentialité/disponibilité potentielle en fonction des actions ultérieures que les attaquants entreprennent.
Scénarios d'exploitation et profil de risque
Pourquoi c'est dangereux :
- Les comptes de contributeurs sont courants sur les blogs multi-auteurs et les sites éditoriaux. De nombreux sites permettent les enregistrements ou ont des personnes qui ont besoin d'un accès éditorial limité — créant une surface d'attaque.
- La vulnérabilité peut être enchaînée avec d'autres faiblesses (mots de passe administratifs faibles, plugins avec accès en écriture, permissions de système de fichiers permissives) pour un compromis complet du site.
- Les campagnes de scan de masse automatisées ciblent souvent rapidement les vulnérabilités de plugins connues après leur divulgation ; les sites qui restent non corrigés sont fréquemment sondés et exploités.
Scénarios typiques d'attaquants :
- L'attaquant enregistre un compte de contributeur (si l'enregistrement est ouvert) ou compromet un compte de contributeur avec des identifiants faibles.
- En utilisant le compte de contributeur, l'attaquant crée des requêtes qui ciblent les points de terminaison ou actions de plugin non sécurisés.
- Le plugin autorise incorrectement la requête, élevant les capacités pour cet utilisateur.
- L'attaquant crée des publications avec des charges utiles malveillantes, crée des utilisateurs de niveau administrateur, modifie des fichiers de thème/plugin, ou introduit des portes dérobées.
- Si les permissions de fichiers et les paramètres du serveur le permettent, l'attaquant persiste du code qui entraîne l'exécution de commandes à distance ou la prise de contrôle complète du site.
Profil de risque : CVSS autour de 8.8 (Élevé) — une remédiation immédiate est recommandée.
Comment vérifier rapidement si vous êtes vulnérable
- Écran de plugin admin WordPress :
- Connectez-vous à wp-admin en tant qu'Admin.
- Allez dans Extensions → Extensions installées.
- Recherchez “Spectra”, “Ultimate Addons for Gutenberg”, ou similaire et vérifiez la version installée.
- Si la version ≤ 2.19.25, le plugin est vulnérable.
- Vérification des fichiers (avancé) :
- Depuis le serveur ou le système de fichiers WP, identifiez le répertoire du plugin (généralement wp-content/plugins/spectra ou ultimate-addons-for-gutenberg).
- Vérifiez les informations d'en-tête du plugin dans le fichier PHP principal du plugin pour la version.
- Si vous maintenez des enregistrements de version de plugin, vérifiez les correspondances.
- Rôles d'audit :
- Examinez les utilisateurs avec le rôle de contributeur (Utilisateurs → Tous les utilisateurs) et toutes les options d'enregistrement de site (Réglages → Général → Adhésion).
- Si vous avez des contributeurs et que la version du plugin est vulnérable, traitez le site comme une priorité élevée.
- Journaux / Surveillance :
- Vérifiez les journaux de votre serveur web pour des requêtes suspectes vers des points de terminaison spécifiques au plugin ou des requêtes malformées provenant d'utilisateurs connectés.
- Si vous avez des journaux WAF, recherchez les tentatives d'exploitation bloquées depuis la divulgation publique.
Si vous trouvez des versions vulnérables, passez aux étapes d'atténuation immédiates ci-dessous.
Atténuations immédiates (à court terme — agissez maintenant)
Si vous ne pouvez pas immédiatement mettre à niveau vers 2.19.26, prenez les mesures suivantes pour réduire le risque. Celles-ci sont critiques dans le temps et doivent être appliquées dès que possible.
- Mettez à niveau le plugin (préféré et le plus rapide)
- Mettez à jour Spectra vers 2.19.26 ou une version ultérieure immédiatement via le mise à jour de plugin WordPress ou en remplaçant manuellement les fichiers du plugin.
- Testez sur un environnement de staging si possible, puis en production.
- Si la mise à jour n'est pas possible immédiatement : désactivez le plugin
- Désactivez le plugin via wp-admin ou en renommant le dossier du plugin via FTP/SFTP/SSH. Cela supprime instantanément le vecteur de vulnérabilité (mais peut affecter la fonctionnalité du site).
- Restreindre les comptes de Contributeur
- Suspendre temporairement ou rétrograder les comptes de contributeurs qui ne sont pas activement nécessaires.
- Supprimez les enregistrements d'utilisateurs s'ils sont ouverts (Réglages → Général → décochez “Tout le monde peut s'inscrire”) jusqu'à ce que le site soit corrigé.
- Renforcez les points de terminaison REST / admin
- Si vous avez un WAF, activez une règle pour bloquer les requêtes POST suspectes vers des points de terminaison spécifiques au plugin ou des chemins d'action connus comme vulnérables.
- Bloquez l'accès aux fichiers d'administration du plugin via IP ou restreignez l'accès aux IPs d'administration connues (si possible).
- Forcez la rotation des identifiants
- Forcer la réinitialisation du mot de passe pour les utilisateurs avec des rôles de Contributeur et supérieurs.
- Appliquez des mots de passe forts et une authentification à deux facteurs pour tous les comptes administrateurs/éditeurs.
- Verrouillez les permissions de fichiers
- S'assurer que wp-config.php et les fichiers critiques ne sont pas accessibles en écriture par tous.
- Limiter les capacités de modification de fichiers lorsque cela est possible.
- Surveillez les journaux de manière intensive
- Activer une journalisation accrue pour les prochaines 72 heures ; suivre les demandes authentifiées suspectes et les créations de publications / écritures de fichiers de plugin inhabituelles.
- Mettre le site en mode maintenance (pour les sites à haut risque)
- Si un risque d'exploitation et des fonctions critiques pour l'entreprise existent, envisager un mode maintenance temporaire pendant que vous appliquez le correctif.
Appliquer une combinaison des éléments ci-dessus réduira considérablement la probabilité d'exploitation avant qu'un correctif ne soit appliqué.
Vérifications judiciaires et Indicateurs de Compromission (IoCs)
Si vous soupçonnez que le site a été exploité avant le correctif, effectuez ces vérifications rapidement.
- Anomalies de compte utilisateur
- Nouveaux comptes admin/éditeur créés sans autorisation.
- Comptes de contributeurs se promouvant eux-mêmes ou ayant soudainement des capacités supérieures.
- Anomalies de contenu
- Publications/pages publiées avec un contenu étrange, des scripts obfusqués, des iframes injectées ou des liens vers des domaines inconnus.
- Brouillons contenant des charges utiles encodées en base64 ou un contenu de shortcode inhabituel.
- Changements dans le système de fichiers
- Fichiers de base de plugin/thème modifiés avec des horodatages récents, en particulier en dehors des fenêtres de mise à jour normales.
- Fichiers PHP inconnus dans wp-content/uploads ou sous-répertoires. Les attaquants cachent souvent des portes dérobées dans les téléchargements.
- Tâches planifiées suspectes
- Vérifiez les tâches cron wps (via Outils → Actions programmées ou plugins de surveillance WP-Cron). Les portes dérobées peuvent planifier des tâches persistantes.
- Connexions sortantes
- Connexions sortantes inhabituelles du serveur vers des IP ou des domaines inconnus. Cela peut indiquer un retour vers l'infrastructure de l'attaquant.
- Entrées de journal
- Recherchez des demandes authentifiées en tant que contributeurs effectuant des POST vers des points de terminaison spécifiques au plugin, en particulier autour de la chronologie de divulgation.
- Journaux d'accès montrant des tentatives d'accès à l'éditeur de thème/plugin ou aux fichiers wp-admin par des utilisateurs non administrateurs.
- Analyse des logiciels malveillants
- Effectuez une analyse complète des logiciels malveillants avec un scanner réputé. Recherchez des signatures de webshell connues, un contenu de fichier inhabituel et des drapeaux de permission modifiés.
Si vous trouvez des indicateurs de compromission :
- Mettez immédiatement le site hors ligne ou en mode maintenance.
- Faites tourner tous les mots de passe et révoquez les jetons et les clés API.
- Restaurez à partir d'une sauvegarde connue et bonne si disponible, idéalement avant les premiers signes de compromission.
- Si la restauration n'est pas possible, effectuez un nettoyage avec des intervenants professionnels en cas d'incident.
Remédiation et renforcement à long terme
Au-delà des correctifs et de l'atténuation immédiate, mettez en œuvre ces contrôles pour réduire votre surface d'attaque future.
- Moindre privilège pour les utilisateurs
- Passez en revue les rôles et attribuez la capacité minimale nécessaire.
- Préférez le rôle d'Éditeur pour les rôles lourds en contenu et réduisez l'utilisation du rôle d'Administrateur.
- Renforcez la politique des plugins.
- Limitez le nombre de plugins et vérifiez les plugins avant l'installation.
- Tenez un registre des auteurs de plugins, de la cadence de mise à jour et de la réactivité du support.
- Patching et surveillance automatisés
- Utilisez des processus de mise à jour automatique contrôlés pour les mises à jour de sécurité critiques.
- Activez les notifications et la surveillance pour détecter les versions de plugins vulnérables dès leur publication.
- WAF et correctifs virtuels
- Déployez un WAF qui peut appliquer des correctifs virtuels compensatoires jusqu'à ce que la mise à jour logicielle soit appliquée.
- Configurez des règles pour bloquer les modèles d'exploitation et les demandes authentifiées suspectes provenant d'utilisateurs de bas niveau.
- Contrôle de l'intégrité des fichiers
- Utilisez des outils qui alertent lorsque des fichiers principaux, des plugins ou des fichiers de thème changent de manière inattendue.
- Configuration sécurisée du serveur
- Assurez-vous que PHP, le serveur web et les paquets OS sont à jour.
- Désactivez l'édition de fichiers PHP via des constantes (DISALLOW_FILE_EDIT, DISALLOW_FILE_MODS).
- Utilisez des droits de propriété et des permissions de fichier sécurisés.
- 2FA et gestion des sessions
- Appliquez l'authentification à deux facteurs pour tous les comptes admin/éditeur.
- Configurez les durées de session et révoquez les sessions lorsque des comportements suspects sont détectés.
- Plan de sauvegarde et de récupération
- Maintenez des sauvegardes hors site, versionnées.
- Testez régulièrement les restaurations et assurez-vous que les sauvegardes ne sont pas modifiables par des processus web.
- Sensibilisation à la sécurité et hygiène des comptes
- Éduquez les contributeurs sur le phishing et l'hygiène des identifiants.
- Évitez de partager des identifiants administratifs et utilisez plutôt des comptes à portée limitée.
- Audits de sécurité périodiques.
- Planifiez des examens de sécurité trimestriels des plugins, thèmes et codes personnalisés.
Comment WP‑Firewall aide à protéger votre site
En tant que fournisseur de sécurité WordPress, notre objectif est de réduire à la fois la fenêtre d'exposition et la probabilité d'exploitation réussie. Voici comment WP‑Firewall protège les sites contre des menaces telles que CVE-2026-7465 et des problèmes similaires d'escalade de privilèges basés sur des plugins.
- Pare-feu d'application Web géré (WAF)
- WP‑Firewall maintient un ensemble de règles qui peuvent bloquer des modèles d'exploitation connus, y compris des requêtes authentifiées suspectes qui tentent d'abuser des points de terminaison des plugins.
- Notre WAF peut être configuré pour traiter les requêtes de niveau contributeur avec une plus grande rigueur, en ajoutant des règles qui interdisent les actions à haut risque provenant de comptes à faible privilège.
- Patching virtuel / atténuation rapide
- Lorsqu'une nouvelle vulnérabilité critique est divulguée, WP‑Firewall peut déployer des patchs virtuels au niveau du WAF pour bloquer le trafic d'exploitation jusqu'à ce que vous puissiez mettre à jour le plugin en toute sécurité.
- Les patchs virtuels sont non invasifs et ne modifient pas le code du plugin, mais ils réduisent considérablement les taux de réussite des exploits.
- Scanner de malware et suppression (selon le plan)
- Notre scanner recherche des webshells, des scripts injectés et des modifications de fichiers suspectes résultant d'une élévation de privilèges.
- Pour les utilisateurs sur des plans éligibles, nous pouvons automatiquement supprimer les malwares identifiés et mettre en quarantaine les fichiers infectés.
- Protections conscientes des rôles
- WP‑Firewall peut mettre en œuvre des politiques qui restreignent certaines opérations pour les comptes de contributeur (par exemple, bloquer certains types de téléchargement de fichiers ou empêcher certaines actions POST).
- Cela réduit le risque provenant de comptes à faible privilège compromis.
- Surveillance de l'intégrité des fichiers et des modifications
- Des alertes sont générées lorsque des fichiers de plugin ou de thème sont modifiés de manière inattendue ; cela aide à détecter une tentative de persistance réussie après une exploitation.
- Protection de la connexion et gestion des sessions
- Nous fournissons un renforcement de la connexion : limites de taux, détection d'anomalies et application optionnelle de la 2FA pour prévenir le compromis de compte qui précède souvent l'escalade de privilèges.
- Analyse et reporting continus (Fonctionnalités Pro)
- Des rapports de sécurité mensuels, des alertes de vulnérabilité et un aperçu de la posture de risque aident les décideurs à garder à l'esprit l'état de sécurité du site.
- Assistance rapide en cas d'incident
- Notre manuel de réponse aux incidents comprend des étapes de confinement, des vérifications forensiques et des options de nettoyage en cas de violation du site.
Recommandations de configuration WP‑Firewall pour cette vulnérabilité
Si vous avez WP‑Firewall actif, appliquez ces paramètres ciblés pour réduire immédiatement le risque :
- Activez le WAF géré et assurez-vous que les mises à jour automatiques des règles sont actives.
- Activez le jeu de règles “Détection d'anomalies des utilisateurs authentifiés” (bloque les actions POST/PUT suspectes des rôles à faible privilège).
- Ajoutez une règle temporaire pour bloquer les requêtes POST/PUT/DELETE vers les points de terminaison spécifiques au plugin qui ont été ciblés par la vulnérabilité si vous ne pouvez pas mettre à jour immédiatement.
- Activez la surveillance des modifications de fichiers et définissez les alertes à haute sensibilité pour les répertoires de plugins et de thèmes.
- Appliquez des protections de connexion solides (limitation de taux, verrouillages après des tentatives échouées) et activez l'authentification multifactorielle optionnelle pour tous les comptes administrateurs/éditeurs.
- Si votre plan prend en charge la suppression automatique des logiciels malveillants ou le patching virtuel, activez ces fonctionnalités jusqu'à ce que le plugin soit corrigé.
Sécurisez votre site aujourd'hui — Commencez avec le plan gratuit WP‑Firewall
Si vous êtes préoccupé par cette vulnérabilité ou souhaitez protéger votre site de manière proactive, envisagez de commencer avec le plan de base (gratuit) de WP‑Firewall. Le plan gratuit offre une protection essentielle, y compris un pare-feu géré, une couverture WAF, une analyse des logiciels malveillants, une bande passante illimitée et une atténuation des risques OWASP Top 10 — toutes des couches utiles pour protéger les sites pendant que vous appliquez des mises à jour. La mise à niveau ultérieure est facile lorsque vous souhaitez une suppression automatique des logiciels malveillants, des listes d'autorisation/refus IP, des rapports mensuels et un patching virtuel.
En savoir plus et s'inscrire ici
(Pourquoi cela importe : un WAF géré et une analyse active comblent l'écart entre la divulgation de vulnérabilité et l'application de patch, réduisant le risque de compromission.)
Liste de contrôle de réponse aux incidents (étape par étape)
- Mettez le site en mode maintenance ou mettez-le hors ligne pour éviter d'autres dommages.
- Changez immédiatement tous les mots de passe des administrateurs et des éditeurs. Forcez les réinitialisations de mot de passe pour tous les utilisateurs.
- Désactivez le plugin vulnérable et supprimez-le s'il n'est pas nécessaire.
- Restaurez à partir d'une sauvegarde propre effectuée avant la compromission, si disponible.
- Exécutez une analyse complète des logiciels malveillants du serveur et du site (WP-Firewall/autres outils).
- Inspectez les journaux du serveur web pour des actions authentifiées suspectes et identifiez la chronologie des événements.
- Supprimez tout utilisateur admin non autorisé et désactivez l'enregistrement si ce n'est pas nécessaire.
- Vérifiez wp-content/uploads et d'autres chemins écriture pour des fichiers PHP ou des actifs suspects et supprimez-les.
- Révoquez toutes les clés API exposées, les jetons et faites tourner les identifiants.
- Corrigez le site : mettez à jour le plugin vers 2.19.26 ou une version ultérieure, mettez à jour le cœur de WordPress, les thèmes et d'autres plugins.
- Renforcez les permissions de fichiers et désactivez l'édition de fichiers.
- Réévaluez et documentez l'incident ; mettez en œuvre des mesures d'atténuation pour prévenir la récurrence.
- Si vous ne pouvez pas nettoyer le site en toute sécurité, recherchez des services de remédiation professionnels.
Indicateurs à surveiller dans les journaux (exemples)
- Requêtes POST vers des points de terminaison spécifiques au plugin à partir de comptes contributeurs.
- Requêtes POST/PUT inhabituelles vers wp-admin/admin-ajax.php ou des points de terminaison de l'API REST par des utilisateurs à faibles privilèges.
- Téléchargements de fichiers entraînant des fichiers PHP sous wp-content/uploads.
- Création de nouveaux utilisateurs avec des rôles admin/éditeur dans de courts délais.
Si vous avez une journalisation centralisée ou un SIEM, créez des alertes autour de ces modèles.
Foire aux questions
Q : La vulnérabilité permet-elle aux attaquants anonymes de prendre le contrôle de mon site ?
R : Non — le problème publié nécessite un utilisateur authentifié au niveau Contributeur ou supérieur. Cependant, les attaquants trouvent souvent des moyens d'obtenir des comptes contributeurs (par le biais de l'enregistrement, de la réutilisation des identifiants ou de la compromission de compte), donc le risque est réel.
Q : J'ai mis à jour le plugin — suis-je en sécurité maintenant ?
R : La mise à jour vers 2.19.26 ou une version ultérieure corrige la vulnérabilité dans le plugin. Après la mise à jour, exécutez une analyse de logiciels malveillants et examinez les journaux pour vous assurer qu'aucune compromission ne s'est produite avant le correctif. Si vous avez vu une activité suspecte avant la mise à jour, suivez la liste de contrôle de réponse à l'incident.
Q : Mon site n'utilise pas de contributeurs ; suis-je en sécurité ?
A : Si vous n'avez vraiment aucun contributeur ou compte à faible privilège équivalent et que l'enregistrement est désactivé, votre risque est plus faible. Mais les attaquants peuvent parfois obtenir des comptes par d'autres vecteurs ; gardez les plugins à jour et la surveillance active.
Q : Dois-je supprimer le plugin au lieu de le mettre à jour ?
A : Si vous n'avez pas besoin des fonctionnalités du plugin, le supprimer peut réduire la surface d'attaque. Si le plugin est essentiel, mettez-le à jour vers la version corrigée et renforcez le site.
Q : J'utilise un hébergeur géré. Vont-ils me protéger ?
A : De nombreux hébergeurs mettent en œuvre des protections, mais les capacités varient. Confirmez que votre hébergeur dispose d'un WAF, d'une détection d'intrusion et d'une politique de patching. Quoi qu'il en soit, vous devez toujours mettre à jour vers la version corrigée du plugin et suivre les étapes de durcissement.
Notes finales et liste de contrôle recommandée
Cette vulnérabilité est un exemple classique de la façon dont un compte à faible privilège peut devenir un point d'entrée initial pour un compromis sérieux. Le risque est élevé car les comptes de contributeurs sont courants, et les sites exploités peuvent être utilisés pour héberger des logiciels malveillants ou pivoter vers d'autres systèmes.
Actions immédiates recommandées :
- Mettez à jour le plugin Spectra vers 2.19.26 ou une version ultérieure.
- Si vous ne pouvez pas mettre à jour immédiatement, désactivez ou supprimez le plugin.
- Limitez ou suspendez les comptes de contributeurs jusqu'à ce que le site soit corrigé.
- Activez un WAF avec patching virtuel et analyse de logiciels malveillants (utilisateurs de WP‑Firewall : assurez-vous que le WAF géré et le patching virtuel sont actifs).
- Scannez les indicateurs de compromission et durcissez la configuration du serveur et de WordPress.
Si vous avez besoin de conseils ou souhaitez que nous examinions la configuration de votre site et votre posture de patching, WP‑Firewall propose à la fois une protection gratuite et des plans payants avec suppression automatique, patching virtuel, reporting et support en cas d'incident. Commencer avec le plan de base (gratuit) vous donnera une couverture immédiate de pare-feu géré et une analyse de logiciels malveillants pour réduire le risque pendant que vous corrigez — et à partir de là, vous pouvez passer à des capacités plus avancées si nécessaire.
Restez en sécurité : priorisez le patching, durcissez les rôles des utilisateurs et appliquez des défenses en couches — ces trois mesures ensemble arrêtent la plupart des attaquants opportunistes.
— Équipe de sécurité WP-Firewall
