Nom du plugin	@libp2p/kad-dht
Type de vulnérabilité	Avis de sécurité
Numéro CVE	CVE-2026-45783
Urgence	Haut
Date de publication du CVE	2026-05-20
URL source	CVE-2026-45783

PUT_VALUE non validé dans @libp2p/kad-dht (CVE-2026-45783) : Ce que les propriétaires de sites WordPress doivent savoir et comment protéger vos sites

Résumé: Une vulnérabilité de haute priorité (CVE-2026-45783 / GHSA-32mq-hpph-xfvr) a été publiée pour le package npm @libp2p/kad-dht (corrigé dans 16.2.6). Le problème permet de stocker des enregistrements PUT_VALUE non validés sans limites sur les nœuds de serveur DHT, ce qui peut épuiser l'espace disque et provoquer des dénis de service ou faciliter des abus persistants sur les hôtes Node.js affectés. Bien qu'il s'agisse d'une vulnérabilité de l'écosystème Node, les propriétaires et administrateurs de sites WordPress devraient prêter attention — l'écosystème WordPress moderne chevauche fréquemment les outils Node.js, les architectures sans tête, les pipelines de construction et les microservices empaquetés qui peuvent utiliser libp2p. Cet article explique la vulnérabilité, l'impact dans le monde réel pour les environnements WordPress, les étapes de détection, les atténuations (y compris les protections immédiates basées sur WAF), la réponse aux incidents et le durcissement à long terme.

---

TL;DR — Actions rapides

• Vulnérabilité : Les enregistrements PUT_VALUE non validés peuvent provoquer une exhaustion de disque illimitée sur les nœuds de serveur DHT dans les versions @libp2p/kad-dht < 16.2.6. CVE-2026-45783, CVSS 7.5.
• Atténuation immédiate : Mettez à jour @libp2p/kad-dht vers 16.2.6 ou une version ultérieure partout où il est utilisé. Reconstruisez et redéployez les services basés sur Node et les artefacts CI.
• Si vous ne pouvez pas mettre à jour immédiatement : bloquez ou restreignez l'accès réseau aux processus Node exposant des points de terminaison DHT ; appliquez des règles WAF pour bloquer le trafic DHT suspect ; imposez des quotas de disque pour les processus et des limites de débit.
• Spécifique à WordPress : Auditez les plugins/thèmes et l'hébergement pour les services Node empaquetés, les front-ends sans tête, les runners CI et les machines de développement avec des services activés DHT ; scannez le package dans votre code source et vos artefacts.
• Utilisez des défenses en couches : quotas de disque au niveau de l'hôte, conteneurisation, WAF/IDS, pratiques CI/CD sécurisées et surveillance des dépendances.

---

La vulnérabilité en termes simples

libp2p est une pile de mise en réseau modulaire utilisée pour construire des applications pair-à-pair. Le module kad-dht implémente une table de hachage distribuée de style Kademlia (DHT) qui prend en charge les opérations PUT_VALUE — écriture d'enregistrements clé-valeur dans le DHT.

CVE-2026-45783 décrit un échec à valider correctement les enregistrements PUT_VALUE sur les nœuds de serveur DHT. Les attaquants peuvent envoyer de nombreuses ou très grandes requêtes PUT_VALUE que le serveur acceptera et persistera sans validation appropriée de la taille, du nombre ou de l'origine. Comme le stockage de ces enregistrements est illimité, un attaquant peut provoquer une exhaustion de disque : le processus continue d'écrire des enregistrements jusqu'à ce que le disque soit plein, entraînant un déni de service ou d'autres corruptions sur l'hôte.

Points clés :

• Nécessite un accès réseau à un nœud DHT (aucune authentification préalable requise).
• Faible complexité pour exploiter à grande échelle — des scripts automatisés peuvent inonder le nœud.
• Impacte les processus Node.js exécutant des versions vulnérables de @libp2p/kad-dht (< 16.2.6).
• Version corrigée : 16.2.6.

---

Pourquoi les propriétaires de sites WordPress devraient s'en soucier

À première vue, cela ressemble à un problème uniquement lié à Node et sans rapport avec WordPress (PHP). Mais l'écosystème WordPress a de nombreux points de contact avec Node :

• Outils de construction et pipelines d'actifs : Les thèmes et plugins incluent souvent des étapes de construction JS (webpack, vite) dans le processus de développement. Les systèmes CI ou les machines de développement exécutant Node peuvent inclure des dépendances vulnérables.
• Architectures sans tête et hybrides : De nombreux sites WordPress modernes utilisent des front-ends sans tête (React/Vue) qui exécutent des serveurs Node ou des microservices qui pourraient inclure libp2p pour des fonctionnalités P2P ou des expériences.
• Microservices groupés : Les plugins ou les fournisseurs d'hébergement expédient ou exécutent parfois des microservices basés sur Node pour des fonctionnalités en temps réel, le traitement d'images ou des intégrations ; ceux-ci pourraient utiliser des modules npm vulnérables.
• Stations de travail des développeurs et exécuteurs CI : Si vos développeurs utilisent la bibliothèque vulnérable dans des environnements locaux ou CI connectés à des réseaux de production, l'exploitation ou l'épuisement des ressources pourrait déborder sur l'infrastructure partagée (par exemple, des exécuteurs CI partagés, un staging hébergé par des développeurs).
• Hébergement géré et composants de plateforme : Certains hébergeurs exécutent des services basés sur Node pour la mise en cache, le proxy ou l'analyse ; l'épuisement là-bas peut perturber les sites WordPress hébergés sur la même infrastructure.

En résumé : même si le code de votre site WordPress est purement PHP, la disponibilité et l'intégrité des données de votre site peuvent dépendre des processus Node dans l'ensemble de la pile d'hébergement.

---

Scénarios d'exploitation pertinents pour les environnements WordPress

1. Environnement d'hébergement partagé
   – Un hébergeur exécute un service basé sur Node pour de nombreux clients (par exemple, un service d'analyse en temps réel ou un service de synchronisation P2P utilisant libp2p).
   – Un attaquant inonde ce service avec des enregistrements PUT_VALUE provoquant un épuisement du disque.
   – Le disque de l'hébergeur se remplit et d'autres locataires (y compris des sites WordPress) subissent des pannes.
2. Microservice Node groupé avec un plugin ou un thème
   – Un plugin regroupe un service Node auxiliaire (par exemple, pour l'optimisation d'images, le chat en temps réel ou le pont websocket).
   – Le microservice utilise @libp2p/kad-dht <16.2.6.
   – L'attaquant déclenche des écritures illimitées vers ce service, provoquant l'épuisement du disque ou le plantage du conteneur ou de la VM sous-jacente.
3. Outils CI/CD ou de développement
   – Un exécuteur CI ou une machine de développeur exposée à Internet (ou accessible via des identifiants compromis) exécute un nœud DHT.
   – Le disque se remplit et les artefacts de construction sont perdus ; les pipelines de déploiement continu échouent et les déploiements en production sont bloqués.
4. Frontends sans tête et proxys
   – Un frontend WordPress sans tête s'appuie sur un serveur Node pour le SSR ou la synchronisation des données.
   – Le serveur Node est attaqué et désactivé, rendant le frontend indisponible bien que le backend WordPress reste.
5. Mouvement latéral et persistance
   – L'épuisement du disque peut être utilisé comme une diversion ou pour corrompre les journaux/la surveillance, aidant d'autres attaques contre les composants WordPress.

---

Comment savoir si vous êtes affecté

Étape 1 — Recherchez dans votre code source et vos artefacts

• Recherchez le package dans les fichiers de dépôt et les fichiers de verrouillage :
  • grep -R "@libp2p/kad-dht" .
  • npm ls @libp2p/kad-dht || true
  • yarn why @libp2p/kad-dht || true
• Inspectez package-lock.json / yarn.lock pour les versions < 16.2.6.

Étape 2 — Inspectez les déploiements et les conteneurs

• Vérifiez les processus en cours sur les serveurs pour les processus Node qui pourraient être des nœuds DHT :
  • ps aux | grep node
  • lsof -nP -iTCP -sTCP:LISTEN | grep node
  • ss -plnt
• Pour les conteneurs, listez les images et inspectez :
  • docker ps --format '{{.ID}} {{.Image}}' && docker inspect | grep -i libp2p -R

Étape 3 — CI/CD et machines des développeurs

• Demandez aux développeurs si les serveurs de tests/construction utilisent libp2p ou kad-dht.
• Scannez les images des runners CI, les artefacts préconstruits ou les caches pour le package.

Étape 4 — Fournisseur d'hébergement / services gérés

• Contactez votre hébergeur pour vérifier si des services Node gérés ou des composants de plateforme utilisent la bibliothèque vulnérable.

Étape 5 — Journaux et télémétrie

• Recherchez des pics dans les écritures sur disque, une croissance de fichiers inhabituelle dans les emplacements de stockage DHT, des erreurs indiquant “plus d'espace disponible sur le périphérique” ou des plantages d'application soudains.
• Alertes à surveiller : utilisation du système de fichiers >85%, entrées répétées PUT_VALUE ou écritures DHT dans les journaux d'application Node, augmentation soudaine du trafic réseau vers les processus Node.

---

Atténuation immédiate — mise à jour et reconstruction (recommandé)

1. Mise à jour
   – Partout où @libp2p/kad-dht est utilisé, mettez à jour vers la version 16.2.6 ou ultérieure.
   – Exécutez :
   • npm install @libp2p/kad-dht@^16.2.6
   • npm mettre à jour

   – Pour les dépendances transitives, mettez à jour le package parent ou exécutez npm dedupe et reconstruisez les fichiers de verrouillage.

2. Reconstruire les artefacts
   – Reconstruisez et redéployez tous les bundles frontend, images Docker et artefacts serveur qui incluent des modules Node.
   – Remplacez les images dans les registres et redéployez les Pods ou conteneurs Kubernetes.
3. Redémarrer les services
   – Redémarrez les services Node après la mise à jour pour vous assurer que la version corrigée est chargée.
4. Confirmer
   – npm ls @libp2p/kad-dht devrait afficher 16.2.6 ou ultérieure.
   – Vérifiez que les processus en cours d'exécution utilisent les artefacts mis à jour.

---

Si vous ne pouvez pas mettre à jour immédiatement — atténuations temporaires

Contrôles d'accès réseau

• Isolez les nœuds DHT : restreignez le trafic entrant aux pairs connus en utilisant le pare-feu de l'hôte (iptables/nft) ou les groupes de sécurité cloud.
• Refuser l'accès externe : bloquez les ports/protocoles utilisés par votre nœud DHT Node depuis Internet public.
• Utilisez des ACL réseau pour empêcher les pairs non fiables de se connecter.

WAF / protections au niveau de l'application

• Implémentez des règles WAF pour détecter et bloquer les requêtes DHT PUT suspectes. Bien qu'un DHT utilise des trames libp2p (pas du HTTP classique), si votre environnement proxy ou expose des points de terminaison HTTP ou des ports personnalisés pour Node, vous pouvez bloquer les requêtes qui correspondent aux indicateurs de protocole DHT ou à des tailles/modèles anormaux.
• Limitez le taux de connexions des pairs externes aux processus Node.

Atténuations au niveau du processus et du système d'exploitation

• Appliquez des quotas de disque par processus (cgroups, systemd ou quotas de stockage de conteneurs) pour empêcher un seul processus de consommer tout l'espace disque.
• Exécutez les services Node dans des conteneurs avec un stockage écrivable limité. Utilisez des couches d'image en lecture seule et des volumes éphémères écrivables séparés avec des limites de taille.
• Utilisez tmpfs ou de petits volumes dédiés pour tout stockage temporaire utilisé par le DHT afin de limiter les dommages.

Surveillance et alerte précoce

• Configurez des alertes pour une utilisation anormale du disque et une augmentation soudaine des écritures I/O.
• Surveillez le nombre d'opérations PUT si votre application Node expose des métriques (Prometheus, etc.).

Exemple : blocage iptables de base (remplacez et selon le besoin)

# Bloquer l'accès externe à un port DHT Node

Exemple : limites de cgroup systemd (extrait d'unité de service)

[Service]

Ce sont des mesures temporaires — la véritable solution est de patcher.

---

Signatures WAF suggérées et détections comportementales

Parce que le trafic DHT libp2p est non-HTTP dans de nombreux cas, la détection directe de signatures WAF peut être limitée à moins que le service Node n'expose des points de terminaison HTTP. Néanmoins, au sein de l'environnement d'hébergement et dans les couches de proxy, vous pouvez :

• Bloquer les charges utiles de requêtes exceptionnellement grandes vers tout point de terminaison associé aux services Node.
• Détecter et bloquer les connexions à haute fréquence provenant de la même IP distante ou ASN ciblant les ports DHT.
• Faire correspondre des modèles de poignée de main libp2p connus s'ils sont proxyés via HTTP ou si les journaux incluent de tels modèles (par exemple, multiaddr, chaînes “kad-dht”).
• Surveillez la croissance soudaine de répertoires de stockage spécifiques utilisés par le service Node (règle au niveau de l'application pour bloquer les demandes lorsque le seuil d'utilisation du disque est dépassé).

Exemple de pseudo-règle de style ModSecurity pour bloquer les écritures trop volumineuses (si le service Node est derrière un proxy HTTP) :

SecRequestBodyLimit 131072"

Remarque : adaptez les limites aux modèles de trafic normaux pour éviter les faux positifs.

---

Guide pour les développeurs — comment corriger le code utilisant libp2p/kad-dht

Si vous maintenez un code qui appelle PUT_VALUE ou stocke des enregistrements DHT, appliquez les meilleures pratiques suivantes :

• Validez la taille de l'enregistrement : rejetez ou tronquez les valeurs dépassant un maximum sûr (par exemple, 64 Ko ou une taille déterminée par votre capacité de stockage).
• Limitez le nombre d'enregistrements par clé et par pair.
• Appliquez une expiration (TTL) et un ramassage des ordures des anciens enregistrements.
• Authentifiez et autorisez les écritures si possible — exigez que les pairs prouvent leur légitimité avant d'accepter des écritures persistantes.
• Limitez le taux des opérations d'écriture par IP de pair ou par ID de pair.
• Utilisez un stockage adressable par contenu (par exemple, CID) et ne conservez les charges utiles que si elles correspondent aux formats autorisés.
• Implémentez des vérifications de taille et de quota avant les écritures sur disque et gérez gracieusement le “disque plein” (échouer en mode fermé).

Exemple de modèle de pseudo-code Node :

async function safePutValue(store, key, value, peerId) {

---

Détection et réponse — un manuel de gestion des incidents

1. Isoler
   • Retirez immédiatement le processus Node de l'exposition au réseau externe (règles iptables, arrêter le service, supprimer la route publique).
   • Mettez en quarantaine le conteneur/VM affecté pour prévenir les mouvements latéraux.
2. Préserver les preuves
   • Sauvegardez les journaux (journaux de l'application Node, journaux système, captures réseau).
   • Prenez des instantanés des disques (si possible) pour une analyse hors ligne.
3. Arrêtez les écritures
   • Arrêtez ou mettez en pause le processus Node problématique.
   • Désactivez tous les ports exposés au DHT et rétablissez les règles de pare-feu.
4. Analyser
   • Recherchez dans les journaux de grandes quantités d'écritures de type PUT_VALUE ou des écritures répétitives provenant des mêmes pairs.
   • Identifiez le répertoire utilisé pour stocker les enregistrements DHT et énumérez les fichiers suspects.
5. Nettoyez
   • Supprimez les enregistrements malveillants ou de taille excessive.
   • Récupérez l'espace disque avec précaution ; assurez-vous de ne pas supprimer de données légitimes.
   • Reconstruisez et redéployez les processus Node après avoir appliqué les correctifs.
6. Corrigez et renforcez
   • Mettez à jour @libp2p/kad-dht vers 16.2.6+.
   • Reconstruisez et redéployez les artefacts d'un CI de confiance avec de nouveaux fichiers de verrouillage.
   • Appliquez des quotas et des restrictions réseau.
7. Actions post-incident
   • Faites tourner les clés / identifiants s'il y a des indications de compromission au-delà de l'épuisement des ressources.
   • Mettez à jour les journaux d'incidents et l'analyse des causes profondes.
   • Communiquez avec les parties prenantes et, le cas échéant, votre fournisseur d'hébergement.

---

Indicateurs d'analyse judiciaire à rechercher

• Croissance anormalement rapide des fichiers dans les répertoires de stockage du service Node.
• Nombre élevé d'opérations PUT ou d'écritures dans les journaux d'application Node.
• Multiples connexions provenant de nombreux IP éphémères ciblant le processus Node.
• Entrées de journal système : “plus d'espace disponible sur le périphérique”, boucles de plantage/redémarrage pour les processus Node.
• Forte utilisation du disque i/o et du CPU par les processus Node.
• Présence de nombreuses clés/enregistrements randomisés dans le magasin DHT (par exemple, beaucoup de clés uniques avec de grandes charges utiles).

Collectez ces artefacts pour votre rapport d'incident et votre analyse judiciaire.

---

Comment tester votre environnement

• Utilisez npm audit / snyk / d'autres scanners de dépendances pour identifier l'utilisation et les versions de @libp2p/kad-dht.
• Simulez localement une attaque (dans un laboratoire contrôlé) pour vérifier les atténuations — lancez un serveur DHT Node de test et tentez d'envoyer des charges utiles PUT_VALUE surdimensionnées. Surveillez les quotas et les règles WAF.
• Testez les règles WAF et les limites de taux pour les faux positifs avant de les activer à grande échelle.
• Exécutez des tests d'intégration pour les pipelines de construction afin de garantir que les mises à jour de dépendances ne cassent pas les artefacts de production.

Liste de contrôle des commandes :

• npm ls @libp2p/kad-dht
• grep -R "@libp2p/kad-dht" .
• find / -type d -name "node_modules" -exec grep -H "@libp2p/kad-dht" {} \;
• Vérifiez les images de conteneurs : docker run --rm sh -c 'npm ls @libp2p/kad-dht || true'

---

Réduction des risques à long terme et recommandations pour une architecture sécurisée

• Moindre privilège et segmentation du réseau : gardez les microservices Node isolés des réseaux publics et des processus PHP WordPress sauf si explicitement nécessaire.
• Infrastructure immuable : reconstruisez et redéployez des images avec des dépendances corrigées plutôt que de corriger sur place.
• Renforcement du pipeline CI : scannez et rejetez les constructions qui incluent des dépendances connues comme vulnérables ; signez et vérifiez les artefacts.
• Hygiène des dépendances : préférez les versions figées et les mises à jour contrôlées ; utilisez des outils qui alertent sur les avis nouvellement publiés.
• Quotas de ressources : appliquez des limites cgroup/conteneur pour les écritures et le stockage par service.
• Observabilité : instrumentez les services Node avec des métriques pour les opérations DHT (écritures/lectures), l'utilisation du disque par service, et des alertes pour une activité inhabituelle.
• Gestion des fournisseurs et des tiers : exigez des auteurs de plugins/thèmes tiers qu'ils déclarent et mettent à jour les dépendances Node s'ils expédient des services Node.

---

Foire aux questions

Q : Mon site WordPress est purement PHP et fonctionne sur Apache/Nginx sans processus Node. Suis-je en sécurité ?
A : S'il n'y a pas de processus Node, vous n'êtes pas directement affecté. Cependant, vérifiez si votre hébergeur, CDN ou fournisseur de plugin exécute des services Node en votre nom. Confirmez également que les artefacts de construction (modules Node regroupés) ne sont pas exécutés sur vos serveurs de production.

Q : J'utilise un plugin qui dit qu'il “regroupe un helper Node”. Que devrais-je faire ?
A : Demandez au fournisseur du plugin s'il utilise @libp2p/kad-dht et quelle version. S'il est vulnérable, demandez ou appliquez une mise à jour qui inclut la version corrigée. En attendant, isolez ou désactivez le service helper si cela est sûr à faire.

Q : La vulnérabilité permet-elle le vol de données sur les sites WordPress ?
A : Le principal risque documenté est l'épuisement des ressources (remplissage du disque). Bien que le vol de données direct ne soit pas la préoccupation immédiate de ce CVE, l'épuisement du disque peut perturber les services, supprimer ou corrompre des journaux, et créer des conditions qui aident les attaquants. Prenez-le au sérieux.

---

Comment WP-Firewall aide à protéger les sites WordPress

En tant que fournisseur de sécurité WordPress géré, WP-Firewall offre des protections en couches qui réduisent le risque tant pour les installations WordPress classiques que pour les environnements incluant des composants Node :

• Pare-feu géré et WAF : nous créons et distribuons des signatures de couche d'application et des règles de limitation de débit qui peuvent bloquer des modèles de trafic suspects, des charges utiles importantes ou anormales, et des tentatives de connexion à haute fréquence qui précèdent les abus de DHT.
• Analyse de logiciels malveillants : notre scanner surveille les anomalies du système de fichiers et la croissance soudaine des fichiers qui sont des indicateurs principaux des attaques par épuisement de disque.
• Atténuation des risques OWASP Top 10 : prévenir les vecteurs courants réduit la chance de mouvement latéral vers les machines des développeurs ou CI.
• Protection pour les environnements mixtes : si votre architecture WordPress inclut des services sans tête ou soutenus par Node, WP-Firewall fournit des règles et des recommandations pour isoler et protéger ces composants.
• Fonctionnalités du plan gratuit : protection essentielle incluant un pare-feu géré, une bande passante illimitée, un WAF, une analyse de logiciels malveillants, et une couverture d'atténuation pour les risques OWASP Top 10.

Nous recommandons à tous les propriétaires de sites d'évaluer leur exposition et, le cas échéant, d'activer les protections de pare-feu qui incluent la limitation de débit, le blocage de la réputation IP et la détection d'anomalies pour atténuer les attaques telles que CVE-2026-45783 jusqu'à ce que des correctifs complets soient appliqués.

---

Une liste de contrôle de remédiation pratique (étape par étape)

1. Inventaire
   – Identifiez toutes les instances Node, conteneurs et runners CI. Recherchez dans les dépôts et artefacts @libp2p/kad-dht.
2. Patch
   – Mettez à jour vers @libp2p/kad-dht >= 16.2.6.
   – Reconstruisez les images, artefacts et redéployez.
3. Isoler
   – Bloquez l'accès réseau externe aux nœuds DHT en attente de validation.
   – Appliquez des quotas de disque par processus et des limites de stockage de conteneurs.
4. Renforcer
   – Ajoutez des limites de débit et des règles WAF pour les services Node.
   – Limitez les pairs autorisés à écrire dans les magasins DHT lorsque cela est possible.
5. Moniteur
   – Alertez sur les pics d'utilisation du disque et les modèles d'écriture anormaux.
   – Surveillez les augmentations de trafic vers les ports liés au DHT.
6. Tester
   – Validez que les dépendances et les services fonctionnent correctement avec la bibliothèque corrigée.
   – Exécutez des tests de récupération (redémarrage, basculement) dans un environnement contrôlé.
7. Signalez et communiquez
   – Informez les hôtes/fournisseurs tiers si leurs composants sont affectés.
   – Documentez l'incident et les leçons apprises.

---

Nouveau : Commencez avec WP‑Firewall Free pour élever votre niveau de protection immédiat.

Titre : Renforcez rapidement votre site — commencez avec WP‑Firewall Free.

Si vous souhaitez une protection immédiate et sans coût pendant que vous effectuez des audits de dépendances et coordonnez les correctifs, envisagez de commencer avec le plan WP‑Firewall Basic (Gratuit). Il fournit des protections essentielles — un pare-feu géré, des règles WAF, une bande passante illimitée, une analyse de logiciels malveillants et une atténuation des 10 principales vulnérabilités OWASP — pour réduire la chance qu'une attaque liée aux services Node impacte votre site WordPress. Inscrivez-vous et protégez-vous rapidement à : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Si vous avez besoin d'une remédiation automatisée plus rapide, de scans programmés ou de correctifs virtuels pendant que vous mettez à jour des piles complexes, nos niveaux payants ajoutent la suppression automatisée de logiciels malveillants, des contrôles IP plus granulaires et des fonctionnalités de correctifs virtuels automatiques pour aider à combler le fossé entre la détection et le déploiement complet des correctifs.

---

Derniers mots — pourquoi une action rapide est importante.

CVE-2026-45783 est une priorité élevée pour une raison : les attaques par épuisement des ressources sont des amplificateurs pour des pannes plus importantes et peuvent être déclenchées avec un effort relativement faible. Pour les propriétaires de sites WordPress, le risque est souvent indirect — mais les dépendances opérationnelles signifient que les risques indirects produisent des pannes directes. Le chemin le plus sûr est : inventaire, correctif, reconstruction et durcissement. Utilisez des défenses en couches — contrôles réseau, quotas par processus, protections WAF et surveillance — pour protéger votre plateforme pendant que les mises à jour se propagent à travers votre chaîne d'approvisionnement.

Si vous avez besoin d'aide pour auditer votre site WordPress pour les dépendances Node, configurer des signatures WAF ou mettre en œuvre des atténuations temporaires pendant que vous appliquez des correctifs, notre équipe de sécurité peut vous aider avec des conseils et des protections gérées.

Restez en sécurité et priorisez les correctifs pour tout service qui touche votre environnement de production.

— Équipe de sécurité WP-Firewall