Vulnérabilité critique IDOR dans le plugin Quick Featured Images // Publié le 15/10/2025 // CVE-2025-11176

ÉQUIPE DE SÉCURITÉ WP-FIREWALL

Quick Featured Images Vulnerability CVE-2025-11176

Nom du plugin Images vedettes rapides
Type de vulnérabilité Référence d'objet directe non sécurisée (IDOR)
Numéro CVE CVE-2025-11176
Urgence Faible
Date de publication du CVE 2025-10-15
URL source CVE-2025-11176

Images vedettes rapides <= 13.7.2 — IDOR vers manipulation d'images (CVE-2025-11176)

Par l'équipe de sécurité WP-Firewall

TL;DR : Une vulnérabilité de faible gravité, de type IDOR (Insecure Direct Object Reference), dans l'extension Quick Featured Images (CVE-2025-11176), permettait à certains utilisateurs authentifiés de manipuler des images auxquelles ils n'auraient pas dû avoir accès. Ce problème est résolu dans la version 13.7.3. Les propriétaires de sites sont invités à effectuer la mise à jour immédiatement. Si la mise à jour n'est pas possible dans l'immédiat, le déploiement de correctifs virtuels et le renforcement de la sécurité peuvent atténuer les risques.


Table des matières

  • Que s'est-il passé (résumé)
  • Contexte technique (qu'est-ce qu'un IDOR et comment s'applique-t-il ici ?)
  • Pourquoi cela est important pour les sites WordPress
  • Scénarios d'exploitation et impact réaliste
  • Détection : signes à rechercher sur votre site
  • Mesures d'atténuation immédiates (pour les propriétaires de sites)
  • Comment un WAF et le patchage virtuel peuvent aider (approche WP-Firewall)
  • Améliorations recommandées à long terme et correctifs pour les développeurs
  • Liste de contrôle en cas d'incident (si vous soupçonnez une compromission)
  • Guide de remédiation à grande échelle pour les agences et les hôtes
  • Foire aux questions
  • Commencez dès aujourd'hui à protéger votre site — WP‑Firewall Basic (formule gratuite)

Que s'est-il passé (résumé)

Le 15 octobre 2025, une vulnérabilité a été publiée sous la référence CVE‑2025‑11176 affectant le plugin WordPress Quick Featured Images dans les versions jusqu'à la version 13.7.2 incluse. La cause principale est une référence directe à un objet non sécurisée (IDOR) dans un point de terminaison de manipulation d'image : un utilisateur disposant de privilèges inférieurs (Auteur) pouvait effectuer des opérations sur l'image qui auraient dû nécessiter un contrôle d'autorisation plus strict.

Le score CVSS publié pour ce problème est de 4,3 (Faible). L'exploitation de cette vulnérabilité nécessite un utilisateur authentifié disposant du rôle Auteur (ou d'un rôle aux capacités équivalentes). L'éditeur a publié un correctif dans la version 13.7.3 afin de résoudre les problèmes de vérification d'autorisation.

Nous recommandons aux propriétaires de sites de mettre à jour leur système vers la version 13.7.3 ou ultérieure immédiatement. Si, pour des raisons opérationnelles, vous ne pouvez pas effectuer la mise à jour immédiatement, suivez les mesures d'atténuation ci-dessous afin de limiter les risques.


Contexte technique — qu'est-ce qu'un IDOR ?

Une référence directe à un objet non sécurisée (IDOR) se produit lorsqu'une application expose une référence interne à une ressource (fichier, enregistrement de base de données, identifiant d'image, etc.) de manière à permettre à un utilisateur d'accéder à des ressources ou de les modifier sans y être autorisé. Le problème ne réside ni dans le chiffrement ni dans le transport des données, mais dans l'autorisation : l'application ne vérifie pas si l'utilisateur effectuant la requête est autorisé à agir sur l'objet référencé.

Dans WordPress, les pièces jointes et les images sont stockées en tant que publications de type pièce jointe et sont référencées par des identifiants de pièce jointe (entiers). Une implémentation sécurisée vérifie systématiquement que l'utilisateur actuel possède les droits appropriés pour manipuler la pièce jointe concernée (par exemple, qu'il en est le propriétaire ou qu'il dispose des capacités requises). modifier_post (pour le billet parent). Il devrait également vérifier les nonces pour les actions d'interface utilisateur et utiliser des rappels d'autorisation sur les points de terminaison REST.

Dans ce cas d'utilisation de Quick Featured Images, un point de terminaison de manipulation d'images a accepté un identifiant de pièce jointe et a effectué des opérations sans vérifier suffisamment les privilèges et/ou la propriété de l'appelant. Cela a permis à un utilisateur authentifié (l'auteur) d'agir sur des pièces jointes au-delà de ses droits.


Pourquoi cela est important pour les sites WordPress

À première vue, une vulnérabilité nécessitant un compte auteur peut sembler mineure. Pourtant, plusieurs raisons expliquent son importance :

  • De nombreux sites permettent aux auteurs (ou contributeurs) de créer du contenu. Si ces rôles sont accessibles aux sous-traitants, aux auteurs invités ou aux comptes de faible fiabilité, un attaquant pourrait s'inscrire ou compromettre un tel compte.
  • Les auteurs sont fréquemment sollicités par les intégrations (articles invités, chargements de contenu côté client). La présence d'une vulnérabilité d'identification de la source (IDOR) accroît la surface d'attaque là où les comptes utilisateurs ne sont pas rigoureusement contrôlés.
  • Les points d'accès permettant la manipulation d'images sont souvent considérés comme fiables et intégrés aux éditeurs, aux aperçus frontaux et aux flux de travail externes. Si un attaquant parvient à remplacer ou à modifier des images, il peut effectuer des modifications de contenu trompeuses, insérer des liens vers des charges utiles malveillantes ou nuire à la confiance envers la marque.
  • Les IDOR peuvent être combinées à d'autres faiblesses : par exemple, une gestion défaillante des chargements de fichiers, l'absence de vérifications MIME ou des permissions de fichiers inadéquates. L'ensemble de ces failles peut entraîner le remplacement de fichiers, l'hébergement de logiciels malveillants ou la divulgation de données.

En raison de ces facteurs, même les vulnérabilités présentant des scores CVSS « faibles » méritent une action rapide.


Scénarios d'exploitation et impact réaliste

Nous ne publierons pas de code d'exploitation ici. Vous trouverez ci-dessous des impacts et des scénarios plausibles et réalistes à prendre en compte lors de l'évaluation des risques pour votre site.

Vecteurs d'impact possibles

  • Remplacement ou modification non autorisée d'images : un auteur intervertit une image mise en avant utilisée dans plusieurs articles. Cela peut dénaturer le contenu ou insérer des images trompeuses, même si l'attaquant ne peut pas modifier le contenu des autres articles.
  • Hébergement de contenu malveillant — si un attaquant peut remplacer une image par un fichier contenant des charges utiles malveillantes ou des redirections (par exemple, un fichier HTML déguisé en image sur des serveurs mal configurés), il peut tenter de distribuer des logiciels malveillants ou de mener une attaque d'hameçonnage.
  • Exposition des pièces jointes privées — un attaquant pourrait être en mesure de récupérer ou de manipuler les pièces jointes associées à des publications privées si le point de terminaison expose les données des pièces jointes sans contrôle d'autorisation.
  • Risque lié à la chaîne d'approvisionnement du contenu — les intégrations tierces qui utilisent des images mises en avant pour afficher les aperçus des e-mails, les flux RSS ou les extractions CDN pourraient propager des contenus multimédias falsifiés aux abonnés.
  • Atteinte à la réputation et au référencement naturel — des modifications importantes et peu visibles des images dans les publications peuvent nuire à la confiance envers la marque et à l'indexation par les moteurs de recherche.

Qui peut l'exploiter ?

  • L'avis publié indique que le privilège requis est celui d'auteur. Cela signifie que les attaquants doivent posséder un compte avec ce rôle ou des droits équivalents. Sur de nombreux sites acceptant les auteurs invités ou permettant l'inscription automatique, obtenir ce niveau est aisé.

Quelle est la probabilité d'exploitation ?

  • Ce problème présente un faible score CVSS et nécessite une authentification ; il ne fait donc pas partie des vulnérabilités les plus urgentes. Cependant, les attaquants opportunistes recherchent fréquemment les failles de sécurité faciles à exploiter. Si un attaquant parvient à créer un compte Auteur ou à en compromettre un, l’exploitation est simple et des attaques automatisées peuvent être rapidement mises en œuvre.

Détection — indicateurs à rechercher dans vos journaux et votre interface utilisateur

Si vous souhaitez vérifier si votre site a été ciblé ou si quelqu'un a tenté d'exploiter cette faille, commencez par rechercher les signes suivants :

Journaux HTTP/Serveur

  • Les requêtes POST/GET adressées aux actions de manipulation d'images du plugin, aux points de terminaison admin-ajax ou à une route REST référençant les identifiants d'images ou de pièces jointes sont recherchées. Recherchez les modèles de requêtes contenant des paramètres tels que : pièce jointe_id, id_post, image_id, taille, action=..., etc.
  • Les requêtes adressées à ces points de terminaison et provenant d'adresses IP inhabituelles, ou d'adresses IP avec de nombreuses requêtes successives.
  • Requêtes provenant de comptes d'auteurs effectuant des opérations sur des pièces jointes appartenant à différents auteurs.

Journaux d'activité WordPress

  • Modifications massives et soudaines des métadonnées des pièces jointes (noms de fichiers, texte alternatif, légendes).
  • Fichiers multimédias nouveaux ou modifiés avec des horodatages correspondant à des requêtes suspectes.
  • Notifications d'administration ou files d'attente de modération signalant des modifications d'images inattendues.

Vérifications du système de fichiers et des supports

  • Nouveaux fichiers dans wp‑content/uploads avec des extensions inhabituelles, des tailles de fichier inattendues ou des noms qui ne respectent pas vos conventions de nommage habituelles.
  • Fichiers présentant des métadonnées EXIF suspectes ou des noms de fichiers contenant des URL ou du JavaScript.

Analyse des logiciels malveillants

  • Alertes des logiciels de détection de logiciels malveillants signalant des modifications apportées aux fichiers multimédias ou la détection de nouveaux fichiers malveillants.

Si vous soupçonnez une exploitation, conservez les journaux et les fichiers multimédias, et suivez la liste de contrôle de réponse aux incidents ci-dessous.


Mesures d'atténuation immédiates (pour les propriétaires de sites)

  1. Mettre à jour le plugin (le plus efficace et le plus rapide)
    • Mettez à jour Quick Featured Images vers la version 13.7.3 ou ultérieure. Ce correctif du fournisseur résout les problèmes de vérification d'autorisation.
  2. Si vous ne pouvez pas effectuer la mise à jour immédiatement, appliquez des mesures d'atténuation à court terme :
    • Désactivez les fonctionnalités de manipulation d'images du plugin si la configuration le permet.
    • Désactivez temporairement le plugin en attendant de pouvoir le tester et le mettre à jour ; si la manipulation d’images n’est pas essentielle à votre flux de travail, il s’agit d’une solution sûre.
    • Limitez l'accès aux inscriptions et aux rôles d'auteur. Désactivez ou limitez l'auto-inscription et vérifiez la liste des utilisateurs afin de repérer les auteurs inattendus.
    • Révoquez ou réinitialisez les identifiants des comptes qui semblent suspects.
  3. Appliquez le correctif virtuel à l'aide de votre pare-feu/WAF (recommandé).
    • Si vous utilisez un pare-feu applicatif WordPress, activez les règles ciblant les requêtes modifiant les pièces jointes ou les métadonnées d'images provenant d'utilisateurs n'ayant pas de rôle d'administrateur. WP-Firewall peut déployer ces signatures et heuristiques pour bloquer les tentatives suspectes (voir « Comment un WAF peut vous aider » ci-dessous).
  4. Sécuriser les chargements et le système de fichiers
    • Assurez-vous que votre serveur web n'exécute pas les fichiers du répertoire uploads (pas d'exécution PHP).
    • Utilisez des vérifications strictes du type MIME et du type d'image pour les téléchargements.
    • Définissez les permissions appropriées pour les fichiers et les répertoires (généralement 755 pour les répertoires et 644 pour les fichiers sur Apache ; à confirmer auprès de votre hébergeur).
  5. Surveiller et analyser
    • Effectuez une analyse complète du site à la recherche de logiciels malveillants et examinez les modifications récentes apportées à la bibliothèque multimédia.
    • Surveillez les journaux pour toute requête adressée aux points de terminaison de manipulation d'images, comme décrit dans la section Détection.
  6. Sauvegardes
    • Assurez-vous de disposer de sauvegardes externes récentes de votre site et de vos médias afin de pouvoir les restaurer en cas de besoin.

Comment un pare-feu d'applications Web et le correctif virtuel peuvent aider — Point de vue de WP-Firewall

En tant que fournisseur de pare-feu applicatifs web (WAF) et de services de sécurité WordPress gérés, nous déployons plusieurs niveaux de protection afin de réduire l'exposition aux vulnérabilités comme celle-ci. Voici comment un WAF correctement configuré et le patchage virtuel peuvent vous aider pendant la mise à jour de l'extension et le nettoyage.

  1. Correctif virtuel (vPatch)
    • Le patchage virtuel crée des ensembles de règles qui bloquent les tentatives d'exploitation au niveau de la couche HTTP avant qu'elles n'atteignent le code vulnérable. Pour cette IDOR, nous créons des règles qui :
      • Bloquer les requêtes vers les points de terminaison connus de manipulation d'images provenant de rôles qui ne devraient pas y avoir accès.
      • Exiger des nonces valides ou des en-têtes attendus pour les actions administratives.
      • Détecter et bloquer l'utilisation anormale des paramètres (par exemple, les requêtes qui tentent d'opérer sur plusieurs identifiants de pièces jointes dans une seule requête).
    • Les correctifs virtuels sont sûrs à appliquer et peuvent être annulés de manière centralisée, offrant ainsi aux opérateurs de sites une protection immédiate sans modifier le code du plugin.
  2. Heuristiques comportementales et limitation du débit
    • Même si une requête semble légitime, des comportements suspects (taux de requêtes élevé, accès répétés à différentes pièces jointes ou plusieurs comptes utilisateurs effectuant la même opération) sont à prendre en compte. Nous utilisons des règles de limitation de débit et la détection d'anomalies pour ralentir ou bloquer les analyses automatisées.
  3. Sécurisation du téléchargement de fichiers
    • Notre WAF inspecte les fichiers téléchargés à la recherche de signatures de fichiers dangereuses et applique des contrôles MIME afin de réduire le risque qu'un fichier remplacé contienne du contenu exécutable.
  4. Application de la loi fondée sur les rôles
    • Dans la mesure du possible, nous appliquons des contrôles de rôle au niveau du WAF (par exemple, en empêchant le rôle d'auteur d'accéder aux routes destinées aux éditeurs/administrateurs) en examinant les cookies d'authentification et les jetons de session ; il s'agit d'un filtre supplémentaire qui s'ajoute à la logique de l'application.
  5. Journalisation, alertes et analyses forensiques
    • Les requêtes bloquées et les activités suspectes sont enregistrées et affichées sur des tableaux de bord, ce qui vous permet de voir rapidement si la règle est appliquée et si une tentative a été effectuée.
  6. Remédiation gérée
    • Pour les clients disposant de plans gérés, nous pouvons déployer instantanément des correctifs virtuels ciblés sur l'ensemble de leurs sites et fournir des plans de remédiation ainsi qu'une assistance au nettoyage.

Pourquoi c'est important : Une règle WAF immédiate peut réduire à zéro le risque pour la plupart des tentatives d'exploitation courantes, en attendant l'application du correctif officiel du plugin. Le patch virtuel est particulièrement utile pour les sites qui ne peuvent pas effectuer de mises à jour immédiates en raison de fenêtres de test, de dépendances ou d'exigences liées à l'environnement de préproduction.


Correctifs recommandés par les développeurs (pour les auteurs et intégrateurs de plugins)

Si vous gérez du code personnalisé ou des plugins qui interagissent avec des médias, adoptez ces modèles de codage sécurisés pour éviter les IDOR :

  • Vérifiez toujours les capacités et la propriété.
    • Utilisez des contrôles de capacité tels que l'utilisateur actuel peut ( 'modifier_le_post', $post_id ) ou vérifiez le propriétaire de la pièce jointe avant d'autoriser toute modification.
    • Pour les points de terminaison REST, implémentez un permission_callback et rejeter les requêtes par défaut.
  • Valider et nettoyer toutes les entrées
    • Utiliser intval() pour les identifiants numériques ; assainir_champ_texte() Pour les chaînes de caractères. N'acceptez pas les identifiants bruts et n'opérez pas sans vérification.
  • Exiger des nonces pour les opérations de modification d'état
    • Utiliser wp_verify_nonce() pour les gestionnaires AJAX d'administration et les champs nonce pour les soumissions de formulaires.
  • Évitez de vous fier aux données côté client pour l'autorisation.
    • Ne vous fiez pas aux champs de formulaire cachés ni aux indications de propriété fournies par le client. Résolvez la question de la propriété côté serveur à l'aide de requêtes de base de données.
  • Utilisez les API WordPress pour la gestion des médias.
    • Utiliser wp_get_attachment_metadata et wp_update_attachment_metadata avec les vérifications appropriées, et évitez de modifier directement les fichiers du système de fichiers sans avoir effectué les vérifications de capacité appropriées.
  • Limiter les opérations par rôle le cas échéant.
    • Si seuls les éditeurs/administrateurs doivent manipuler des images qui affectent plusieurs publications, exigez explicitement ces capacités.
  • Outils de test approfondis
    • Ajoutez des tests unitaires et d'intégration concernant les règles d'autorisation. Incluez des tests négatifs où des utilisateurs disposant de faibles privilèges tentent des actions nécessitant des privilèges élevés.

Liste de contrôle en cas d'incident (si vous soupçonnez une compromission)

  1. Conserver les bûches
    • Conservez les journaux du serveur web, les journaux d'activité WordPress et tous les journaux WAF. Ils sont essentiels pour une enquête forensique.
  2. Isoler le problème
    • Si vous constatez des modifications de fichiers non autorisées, mettez hors ligne les systèmes concernés ou placez-les derrière des pages de maintenance pendant que vous menez votre enquête.
  3. Mise à jour et correctif
    • Appliquez immédiatement le correctif du fournisseur (13.7.3) ou désactivez le plugin si vous ne pouvez pas effectuer la mise à jour en toute sécurité.
  4. Numériser et nettoyer
    • Effectuez une analyse complète de l'intégrité des fichiers et à la recherche de logiciels malveillants sur l'ensemble du site. Vérifiez la présence de nouveaux fichiers PHP dans les fichiers téléchargés, de tâches cron inconnues ou de fichiers système modifiés.
  5. Réinitialiser les identifiants
    • Réinitialisez les mots de passe des comptes utilisateurs concernés et des administrateurs. Renouvelez les clés API et les identifiants de service utilisés par le site.
  6. Restaurez à partir d'une sauvegarde propre (si nécessaire).
    • Si vous constatez des signes de compromission persistante, envisagez de restaurer une sauvegarde effectuée avant l'activité suspecte.
  7. Surveillance post-incident
    • Maintenez une surveillance accrue du site pendant au moins 30 jours. Soyez attentif à la réapparition de fichiers modifiés ou de nouveaux comptes suspects.
  8. Rapport et document
    • Si la violation affecte des données clients ou est importante, respectez toutes les obligations légales ou contractuelles de notification et conservez une documentation claire de l'incident à des fins d'audit.

Guide de remédiation à grande échelle pour les agences et les hôtes

Si vous gérez plusieurs sites WordPress, suivez un plan de remédiation structuré :

  1. Inventaire
    • Recherchez le plugin et sa version sur tous les sites gérés. Automatisez l'inventaire avec WP-CLI ou les tableaux de bord de gestion.
  2. Priorisation
    • Privilégier les sites où les auteurs peuvent être créés par des utilisateurs externes, ou ceux où les médias sont largement réutilisés.
  3. Stratégie de correctifs
    • Pour les sites standard, planifiez une fenêtre de mise à jour immédiate pour passer à la version 13.7.3. Pour les sites complexes, implémentez d'abord les correctifs virtuels WAF, puis planifiez les mises à jour testées.
  4. Communication
    • Informez vos clients du problème, des mesures prises et des délais prévus. Fournissez une brève explication des risques et des actions entreprises.
  5. Appliquer des mesures d'atténuation automatisées
    • Déployez les règles de correctifs virtuels sur tous les sites via une gestion WAF centralisée. Surveillez l'efficacité des règles et les faux positifs.
  6. Audit après la mise à jour
    • Après les mises à jour des plugins, vérifiez les modifications apportées à la bibliothèque multimédia et consultez les entrées du journal pour suivre l'activité post-mise à jour.

Foire aux questions

Q : Cette vulnérabilité nécessite un compte auteur. Dois-je m'inquiéter ?
R : Oui, de nombreux sites permettent aux éditeurs de créer des comptes d'auteur, ou proposent des intégrations utilisant des comptes aux privilèges limités. Si des attaquants parviennent à créer ou à compromettre un compte d'auteur, cette vulnérabilité pourrait être exploitée.

Q : Cette vulnérabilité est-elle exploitable sans se connecter ?
A : Les rapports publiés indiquent qu'une authentification en tant qu'auteur est requise. Cela réduit le risque par rapport à une exécution de code à distance non authentifiée, mais les exploits nécessitant une authentification restent graves.

Q : J'ai effectué la mise à jour — ai-je besoin de quelque chose d'autre ?
A : Après la mise à jour, analysez votre site à la recherche de modifications suspectes, vérifiez les modifications inattendues des médias et examinez les comptes utilisateurs. Si vous avez appliqué un correctif virtuel, supprimez la règle temporaire uniquement après avoir confirmé que la mise à jour du plugin a bien résolu le problème.

Q : Un WAF peut-il perturber le fonctionnement normal d'un site web ?
R : Excellente question ! Des règles mal configurées peuvent générer de faux positifs. Les processus de test de WP-Firewall incluent des simulations et des déploiements progressifs. Si vous utilisez vos propres règles WAF, effectuez d’abord des tests en environnement de préproduction.


Commencez dès aujourd'hui à protéger votre site — WP‑Firewall Basic (formule gratuite)

Sécurisez instantanément votre site avec le forfait Basic (gratuit) de WP‑Firewall, conçu pour offrir aux propriétaires de sites les protections essentielles dont ils ont besoin, sans frais.

Ce que vous obtenez avec la version de base (gratuite)

  • Pare-feu géré essentiel et pare-feu d'applications Web (WAF)
  • Bande passante illimitée et inspection des requêtes en temps réel
  • Scanner de logiciels malveillants qui vérifie les supports et les codes suspects.
  • Mesures d'atténuation adaptées aux 10 principaux risques OWASP, incluant des règles pour les modèles IDOR et les points d'accès courants à la manipulation d'images.

Si vous souhaitez bénéficier d'une sécurité renforcée lors de vos mises à jour et audits, inscrivez-vous à notre offre gratuite et laissez notre protection gérée surveiller les tentatives d'exploitation et les requêtes non sécurisées :
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Envisagez de passer ultérieurement à la version Standard ou Pro pour bénéficier de la suppression automatique des logiciels malveillants, du contrôle d'autorisation/de refus des adresses IP, de rapports de sécurité mensuels et de notre service de mise à jour automatique des logiciels virtuels.


Recommandations finales — que faire maintenant

  1. Mettez à jour Quick Featured Images immédiatement vers la version 13.7.3 ou ultérieure. Il s'agit de la solution définitive.
  2. Vérifiez la présence d'une activité inhabituelle dans votre bibliothèque multimédia et les journaux de votre serveur pour les semaines entourant le 15 octobre 2025.
  3. Si vous ne pouvez pas effectuer la mise à jour immédiatement :
    • Désactivez le plugin ou désactivez les fonctions de manipulation d'images.
    • Restreindre les privilèges des utilisateurs ayant le rôle d'auteur pour la création et la révision.
    • Activez une règle WAF/de correctif virtuel qui empêche les tentatives de manipulation suspectes des pièces jointes.
  4. Scannez et sauvegardez — assurez-vous d'avoir des sauvegardes propres avant et après les modifications.
  5. Envisagez un plan de sécurité géré si vous hébergez de nombreux sites ou si vous ne pouvez pas réagir rapidement : la mise à jour virtuelle gérée réduit votre période d’exposition.

Si vous avez besoin d'aide pour valider votre site, consulter les journaux ou déployer un correctif virtuel pendant vos tests de mise à jour, notre équipe de sécurité WP-Firewall est là pour vous accompagner. Nous avons aidé des milliers de sites WordPress à corriger rapidement et efficacement leurs vulnérabilités.

Soyez prudent,
Équipe de sécurité WP-Firewall

(CVE : CVE‑2025‑11176 — chercheur crédité : Lucas Montes (Nirox))


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.