| Nom du plugin | eMagicOne Gestionnaire de Magasin |
|---|---|
| Type de vulnérabilité | Injection SQL |
| Numéro CVE | CVE-2026-42773 |
| Urgence | Haut |
| Date de publication du CVE | 2026-05-09 |
| URL source | CVE-2026-42773 |
Urgent : Injection SQL dans eMagicOne Store Manager (≤1.3.2) — Ce que les propriétaires de sites WordPress et les développeurs doivent faire maintenant
Auteur: Équipe de sécurité WP-Firewall
Date: 2026-05-09
Mots clés: WordPress, Vulnérabilité, Injection SQL, WAF, Réponse aux incidents, eMagicOne Store Manager
Résumé : Une vulnérabilité critique d'injection SQL (CVE-2026-42773) affectant le plugin eMagicOne Store Manager (versions ≤ 1.3.2) a été divulguée publiquement. Cette vulnérabilité est classée comme élevée (CVSS 9.3) et peut être déclenchée par des requêtes non authentifiées. Si vous exécutez ce plugin sur un site WordPress, agissez immédiatement : isolez, atténuez et suivez les étapes de remédiation dans ce post.
Table des matières
- Aperçu : ce qui s'est passé
- Pourquoi l'injection SQL est-elle si dangereuse pour les sites WordPress
- Résumé technique de la vulnérabilité (niveau élevé)
- Étapes immédiates pour les propriétaires de sites (minutes à heures)
- Atténuations à court terme (heures à jours)
- Comment détecter l'exploitation et les indicateurs de compromission
- Guide pour les développeurs : comment corriger le code correctement
- Guide WAF et de patch virtuel (ce que nous recommandons)
- Liste de contrôle de réponse aux incidents (pour les sites compromis)
- Durcissement et prévention à long terme
- À propos de WP-Firewall et comment nous pouvons aider
- Protégez votre site aujourd'hui — WP-Firewall Basic (Gratuit)
Aperçu : ce qui s'est passé
Le 7 mai 2026, une vulnérabilité d'injection SQL de haute priorité affectant le plugin WordPress eMagicOne Store Manager (versions ≤ 1.3.2) a été divulguée publiquement (CVE-2026-42773). Selon l'avis, le code défectueux accepte des entrées non assainies et construit des requêtes SQL d'une manière qui permet à un attaquant de manipuler les requêtes de base de données à distance, sans authentification.
Faits clés :
- Vulnérabilité : Injection SQL (A3 : Injection / OWASP)
- Plugin affecté : eMagicOne Store Manager (connecteur)
- Versions vulnérables : ≤ 1.3.2
- Privilège requis : Non authentifié (aucune connexion requise)
- Score CVSS utilisé par le chercheur : 9.3 (Élevé)
- Statut : Aucun patch officiel disponible au moment de la divulgation pour les versions vulnérables
Parce qu'il s'agit d'une injection SQL non authentifiée, l'exposition est sérieuse : les attaquants peuvent extraire ou modifier des données, escalader des privilèges, créer des comptes administrateurs ou utiliser le site comme point d'appui pour d'autres attaques.
Pourquoi l'injection SQL est-elle si dangereuse pour les sites WordPress
L'injection SQL est l'une des vulnérabilités web les plus impactantes. Sur les sites WordPress, les conséquences incluent :
- Divulgation complète de la base de données : les attaquants peuvent lire wp_users (hashs de mots de passe), wp_options (paramètres sensibles du site), commandes, dossiers clients, clés API et autres données confidentielles.
- Escalade de privilèges : les attaquants peuvent modifier les rôles des utilisateurs ou ajouter des comptes administrateurs.
- Défiguration de site, portes dérobées, ransomware : avec l'accès à la base de données, un attaquant peut insérer du contenu malveillant, créer des tâches cron malveillantes ou implanter des portes dérobées persistantes.
- Mouvement latéral : le contenu de la base de données contient souvent des identifiants et des jetons que les attaquants utilisent pour accéder à l'hébergement, aux services tiers ou à d'autres sites connectés.
- Exploitation de masse : les vulnérabilités SQLi non authentifiées sont souvent armées et scannées en masse ; des milliers de sites peuvent être impactés rapidement.
Étant donné cela, tout site utilisant un plugin vulnérable devrait traiter le problème comme urgent.
Résumé technique de la vulnérabilité (niveau élevé)
La vulnérabilité survient lorsque le code du plugin construit des requêtes SQL en utilisant des données dérivées des paramètres de requête HTTP (GET/POST) sans validation ou paramétrage appropriés. Au lieu d'utiliser des instructions préparées ou les API de base de données WordPress en toute sécurité, le code concatène l'entrée dans une chaîne de requête. Cela permet à un attaquant d'injecter des structures de contrôle SQL (par exemple : clauses supplémentaires, UNION, opérateurs logiques) pour manipuler l'ensemble de résultats retourné ou effectuer des opérations destructrices.
Propriétés techniques importantes :
- Accès non authentifié : un attaquant n'a pas besoin de credentials pour déclencher le chemin de code vulnérable.
- Le point de terminaison vulnérable est accessible depuis le web (points de terminaison de connecteur de plugin ou routes AJAX/REST).
- Le plugin construit des requêtes influencées par des paramètres contrôlés par l'attaquant.
Nous ne publions délibérément pas de code d'exploitation ligne par ligne ou d'exemples de charges utiles d'attaque complètes ici pour éviter de fournir une feuille de route pour l'exploitation automatisée, mais les mécanismes sont des injections SQL classiques : SQL non paramétré qui inclut l'entrée utilisateur.
Étapes immédiates pour les propriétaires de sites (minutes à heures)
Si votre site utilise eMagicOne Store Manager (ou le plugin “Store Manager Connector”), faites ce qui suit immédiatement :
- Identifiez les installations affectées
- Recherchez dans votre liste de plugins (wp-admin > Plugins) et dans votre système de fichiers des dossiers de plugins avec des noms correspondant à eMagicOne / store-manager / store-manager-connector.
- Si vous utilisez un hébergement géré ou des inventaires de logiciels centralisés, interrogez le nom et la version du plugin.
- Prenez un instantané d'urgence (si possible)
- Créez une sauvegarde complète (fichiers + base de données) dès maintenant et stockez-la hors ligne. Cela préserve les preuves avant toute remédiation.
- Si vous ne pouvez pas immédiatement appliquer un correctif (aucun correctif officiel disponible) :
- Désactivez le plugin jusqu'à ce qu'un correctif sûr soit disponible.
- Si la désactivation casse les opérations et que vous ne pouvez pas mettre le plugin hors ligne, passez aux atténuations à court terme ci-dessous.
- Mettez le site en mode maintenance (si approprié)
- Limitez l'exposition publique pendant que vous complétez les scans et les atténuations.
- Faites tourner les identifiants sensibles
- Changez les mots de passe des comptes administrateurs WordPress, le mot de passe de l'utilisateur de la base de données (si possible) et toutes les clés API qui peuvent être stockées dans les options ou les paramètres des plugins.
- Informez votre équipe et votre fournisseur d'hébergement
- Informez les administrateurs du site et les équipes de sécurité de l'hébergement et coordonnez les étapes et la préservation des journaux.
Ces actions d'urgence visent à contenir l'exposition. Si vous soupçonnez un compromis, suivez la liste de contrôle de réponse aux incidents ci-dessous.
Atténuations à court terme (heures à jours)
Si vous ne pouvez pas immédiatement mettre à jour le plugin (par exemple, aucun correctif n'a été publié ou la mise à jour perturbera des flux critiques pour l'entreprise), appliquez une ou plusieurs des atténuations suivantes en attendant un correctif approprié :
- Patching virtuel via WAF
- Déployez une règle de pare-feu d'application Web pour bloquer les modèles de requêtes malveillantes ciblant le point de terminaison du plugin. Le patch virtuel empêche les tentatives d'exploitation d'atteindre le code vulnérable.
- Restreindre l'accès aux points de terminaison du plugin
- Utilisez des règles d'accès au niveau du serveur (.htaccess, configuration nginx) pour restreindre les points de terminaison du connecteur du plugin à des plages d'IP spécifiques (IP administratives, serveurs de gestion de magasin) ou pour bloquer tout accès direct depuis Internet public.
- Exemple : interdire l'accès public à /wp-content/plugins/store-manager-connector/* sauf depuis des IP de confiance.
- Désactivez ou restreignez les routes admin-ajax / REST utilisées par le plugin.
- Si le bogue se trouve dans un gestionnaire AJAX ou REST qui n'est pas requis pour la fonctionnalité de base, désactivez temporairement le gestionnaire ou ajoutez une vérification de permission.
- Ajoutez des vérifications de longueur de requête et de valeur de paramètre.
- Bloquez les requêtes contenant des fragments SQL suspects (par exemple, “UNION”, “SELECT”, “SLEEP(“, “--“, “/*”) dans les paramètres utilisés par le plugin — mais évitez un blocage trop large qui nuirait au trafic légitime.
- Renforcez l'utilisateur de la base de données.
- Dans la mesure du possible, exécutez WordPress avec un utilisateur de base de données qui a uniquement les privilèges requis. Remarque : le cœur de WordPress s'attend à SELECT/INSERT/UPDATE/DELETE ; restreindre les privilèges peut casser des plugins, mais dans la mesure du possible, évitez d'accorder des privilèges de type superutilisateur.
- Surveillez et limitez le taux.
- Ajoutez une limitation de taux pour les requêtes aux points de terminaison du plugin et activez la journalisation et les alertes pour les requêtes répétées qui correspondent à des modèles d'injection.
- Scannez à la recherche de signes de compromission
- Exécutez une analyse de logiciels malveillants des fichiers et de la base de données, vérifiez les nouveaux comptes administrateurs, les options suspectes, le contenu ou les tâches planifiées.
Remarque : ces atténuations sont des solutions temporaires, pas des remplacements pour la mise à niveau ou le patching du plugin vulnérable.
Comment détecter l'exploitation et les indicateurs de compromission (IoCs)
Surveillez les signaux suivants indiquant qu'un site a pu être ciblé ou compromis via une injection SQL :
- Requêtes ou erreurs de base de données inattendues dans les journaux.
- Erreurs MySQL dans les journaux PHP mentionnant des erreurs de syntaxe, des requêtes étranges ou des délais d'attente de requêtes.
- Pages anormalement lentes ou pics de charge de la base de données
- Des requêtes lourdes répétées déclenchées par des charges utiles injectées peuvent provoquer des pics de charge.
- Nouveaux utilisateurs administrateurs ou utilisateurs modifiés
- Vérifiez wp_users pour des comptes non reconnus ou des changements de privilèges.
- Changements inattendus dans wp_options, posts ou posts_meta
- Les attaquants déposent souvent des options malveillantes ou changent les paramètres de l'URL du site pour rediriger le trafic.
- Nouveaux fichiers PHP ou fichiers de plugin modifiés
- Les changements dans le système de fichiers (nouvelles portes dérobées) sont courants après une exploitation.
- Tâches planifiées (wp_cron) que vous n'avez pas créées
- Vérifiez wp_options où les entrées cron sont stockées et le crontab du serveur pour des tâches malveillantes.
- Connexions sortantes
- Du code malveillant peut se connecter à des serveurs de commande et de contrôle distants.
- Requêtes HTTP suspectes
- Appels répétés aux points de terminaison des plugins avec des chaînes de paramètres anormalement longues, ou des paramètres contenant des mots-clés SQL ou des charges utiles encodées.
Journaux à inspecter :
- Journaux d'accès du serveur web (filtrer par points de terminaison de plugins)
- Journaux d'erreurs PHP-FPM / Apache
- WordPress debug.log (si activé)
- Journaux de base de données (journal des requêtes lentes, journal des requêtes générales)
- Journaux du panneau de contrôle d'hébergement (téléchargements SFTP, changements de fichiers)
Si l'un de ces éléments apparaît, considérez le site comme potentiellement compromis et suivez la liste de contrôle de réponse aux incidents ci-dessous.
Guide pour les développeurs : comment corriger le code correctement
Si vous maintenez ou développez le plugin, ou si vous êtes le fournisseur, suivez les meilleures pratiques de codage sécurisé pour corriger les vulnérabilités d'injection SQL :
- Utilisez des requêtes paramétrées et les API de base de données WordPress
Toujours utiliser
$wpdb->preparepour les requêtes qui incluent des entrées externes. Exemple (sûr) :global $wpdb; - Évitez la concaténation de chaînes pour SQL
Ne construisez pas SQL comme : “… WHERE id = $id” où $id est fourni par l'utilisateur.
- Utilisez $wpdb->insert / $wpdb->update / $wpdb->delete
Ces fonctions d'assistance préparent et castent automatiquement les valeurs.
$wpdb->insert(; - Pour les points de terminaison de l'API REST, appliquez des rappels de permission
Lors de l'enregistrement des routes REST, fournissez un robuste
permission_callbackqui vérifie les capacités et, si nécessaire, les nonces.register_rest_route( 'myplugin/v1', '/do-something', [; - Valider et nettoyer toutes les entrées
Utilisez le bon assainisseur pour chaque type attendu :
assainir_champ_texte()pour un texte courtassainir_email(),sanitize_textarea_field(),esc_url_raw()intval(),floatval(),wp_validate_{{pc_skip_field}}- Pour une entrée structurée (JSON), décodez et validez les clés et types attendus.
- Limitez les résultats et utilisez des listes blanches
Lorsque cela est possible, acceptez uniquement des valeurs spécifiques connues (liste blanche) au lieu d'essayer de bloquer de mauvais modèles.
- Évitez de renvoyer des erreurs de base de données aux utilisateurs
Les erreurs qui révèlent des détails SQL ou de schéma aident les attaquants.
- Utilisez des instructions préparées pour les requêtes LIKE
Utiliser
$wpdb->esc_like()+ préparez. - Ajoutez des tests unitaires et des tests de fuzz.
Testez vos couches d'accès aux données avec des entrées inattendues pour vous assurer qu'elles échouent en toute sécurité.
- Utilisation de bibliothèques tierces
Si votre plugin inclut des helpers de base de données externes ou des couches similaires à un ORM, examinez-les pour une paramétrisation appropriée.
En suivant cette liste de contrôle, les développeurs de plugins peuvent prévenir les SQLi et d'autres classes d'injection.
Guide WAF et de patch virtuel (ce que nous recommandons)
Un pare-feu d'application Web (WAF) est l'un des moyens les plus rapides de protéger les sites contre les vulnérabilités connues pendant qu'un fournisseur prépare et distribue un correctif approprié. WP-Firewall fournit des règles WAF gérées et un patch virtuel qui peut bloquer les tentatives d'exploitation ciblant les points de terminaison spécifiques du plugin.
L'efficacité du patch virtuel :
- Il bloque les modèles d'exploitation connus au niveau HTTP avant qu'ils n'atteignent le code PHP vulnérable.
- Il donne du temps aux équipes de développement pour produire, tester et distribuer des correctifs appropriés.
- Lorsqu'il est soigneusement ajusté, le patch virtuel génère peu de faux positifs et maintient le site disponible.
Recommandations de règles WAF (niveau élevé — ajusté par site) :
- Bloquez les requêtes vers des points de terminaison spécifiques au plugin qui contiennent des caractères de contrôle SQL ou des mots-clés (par exemple, “ UNION ” non échappé, “ SELECT ”, “ INSERT ”, “ UPDATE ”, “ SLEEP( “, “ BENCHMARK( “, des marqueurs de commentaire en ligne comme “ – ” ou “ /* ”).
- Limitez la longueur des paramètres pour les paramètres connus devant être de petits ID ou slugs.
- Ajoutez une limitation de taux et bloquez les IP qui frappent de manière répétée des points de terminaison vulnérables.
- Pour les sites publics/exposés à Internet, restreignez les points de terminaison sensibles du plugin aux IP de la liste blanche (administrateurs, serveurs de magasin).
- Surveillez et bloquez les requêtes avec des charges utiles SQL obfusquées (encodage hexadécimal, double encodage).
Important: Les règles WAF doivent être soigneusement définies pour éviter de bloquer le trafic légitime. Les règles spécifiques au plugin (basées sur le chemin du point de terminaison et les noms de paramètres) sont plus sûres que le blocage générique des mots-clés SQL.
Liste de contrôle en cas d'incident (si vous soupçonnez une compromission)
Si vous déterminez que votre site a été exploité ou si vous voyez des indicateurs de compromission, suivez un processus formel de réponse aux incidents :
- Isoler
- Mettez le site hors ligne ou mettez-le en mode maintenance pour arrêter d'autres dommages.
- Préserver les preuves
- Prenez des instantanés de fichiers et de bases de données, préservez les journaux et évitez de modifier le système plus que nécessaire.
- Identifiez l'étendue
- Déterminez quels comptes, fichiers et données ont été accédés ou modifiés.
- Contenir et éradiquer
- Désactivez les plugins vulnérables, supprimez les portes dérobées et nettoyez les fichiers malveillants. Utilisez des outils de suppression de logiciels malveillants vérifiés et un examen manuel.
- Rotation des identifiants
- Réinitialisez les mots de passe WordPress (tous les utilisateurs administrateurs), les mots de passe de la base de données, les clés API et toutes les informations d'identification tierces associées. Mettez à jour les sels (AUTH_KEY, etc.) dans wp-config.php.
- Restauration ou reconstruction propre
- Restaurez à partir d'une sauvegarde propre effectuée avant la compromission si une sauvegarde fiable existe. Sinon, reconstruisez le site à partir de sources propres et réimportez uniquement des données vérifiées et propres.
- Durcissement post-incident
- Appliquez des correctifs, examinez les journaux, augmentez la surveillance et mettez en œuvre des règles WAF et d'autres atténuations pour prévenir la réexploitation.
- Signaler
- Informez les clients concernés si des données ont été exposées et respectez les obligations légales et celles du fournisseur d'hébergement.
- Apprendre
- Effectuez une analyse des causes profondes et mettez à jour les procédures pour prévenir la récurrence.
Si vous n'êtes pas expérimenté en réponse aux incidents, engagez immédiatement un professionnel de la sécurité ou l'équipe d'incidents de votre fournisseur d'hébergement.
Durcissement et prévention à long terme
Au-delà des corrections immédiates, suivez ces meilleures pratiques pour réduire le risque futur :
- Gardez le cœur de WordPress, les thèmes et les plugins à jour. Appliquez les mises à jour de sécurité rapidement.
- Désactivez et supprimez les plugins et thèmes inutilisés.
- Maintenez le principe du moindre privilège : minimisez le nombre d'utilisateurs administrateurs, utilisez des rôles granulaires et évitez les comptes administrateurs partagés.
- Appliquez une authentification forte :
- Utilisez des mots de passe forts, des gestionnaires de mots de passe et activez l'authentification à deux facteurs pour les utilisateurs administrateurs.
- Désactiver l'édition de fichiers dans le tableau de bord :
définir( 'DISALLOW_FILE_EDIT', vrai ); - Renforcer les permissions de fichiers :
- Utilisez des permissions sécurisées pour wp-config.php, les téléchargements et les dossiers de plugins.
- Sauvegardes régulières :
- Maintenez des sauvegardes automatisées hors site avec versioning et testez régulièrement les restaurations.
- Surveillance et journalisation de la sécurité :
- Conservez les journaux, mettez en œuvre des alertes sur les événements suspects et examinez-les périodiquement.
- Revue de code de sécurité :
- Si vous créez des plugins ou des thèmes personnalisés, effectuez des revues de code sécurisées, une analyse statique et des vérifications de dépendances.
- Environnement de staging :
- Testez les mises à jour et les correctifs de sécurité en environnement de staging avant de les appliquer en production.
Ces pratiques réduisent la probabilité et l'impact des vulnérabilités futures.
Exemple : Accès aux données non sécurisé vs sécurisé (conceptuel)
Modèle non sécurisé (ne PAS utiliser) :
// Vulnérable : concatène l'entrée utilisateur directement dans SQL;
Modèle sécurisé (utiliser $wpdb->prepare et assainir) :
global $wpdb;
Pour les entrées de chaîne, assainir et utiliser %s:
$sku = isset( $_GET['sku'] ) ? sanitize_text_field( wp_unslash( $_GET['sku'] ) ) : '';
Ne jamais faire confiance à l'entrée fournie par le client ; toujours valider et préparer.
Comment WP-Firewall aide (protection gérée et patching virtuel)
Chez WP-Firewall, nous protégeons les sites WordPress à plusieurs niveaux :
- WAF géré : nous pouvons déployer des patchs virtuels qui bloquent les modèles d'exploitation connus pour cette vulnérabilité eMagicOne (et d'autres vulnérabilités) jusqu'à ce qu'un patch officiel du plugin soit disponible.
- Analyseur de logiciels malveillants : analyse en continu les fichiers et la base de données à la recherche d'indicateurs de compromission.
- Les 10 principales mesures d'atténuation selon l'OWASP : règles pour réduire les risques d'injection, XSS, CSRF et autres menaces courantes.
- Protection de la bande passante : protège contre le trafic de scan automatisé de masse qui précède souvent les attaques.
- Notifications et informations sur les incidents : journaux exploitables et alertes lorsque des modèles de requêtes suspects sont détectés.
Si vous gérez plusieurs sites ou des sites clients, le patching virtuel via un WAF géré est souvent le moyen le plus rapide de réduire l'exposition pendant que vous coordonnez la sortie d'un plugin patché et testez votre environnement.
Protégez votre site aujourd'hui — WP-Firewall Basic (Gratuit)
Commencez à protéger votre site immédiatement avec le plan de base (gratuit) de WP-Firewall. Il comprend les protections essentielles dont tout le monde a besoin :
- Protection essentielle : pare-feu géré et bande passante illimitée
- Règles de pare-feu d'application web (WAF)
- Analyseur de logiciels malveillants
- Atténuation des 10 principaux risques de l'OWASP
Si vous souhaitez une suppression automatique des logiciels malveillants et plus de contrôle, notre plan Standard (payant) ajoute la suppression automatique des logiciels malveillants et des listes d'autorisation/blockage IP. Pour les organisations qui ont besoin de rapports complets et de patching virtuel automatique à grande échelle, le plan Pro fournit des rapports de sécurité mensuels, un patching virtuel automatique des vulnérabilités et des modules complémentaires premium, y compris un gestionnaire de compte dédié et un service de sécurité géré.
Inscrivez-vous ici au forfait gratuit :
https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Chronologie de remédiation recommandée
- Maintenant (0–1 heure)
- Détecter si le plugin est installé, désactiver le plugin si possible, prendre un instantané hors ligne, faire pivoter les identifiants.
- Court terme (1–24 heures)
- Appliquer un correctif virtuel WAF ou une restriction d'accès au niveau du serveur aux points de terminaison du plugin, scanner pour des compromissions, contacter les équipes d'hébergement/IT.
- Moyen terme (1–7 jours)
- Appliquer le correctif officiel lorsque le fournisseur le publie, ou mettre à jour vers une version de plugin corrigée. Si le correctif officiel n'est pas disponible, coordonner avec le fournisseur du plugin pour un correctif ou retirer/remplacer le plugin.
- Long terme (semaines)
- Réaliser un examen post-incident, renforcer la posture de sécurité et appliquer la liste de contrôle de durcissement ci-dessus.
Réflexions finales de l'équipe de sécurité de WP-Firewall
L'injection SQL non corrigée et non authentifiée est l'un des moyens les plus rapides d'une compromission complète du site. Lorsqu'une vulnérabilité comme CVE-2026-42773 est divulguée, la rapidité est essentielle : les acteurs de la menace ajoutent souvent de telles failles aux scanners automatisés en quelques heures. Pour chaque propriétaire de site et développeur, la priorité est la containment et la protection — désactiver ou restreindre le chemin de code vulnérable, appliquer un correctif virtuel avec un WAF pendant que vous préparez et testez une mise à jour de code appropriée, et effectuer un scan et une validation approfondis avant de remettre le site en production.
Si vous avez besoin d'aide pour mettre en œuvre des atténuations, configurer des règles WAF ou effectuer une réponse à un incident, notre équipe de sécurité chez WP-Firewall est disponible pour aider. Même notre plan gratuit fournit une protection WAF essentielle et un scan de malware qui peut bloquer de nombreuses tentatives d'exploitation automatisées.
Restez en sécurité : les inventaires de plugins installés, les politiques de mise à jour automatisées et un WAF fiable sont les trois étapes pratiques qui réduisent le risque des vulnérabilités massivement exploitées.
Références et ressources
- Détails CVE : CVE-2026-42773 (liste publique)
- Docs de développement WordPress : $wpdb, $wpdb->prepare, register_rest_route, permission_callback
- OWASP Top 10 : catégorie Injection
(Si vous avez trouvé ce post utile, ajoutez-le à vos favoris et revenez pour des mises à jour — nous publierons des règles d'atténuation et des conseils techniques au fur et à mesure que d'autres détails et correctifs officiels deviennent disponibles.)
