Exécution de code à distance critique dans WooCommerce Listener//Publié le 2026-04-02//CVE-2025-15484

ÉQUIPE DE SÉCURITÉ WP-FIREWALL

WordPress Order Listener for WooCommerce Plugin Vulnerability

Nom du plugin Écouteur de commandes WordPress pour le plugin WooCommerce
Type de vulnérabilité Exécution de code à distance
Numéro CVE CVE-2025-15484
Urgence Haut
Date de publication du CVE 2026-04-02
URL source CVE-2025-15484

Exécution de code à distance (RCE) dans “Écouteur de commandes pour WooCommerce” — Ce que les propriétaires de magasins doivent faire maintenant

Date: 2 avril 2026
Gravité: Élevé (CVSS 7,5)
Versions concernées : Toutes les versions du plugin “Écouteur de commandes pour WooCommerce” / “Notification de commande WordPress pour WooCommerce” antérieures à 3.6.3
CVE : CVE-2025-15484
Crédit de divulgation : Khaled Alenazi (alias Nxploited)

Une vulnérabilité récemment divulguée dans le populaire plugin Écouteur de commandes pour WooCommerce peut être exploitée par des attaquants non authentifiés pour contourner les autorisations REST de WooCommerce et réaliser une exécution de code à distance (RCE). En termes simples : si vous utilisez ce plugin et que vous n'êtes pas patché, les attaquants peuvent exécuter des commandes à distance sur votre site—pouvant potentiellement obtenir un contrôle total.

Cet article explique la nature du bug, le risque dans le monde réel, comment détecter l'exploitation, les atténuations immédiates et à long terme que vous pouvez appliquer dès maintenant, et comment WP‑Firewall aide à protéger votre magasin pendant que vous mettez à jour.

Note pour les lecteurs : si vous gérez plusieurs magasins WooCommerce ou fournissez des services d'hébergement ou de développement, considérez cela comme urgent. La vulnérabilité est non authentifiée et facile à scanner ; les tentatives d'exploitation de masse sont courantes après une divulgation publique.


Résumé rapide pour les propriétaires de sites (TL;DR)

  • Quoi: Un contournement de permission non authentifié dans les points de terminaison REST du plugin qui peut être enchaîné à une exécution de code à distance.
  • Impact: Les attaquants peuvent exécuter du code arbitraire, télécharger des portes dérobées, pivoter vers d'autres sites sur le serveur, défigurer des magasins, voler des données ou miner des identifiants.
  • Affecté: Versions du plugin antérieures à 3.6.3.
  • Corrigé dans : Mettez à jour vers 3.6.3 (ou version ultérieure) dès que possible.
  • Si vous ne pouvez pas effectuer la mise à jour immédiatement : appliquez des règles WAF temporaires, bloquez les routes REST du plugin au niveau du serveur web, ou désactivez le plugin jusqu'à ce qu'il soit patché.
  • Action recommandée : Patch ASAP, scannez les indicateurs de compromission, renforcez l'exposition de l'API REST, et activez la protection WAF continue.

Ce qui s'est passé — cause racine technique (niveau élevé)

Le plugin expose un ou plusieurs points de terminaison API REST personnalisés pour intégrer les notifications de commande et les écouteurs avec des systèmes externes. La vulnérabilité est un contournement de permission/autorisation dans ces points de terminaison REST : le plugin ne vérifie pas correctement les capacités de l'appelant (authentification et autorisation) avant d'effectuer des actions sensibles. Comme les points de terminaison sont accessibles via l'API REST de WordPress, tout client non authentifié peut les appeler.

Une fois que l'attaquant peut interagir avec le point de terminaison sans vérifications de capacité appropriées, il peut fournir des charges utiles conçues que le plugin gère mal d'une manière qui conduit à une exécution de code côté serveur. La vulnérabilité est classée sous les faiblesses d'injection (OWASP A3 : Injection) et entraîne une exécution de code à distance—donnant essentiellement à un attaquant la capacité d'exécuter du code PHP arbitraire dans le contexte du site.

Parce que le plugin fonctionne avec les privilèges du serveur web/processus PHP et dans l'environnement WordPress, une exploitation réussie entraîne généralement l'attaquant à déposer une porte dérobée, créer un utilisateur Administrateur, exfiltrer des données ou exécuter d'autres activités malveillantes.


Pourquoi cela est particulièrement dangereux pour les boutiques WooCommerce

  • Les boutiques WooCommerce stockent souvent des données clients, des métadonnées de paiement et l'historique des commandes - des cibles attrayantes pour la collecte de données d'identification et la fraude.
  • La vulnérabilité est non authentifiée : les attaquants n'ont pas besoin de comptes WordPress valides.
  • Les points de terminaison REST sont faciles à découvrir et à énumérer (les scanners peuvent trouver rapidement l'espace de noms du plugin).
  • Les attaquants effectuent fréquemment des scans massifs et des campagnes d'exploitation massive après une divulgation publique.

Si vous exécutez le plugin et que votre site est accessible publiquement, supposez que vous êtes à risque jusqu'à ce que vous vérifiiez le contraire.


Indicateurs de compromission (ce qu'il faut rechercher)

Si vous soupçonnez que votre site a été ciblé ou si vous souhaitez vérifier de manière proactive, surveillez :

  • Des requêtes POST/PUT/DELETE augmentées ou répétées vers des routes REST liées au plugin, par exemple tout chemin sous :
    • /wp-json/woc-order-alert/
    • /wp-json//

    (le slug du plugin est souvent “woc-order-alert” - examinez les routes de votre site pour confirmer)

  • Des nouveaux utilisateurs WordPress inattendus avec des rôles d'Administrateur ou de gestionnaire de boutique
  • Des fichiers PHP modifiés ou nouvellement ajoutés dans wp-content/plugins, wp-content/uploads ou les répertoires de thèmes
  • Des entrées cron inhabituelles ou des tâches planifiées
  • Des connexions sortantes de votre site vers des IP ou des domaines inconnus peu après des appels REST
  • Des créations ou modifications de commandes inattendues dans WooCommerce (commandes que vous n'avez pas créées)
  • Des processus inconnus sur le serveur ou des pics d'utilisation du CPU / réseau
  • Des avertissements de liste noire de la part des moteurs de recherche ou de votre hébergeur

Vérifiez vos journaux d'accès et journaux d'erreurs pour des points de terminaison et des charges utiles suspects. Si vous trouvez l'un des éléments ci-dessus, considérez le site comme potentiellement compromis et suivez immédiatement un plan de réponse aux incidents.


Actions immédiates - correction et atténuations à court terme

  1. Mettez à jour le plugin immédiatement
    • Le fournisseur a publié la version 3.6.3 qui corrige le problème. Mettez à jour le plugin vers 3.6.3 ou une version ultérieure. Testez les mises à jour sur un environnement de staging si possible, puis déployez en production.
    • Si les mises à jour automatiques sont activées et fonctionnent, confirmez que le plugin a été mis à jour avec succès.
  2. Si vous ne pouvez pas mettre à jour immédiatement : désactivez le plugin
    • Désactivez le plugin depuis votre admin WordPress ou, si vous ne pouvez pas accéder à l'admin, renommez le dossier du plugin via SFTP/SSH (par exemple, renommez wp-content/plugins/woc-order-alert en woc-order-alert.disabled).
  3. Bloquez les points de terminaison REST du plugin au niveau du serveur web / WAF.
    • Si vous utilisez un pare-feu d'application web, appliquez une règle temporaire qui bloque l'accès à l'espace de noms REST du plugin jusqu'à ce que vous le mettiez à jour.
    • Si vous contrôlez le serveur, ajoutez une règle pour bloquer les requêtes vers le chemin REST du plugin (exemples ci-dessous).
  4. Faites tourner les identifiants et les secrets (si un compromis est suspecté).
    • Réinitialisez les mots de passe admin WordPress, les identifiants de base de données et toutes les clés API utilisées par le plugin.
    • Faites tourner tous les identifiants tiers utilisés dans les intégrations.
  5. Recherchez les signes de compromission
    • Effectuez un scan approfondi des malwares et un contrôle de l'intégrité des fichiers.
    • Vérifiez les fichiers inconnus dans les répertoires de plugins et de téléchargements et recherchez du code inattendu dans le thème et les mu-plugins.
  6. Informez votre hébergeur et les parties prenantes.
    • Si vous soupçonnez un compromis en direct, informez votre fournisseur d'hébergement et toutes les équipes impliquées afin qu'elles puissent aider à la containment.

Règles de serveur web que vous pouvez appliquer immédiatement.

Si vous ne pouvez pas appliquer une règle WAF de manière centrale, vous pouvez ajouter une règle de serveur web pour bloquer les routes REST du plugin. Remplacez les modèles d'espace de noms d'exemple par les points de terminaison réels observés sur votre site.

Exemple Nginx (interdire l'accès à un espace de noms REST de plugin) :

# Bloquer l'accès à l'espace de noms de point de terminaison REST du plugin pour les visiteurs non authentifiés

Exemple Apache (.htaccess) :

# Bloquer les points de terminaison REST du plugin

Remarque : Si des intégrations légitimes dépendent de ces points de terminaison, envisagez de limiter l'accès par IP au lieu d'un refus total (voir l'extrait suivant).

Exemple de liste blanche IP Nginx (autoriser uniquement certaines IP à appeler le point de terminaison) :

location ~ ^/wp-json/woc-order-alert/ {

Si vous utilisez l'authentification de base pour cette intégration, assurez-vous que les identifiants sont vérifiés côté serveur et changez-les après remédiation.


Atténuation programmatique temporaire à l'intérieur de WordPress

Si vous préférez désactiver les points de terminaison du plugin sans désactiver l'ensemble du plugin, utilisez un petit extrait dans un plugin spécifique au site ou dans le functions.php de votre thème (déployez d'abord dans un environnement de staging) :

<?php
add_filter( 'rest_endpoints', function( $endpoints ) {
    foreach ( $endpoints as $route => $handlers ) {
        // Adjust 'woc-order-alert' to the plugin's REST namespace if different
        if ( strpos( $route, '/woc-order-alert/' ) !== false ) {
            unset( $endpoints[ $route ] );
        }
    }
    return $endpoints;
} );
?>

Cela supprime les points de terminaison exposés du routeur REST. C'est une atténuation temporaire — assurez-vous de le supprimer une fois le plugin mis à jour et vérifié.


Étapes de durcissement à long terme pour les boutiques WooCommerce

  1. Gardez tout à jour
    • Core WordPress, WooCommerce, thèmes et plugins. Appliquez les correctifs rapidement, idéalement avec un processus de staging testé.
  2. Limiter l'exposition de l'API REST
    • N'exposez que les points de terminaison REST dont vous avez besoin. Utilisez l'authentification pour tous les points de terminaison qui effectuent des actions d'écriture.
    • Envisagez des jetons à courte durée de vie ou HMAC pour les points de terminaison d'intégration, et une limitation IP pour les partenaires de confiance.
  3. Principe du moindre privilège
    • Assurez-vous que les plugins n'exécutent que les capacités nécessaires. Examinez le code du plugin (ou un examinateur de sécurité) pour les points de terminaison qui effectuent des actions privilégiées.
  4. Utilisez un WAF géré avec un patch virtuel
    • Un WAF peut bloquer les tentatives d'exploitation pour les vulnérabilités connues même avant que vous ne mettiez à jour (patching virtuel), vous donnant du temps pour tester et déployer des correctifs.
  5. Surveillez les journaux et définissez des alertes
    • Surveillez les journaux d'accès pour des appels REST suspects et un trafic POST non autorisé.
    • Configurez des alertes pour les changements dans les fichiers de base, de plugin, les nouveaux utilisateurs administrateurs et les fichiers .htaccess modifiés.
  6. Vérifications d'intégrité et sauvegardes de routine
    • Maintenez des sauvegardes régulières hors site et testez les procédures de restauration.
    • Utilisez la surveillance de l'intégrité des fichiers pour détecter rapidement les modifications non autorisées.
  7. Évaluer et limiter les plugins
    • N'installez que des plugins provenant de sources fiables. Supprimez les plugins que vous n'utilisez pas activement.
    • Pour les fonctions commerciales critiques, privilégiez les plugins qui ont une maintenance de sécurité active et un historique de réponse rapide.

Liste de contrôle de détection et de récupération (si vous avez été exploité)

Si vous trouvez des signes de compromission, suivez un flux de travail de réponse aux incidents — rapidement, mais méthodiquement :

  1. Contenir
    • Mettez le site hors ligne ou activez un mode de maintenance si nécessaire.
    • Désactivez immédiatement le plugin vulnérable.
    • Supprimez l'exposition du serveur web aux points de terminaison du plugin.
  2. Préserver les preuves
    • Sauvegardez les journaux, les fichiers modifiés et les instantanés de la base de données pour un examen judiciaire.
  3. Identifier le périmètre
    • Recherchez de nouveaux utilisateurs administrateurs, des thèmes/plugins modifiés, des fichiers inconnus, des tâches planifiées suspectes et un trafic sortant inhabituel.
  4. Éradiquer
    • Supprimez les logiciels malveillants et les portes dérobées. Idéalement, utilisez des sauvegardes connues et saines d'avant la compromission.
    • Remplacez toutes les informations d'identification compromises (WordPress, base de données, clés API).
  5. Restaurer et durcir
    • Restaurez à partir d'une sauvegarde propre ou après une remédiation complète.
    • Appliquez la mise à jour du plugin (3.6.3 ou ultérieure).
    • Mettez en œuvre les protections WAF et les étapes de durcissement ci-dessus.
  6. Notifier
    • Si des données personnelles ont pu être exposées, suivez les réglementations de notification de violation applicables et informez les utilisateurs concernés de manière appropriée.
  7. Examen post-incident
    • Effectuez une analyse des causes profondes, corrigez les problèmes connexes et améliorez les défenses et les processus pour réduire la probabilité de récurrence.

Comment un pare-feu géré (comme WP‑Firewall) protège votre boutique pendant les incidents

Lorsqu'une vulnérabilité comme celle-ci est divulguée, vous avez deux options : corriger immédiatement ou mettre en place des protections pendant que vous préparez et testez les mises à jour. Un pare-feu d'application web géré offre plusieurs avantages :

  • Patching virtuel : Les WAF peuvent bloquer le trafic d'exploitation ciblant des points de terminaison vulnérables connus en temps réel. Cela empêche les attaques même lorsqu'un correctif n'est pas encore appliqué.
  • Détection basée sur des signatures et des comportements : Le pare-feu utilise des modèles et des heuristiques comportementales pour identifier les tentatives d'exploitation, les charges utiles POST malveillantes et les comportements de scan.
  • Limitation de taux et protection contre les bots : Bloque les tentatives de scan de masse et d'exploitation automatisées qui précèdent ou accompagnent souvent les tentatives RCE.
  • Déploiement de règles personnalisées : Nous pouvons créer des règles qui bloquent spécifiquement les demandes vers l'espace de noms REST du plugin, bloquent les agents utilisateurs suspects ou refusent les charges utiles suspectes.
  • Surveillance et alertes : Recevez des alertes instantanées dès qu'un trafic semblable à une exploitation est détecté afin que vous puissiez agir rapidement.
  • Tests sûrs et retour en arrière : Les règles peuvent être activées et ajustées afin de ne pas perturber les intégrations légitimes ; nous fournissons des fenêtres de test pour vérifier la compatibilité.

Si vous ne pouvez pas mettre à jour chaque instance immédiatement (courant pour les agences et les fournisseurs d'hébergement avec de nombreux sites WordPress), le patching virtuel via un WAF géré est une mesure de réduction des risques pratique et immédiate qui vous donne du temps pour planifier la maintenance.


Exemples de règles WAF pratiques (non exhaustif, à ajuster)

Ci-dessous des exemples des types de règles qu'un WAF pourrait déployer. Ce sont des formes de règles conceptuelles de haut niveau—votre équipe de pare-feu géré devrait les ajuster pour votre environnement et éviter les faux positifs.

  • Bloquer les requêtes REST anonymes vers l'espace de noms du plugin :
    • Condition : méthode HTTP IN (POST, PUT, DELETE) ET l'URL correspond à ^/wp-json/woc-order-alert/ ET pas de cookie d'authentification WP valide
    • Action : BLOQUER (403)
  • Bloquez les modèles de charge utile suspects :
    • Condition : Le corps de la requête contient des balises PHP excessives, des chaînes longues encodées en base64, ou des signatures de webshell courantes
    • Action : BLOQUER et ENREGISTRER
  • Limiter le taux des appels REST d'une seule IP à des seuils agressifs :
    • Condition : > 20 requêtes REST / minute vers /wp-json/* depuis la même IP
    • Action : Limiter le taux / défi / bloquer

Rappelez-vous : les règles de blocage doivent être testées contre des intégrations légitimes avant d'être appliquées. Un pare-feu géré peut appliquer des règles de protection en mode “ surveillance ” d'abord pour repérer les faux positifs.


Exemples de détections exploitables pour révision des journaux

Recherchez dans vos journaux :

  • Requêtes vers /wp-json/ contenant l'espace de noms du plugin :
    • Exemple regex : /wp-json/(woc-order-alert|order-alert|woc_order_alert)/
  • Tentatives POST répétées d'une seule IP dans un court laps de temps
  • Types de contenu inattendus dans les appels REST (par exemple, text/plain là où application/json est attendu)
  • POST avec des paramètres anormalement longs ou de nombreux caractères encodés (courant avec les tentatives d'injection)

Si vous utilisez un SIEM ou une agrégation de journaux, définissez des alertes pour ces modèles.


Une méthode sécurisée pour les développeurs pour renforcer les points de terminaison personnalisés

Si vous développez des intégrations qui nécessitent des points de terminaison REST personnalisés, assurez-vous de :

  • Utiliser une authentification appropriée (OAuth, mots de passe d'application ou JWT)
  • Appliquer des vérifications de capacité côté serveur en utilisant des fonctions WordPress comme current_user_can (pour les points de terminaison authentifiés) ou une vérification de jeton personnalisée robuste (pour les flux non authentifiés mais autorisés)
  • Nettoyer et valider toutes les entrées — ne jamais eval() les chaînes fournies par l'utilisateur, ne jamais écrire de fichiers PHP sur le disque sans vérification
  • Limiter la portée des actions que le point de terminaison peut effectuer — préférer mettre en file d'attente le travail pour des tâches en arrière-plan plutôt que d'effectuer des tâches sensibles dans le gestionnaire de requêtes

Exemple de vérification de capacité pour un point de terminaison authentifié :

<?php

Si vous devez exposer un point de terminaison pour des systèmes tiers, envisagez le TLS mutuel, la liste blanche d'IP statiques ou les requêtes signées.


Modèles de réponse aux incidents et journaux à préserver

Lors de l'enquête, capturez :

  • Journaux complets du serveur web pour les 30 derniers jours
  • Journaux d'accès et d'erreurs WordPress
  • Dumps de base de données (lecture seule) à des fins d'analyse judiciaire
  • Instantanés du système de fichiers (listant tous les temps de modification des fichiers)
  • Listes de processus actifs et journaux de connexions sortantes (si disponibles)

Préserver les preuves aidera à identifier l'origine de l'attaque, son ampleur et l'activité post-exploitation.


Pourquoi cette vulnérabilité devrait motiver des améliorations de processus

Cet incident met en évidence des thèmes récurrents dans la sécurité de WordPress :

  • Les points de terminaison REST sont puissants et doivent être traités comme des interfaces publiques.
  • Les auteurs de plugins doivent valider les autorisations et assainir les entrées pour toute action pouvant modifier l'état du site ou des fichiers.
  • Les cycles de correctifs et les délais de divulgation responsable sont importants. En tant qu'administrateur de site, vous devez être prêt à réagir rapidement.
  • Pour les agences et les hébergeurs gérant de nombreux sites, des contrôles d'application centralisés (WAF, correctifs automatisés, surveillance des vulnérabilités) sont essentiels.

Utilisez cet événement pour tester vos flux de travail de mise à jour et de réponse aux incidents. Le temps de correction est souvent la différence entre une tentative bloquée et un compromis total.


Livre de jeu de récupération suggéré par WP‑Firewall (concis)

Si vous êtes un client de WP‑Firewall ou si vous prévoyez d'utiliser nos services, voici notre livre de jeu étape par étape suggéré après la découverte ou la publication d'un correctif :

  1. Confirmez la version du plugin sur tous les sites (inventaire).
  2. Priorisez les magasins à fort trafic et orientés vers les clients pour une mise à jour immédiate.
  3. Si la mise à jour immédiate est impossible, activez les règles de correctifs virtuels pour bloquer l'espace de noms REST du plugin et les charges utiles suspectes.
  4. Effectuez une analyse complète des logiciels malveillants et de l'intégrité des fichiers ; mettez en quarantaine les fichiers suspects.
  5. Faites tourner les identifiants d'administrateur et d'intégration.
  6. Restaurez à partir de sauvegardes vérifiées si nécessaire.
  7. Passez à l'amélioration post-incident : mises à jour automatiques programmées pour les plugins non perturbateurs, surveillance continue et examens de sécurité périodiques.

Notre service géré peut automatiser bon nombre de ces étapes sur des flottes de sites afin que vous ne perdiez pas des heures site par site.


Protection immédiate disponible — Commencez avec le plan gratuit de WP‑Firewall

Si vous jonglez avec plusieurs mises à jour, n'avez pas le temps pour une remédiation complète en ce moment, ou souhaitez ajouter une autre couche de protection pendant que vous appliquez des correctifs : WP‑Firewall propose un plan gratuit toujours actif qui inclut des protections essentielles pour les magasins WordPress. Le niveau de base (gratuit) vous offre un pare-feu géré, un WAF de couche applicative, une analyse des logiciels malveillants, une bande passante illimitée et une atténuation des risques OWASP Top 10—précisément le type de couverture qui aide à stopper les tentatives RCE basées sur REST non authentifiées pendant que vous appliquez les correctifs du fournisseur. Inscrivez-vous au plan gratuit ici et activez rapidement la protection de base : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Points forts du plan :

  • Basique (gratuit) : Pare-feu géré, WAF, analyseur de logiciels malveillants, bande passante illimitée, protection contre les risques OWASP Top 10.
  • Standard : Toutes les fonctionnalités de base + suppression automatique des logiciels malveillants et possibilité de mettre sur liste noire/liste blanche jusqu'à 20 adresses IP.
  • Pro : Toutes les fonctionnalités standard + rapports de sécurité mensuels, correctifs virtuels automatiques pour les vulnérabilités, et modules complémentaires premium comme un gestionnaire de compte dédié et des services de sécurité gérés.

Si vous souhaitez un correctif virtuel immédiat et des règles ajustées pour cette vulnérabilité de plugin spécifique, notre équipe peut fournir une assistance et déployer des protections pendant que vous mettez à jour.


Liste de contrôle finale — que faire dès maintenant.

  • ☐ Vérifiez si le plugin “Order Listener for WooCommerce” / “WordPress Order Notification for WooCommerce” est installé.
  • ☐ S'il est installé, mettez à jour vers la version 3.6.3 ou ultérieure immédiatement.
  • ☐ Si vous ne pouvez pas mettre à jour, désactivez temporairement le plugin ou appliquez des règles de serveur web/WAF pour bloquer les points de terminaison REST du plugin.
  • ☐ Scannez votre site à la recherche d'indicateurs de compromission (nouveaux utilisateurs administrateurs, fichiers inconnus, fichiers de base/plugin modifiés).
  • ☐ Faites tourner les identifiants et sécurisez les clés d'intégration.
  • ☐ Activez la surveillance continue et envisagez un WAF géré avec un patch virtuel jusqu'à ce que vous soyez sûr que tous les sites sont mis à jour et propres.
  • ☐ En cas de compromission, suivez les étapes de confinement → préservation → éradication → récupération et travaillez avec votre hébergeur/fournisseur de sécurité pour restaurer un état propre.

Réflexions finales d'un praticien de la sécurité WordPress

J'ai vu trop d'incidents où une simple erreur de vérification des autorisations dans un plugin entraîne des heures ou des jours de travail de récupération. La meilleure défense est une combinaison de patchs rapides, de protections WAF proactives (le patch virtuel achète du temps) et d'opérations disciplinées : inventaire, sauvegardes et surveillance.

Si vous gérez ou hébergez des boutiques WooCommerce, priorisez cette vulnérabilité immédiatement. Le patch vers 3.6.3 est le bon premier pas ; un scan complet et un durcissement sont ce qui vous garde en sécurité à long terme. Si vous avez besoin d'aide pour évaluer votre exposition, déployer des atténuations temporaires ou mettre en place une protection continue sur de nombreux sites, WP‑Firewall offre à la fois des outils automatisés et une assistance experte pour réduire les risques et restaurer rapidement la confiance.

Restez en sécurité et agissez maintenant—les attaquants n'attendent pas.


wordpress security update banner

Recevez gratuitement WP Security Weekly 👋
S'inscrire maintenant
!!

Inscrivez-vous pour recevoir la mise à jour de sécurité WordPress dans votre boîte de réception, chaque semaine.

Nous ne spammons pas ! Lisez notre politique de confidentialité pour plus d'informations.