Nom du plugin	Moteur IA
Type de vulnérabilité	L'escalade de privilèges
Numéro CVE	CVE-2026-8719
Urgence	Haut
Date de publication du CVE	2026-05-18
URL source	CVE-2026-8719

Élévation de privilèges dans le Moteur IA (CVE-2026-8719) : Ce que les propriétaires de sites WordPress doivent savoir — Analyse d'expert et atténuation pratique

Date: 18 mai 2026
Auteur: Équipe de sécurité WP-Firewall

Résumé: Une vulnérabilité d'élévation de privilèges de haute sévérité (CVE-2026-8719, CVSS 8.8) a été divulguée dans le plugin Moteur IA (versions vulnérables 3.4.9). Un compte authentifié de niveau abonné peut exploiter des vérifications d'autorisation insuffisantes pour élever ses privilèges. Le fournisseur a publié un correctif dans la version 3.5.0. Cet article explique la vulnérabilité, démontre comment les attaquants abusent généralement de telles failles, et fournit des conseils d'atténuation, de détection et de récupération immédiats et à long terme adaptés aux propriétaires de sites WordPress et aux développeurs. En tant que fournisseur de sécurité WordPress, nous décrivons également comment un pare-feu d'application Web géré et un patch virtuel peuvent protéger votre site pendant que vous mettez à jour.

---

Pourquoi cela importe (réponse courte)

• Versions vulnérables : 3.4.9 (3.4.9 — vulnérable)
• Corrigé dans : 3.5.0
• CVE : CVE-2026-8719
• Gravité: Élevé (CVSS 8,8)
• Privilège requis pour exploiter : Abonné (utilisateur authentifié à faible privilège)
• Classification: Élévation de privilèges / Échecs d'identification et d'authentification

Un abonné est le rôle authentifié le moins privilégié sur la plupart des sites WordPress. Une faille qui permet à un abonné d'élever ses privilèges permet effectivement à un attaquant de contourner la sécurité au niveau du compte et d'obtenir un contrôle administratif. Cela ouvre la porte à une compromission totale du site (portes dérobées, exfiltration de données, empoisonnement SEO par spam, redirections monétisées, destruction de type ransomware, et plus encore).

---

Ce qui a probablement mal tourné (cause racine technique — expliquée)

D'après les informations publiées par les chercheurs et les modèles communs dans les vulnérabilités des plugins WordPress, il s'agit très probablement d'un échec de vérification d'autorisation/de permission. En termes simples :

• Le plugin expose une action (via admin-ajax.php, un point de terminaison REST, ou d'autres gestionnaires internes) qui effectue une opération sensible — par exemple, modifier des capacités, mettre à jour des rôles d'utilisateur, écrire des options privilégiées, ou activer des intégrations — mais échoue à valider que l'utilisateur appelant a la capacité appropriée.
• Le gestionnaire soit :
  • Omet un appel à current_user_can( 'gérer_options' ) ou une vérification de capacité équivalente, ou
  • Utilise une vérification non sécurisée (par exemple, vérifiant seulement que l'utilisateur est authentifié, pas qu'il a une capacité spécifique), ou
  • Se fie uniquement à un nonce ou à des données fournies par le client sans vérification appropriée côté serveur.

Lorsqu'un abonné peut envoyer une requête spécialement conçue à ce gestionnaire et que le serveur effectue l'action sensible sans vérifications autoritaires, l'élévation suit.

Modèles de manifestation courants :

• Route REST avec permission_callback retournant true pour les utilisateurs authentifiés ou non appliquée.
• Action admin-ajax appelable par tout utilisateur connecté (vérifications de capacité manquantes).
• Options ou métadonnées utilisateur mises à jour en utilisant des valeurs fournies par l'utilisateur sans assainissement ni vérification.
• Élévation de privilèges en créant ou en mettant à jour un enregistrement utilisateur pour inclure des capacités d'administrateur.

---

Scénarios d'exploitation et impact dans le monde réel

Si un attaquant peut élever un compte d'abonné à un compte d'administrateur, l'impact est sévère :

• Créer des comptes administrateurs backdoor et persister l'accès.
• Installer des plugins ou des thèmes malveillants qui exécutent du PHP arbitraire.
• Modifier les fichiers de thème pour injecter du spam SEO, des mineurs de cryptomonnaie ou des pages de phishing.
• Voler des données sensibles : listes de clients, entrées de formulaires, clés API, informations de paiement.
• Utiliser le site comme partie d'un botnet ou pour héberger du contenu malveillant.
• Forcer des changements au niveau administrateur tels que modifier les URL du site, rediriger les visiteurs ou supprimer des sauvegardes.
• Mouvement latéral vers d'autres systèmes connectés (par exemple, CRM, services de messagerie) si des identifiants ou des jetons sont stockés sur le site.

Parce qu'un compte d'abonné est facile à obtenir — soit en s'inscrivant sur des sites ouverts, soit en compromettant un utilisateur à faible privilège — cette vulnérabilité est attrayante pour une exploitation de masse et un scan automatisé. Les attaquants scannent souvent de nombreux sites à la recherche d'une version de plugin vulnérable et tentent un payload automatisé pour créer un utilisateur administrateur ou changer des capacités.

---

Actions immédiates pour les propriétaires de sites (étape par étape)

Si vous gérez un site WordPress, suivez ces étapes immédiatement. Considérez cela comme la liste de contrôle de triage.

1. Vérifiez la version du plugin
   • Dans WP Admin → Plugins, vérifiez la version de AI Engine. Si elle est 3.4.9 (ou toute version antérieure à 3.5.0), considérez-la comme vulnérable.
2. Mettez à jour le plugin immédiatement (recommandé)
   • Mettez à jour AI Engine vers 3.5.0 ou une version ultérieure. C'est la solution la plus simple et la plus fiable.
3. Si vous ne pouvez pas mettre à jour immédiatement, appliquez des mesures d'atténuation temporaires :
   • Désactivez temporairement le plugin AI Engine. Cela élimine le chemin de code vulnérable.
   • Restreignez ou désactivez les inscriptions publiques (Paramètres → Général → Adhésion) si votre site permet la création de comptes visiteurs.
   • Forcez une authentification à deux facteurs ou plus forte pour tous les comptes administrateurs.
   • Limitez la capacité des abonnés à accéder aux formulaires front-end qui soumettent aux points de terminaison du plugin (par exemple, paramètres utilisateur, formulaires de commentaire).
4. Passez en revue les utilisateurs et les autorisations
   • Inspectez tous les comptes avec des privilèges administratifs.
   • Utilisez WP-CLI ou la base de données pour trouver des utilisateurs avec la capacité d'administrateur :
     • wp user list --role=administrator
     • SQL :

       SELECT u.ID, u.user_login, m.meta_value FROM wp_users u JOIN wp_usermeta m ON u.ID = m.user_id WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%';

   • Si vous trouvez des comptes administratifs inattendus, désactivez-les (définissez user_pass sur une valeur aléatoire, ou changez le rôle en abonné) et conservez une copie des détails du compte pour une analyse ultérieure.
5. Faites tourner les secrets à forte utilisation
   • Changez les mots de passe des utilisateurs administrateurs.
   • Révoquez et régénérez les clés API stockées sur le site (intégrations tierces, services de paiement).
   • Si des attaquants ont pu avoir un accès administrateur pendant un certain temps, faites tourner les identifiants de la base de données et d'autres secrets sensibles, puis mettez à jour wp-config.php en conséquence.
6. Scannez et surveillez les signes de compromission
   • Exécutez des analyses approfondies de logiciels malveillants contre le système de fichiers.
   • Contrôler /wp-content/téléchargements/ et les répertoires de thèmes/plugins pour les fichiers PHP (les téléchargements ne devraient pas avoir de PHP).
   • Vérifiez les fichiers récemment modifiés :

     find . -type f -mtime -n

     (remplacer n avec des jours) pour identifier les changements récents.

   • Contrôler wp_posts pour du contenu ou des pages indésirables insérées.
   • Passez en revue les crons via wp-cron ou le crontab du serveur.
7. Restaurez à partir d'une sauvegarde propre si un compromis est confirmé.
   • Si vous identifiez des signes de compromission (utilisateurs administrateurs inconnus, webshells, fichiers de thème altérés), restaurez à partir d'une sauvegarde effectuée avant la compromission.
   • Après la restauration, mettez à jour le plugin, auditez les utilisateurs et les plugins, et faites tourner les identifiants.

---

Si vous ne pouvez pas mettre à jour ou désactiver le plugin — mesures d'atténuation efficaces

Si une mise à jour immédiate n'est pas possible (pour des tests de compatibilité, validation de staging, ou contraintes commerciales), appliquez ces mesures d'atténuation :

• Appliquez un patch virtuel via un WAF
   - Bloquez toutes les requêtes ciblant les points de terminaison AJAX et REST administratifs du plugin provenant de comptes non fiables.
   - Bloquez les requêtes qui tentent de définir des rôles d'utilisateur ou d'envoyer des charges utiles suspectes (voir les règles de détection ci-dessous).
   - Limitez le nombre de requêtes aux points de terminaison des plugins pour ralentir les exploits automatisés.
• Renforcez l'enregistrement des utilisateurs et les rôles
   - Désactivez l'enregistrement public.
   - Exigez l'approbation de l'administrateur pour la création de nouveaux comptes.
   - Utilisez CAPTCHA et vérification par e-mail pour les enregistrements.
• Renforcez la configuration du site
   - Restreignez les permissions d'écriture sur les répertoires des plugins au niveau du système de fichiers.
   - Désactivez l'exécution de PHP dans les téléchargements (par exemple, en utilisant .htaccess ou la configuration du serveur web).
   - Assurez-vous que la surveillance de l'intégrité des fichiers est activée (détecter les modifications non autorisées).
• Auditez et surveillez les journaux
   - Activez WP_DEBUG_LOG temporairement (pas en production pendant longtemps) ou configurez la journalisation au niveau du serveur des requêtes POST/REST.
   - Surveillez les requêtes POST provenant de comptes à faible privilège vers les points de terminaison des plugins.

Rappelez-vous : ces mesures réduisent le risque d'exploitation mais ne remplacent pas l'application du correctif officiel.

---

Comment un WAF géré aide (ce à quoi s'attendre de WP-Firewall)

Un pare-feu d'application web géré offre plusieurs avantages pendant que vous mettez à jour :

• Patching virtuel
  Le WAF peut mettre en œuvre un blocage basé sur des règles pour les signatures d'exploit spécifiques, empêchant efficacement les modèles d'attaque connus d'atteindre votre site.
• Détection basée sur la signature
  Bloquez les charges utiles d'attaque connues (tentatives de définir wp_capabilities, de créer des utilisateurs administrateurs ou d'appeler des points de terminaison de plugins spécifiques avec des paramètres suspects).
• Protection basée sur le comportement
  Détectez et bloquez les comportements anormaux des comptes authentifiés à faible privilège (par exemple, un abonné frappant à plusieurs reprises les points de terminaison administratifs).
• Limitation de débit et protection contre les bots
  Bloquez les campagnes de balayage massif et d'exploitation.
• Atténuations d'urgence
  Des règles immédiates peuvent être appliquées pour bloquer la vulnérabilité pendant que vous appliquez le correctif officiel.
• Surveillance et alertes
  Alertes en temps réel pour les activités suspectes et journalisation automatisée pour aider au triage.

Si vous gérez plusieurs sites, un WAF géré peut appliquer des correctifs virtuels et des règles d'atténuation sur l'ensemble de votre flotte, réduisant considérablement le temps d'exposition.

---

Indicateurs de compromission (IoCs) à rechercher

Si vous soupçonnez une exploitation, recherchez les éléments suivants :

• Horodatages de création de compte admin inattendus (surtout peu avant ou après une demande de plugin).
• Insertion/mise à jour de base de données dans le wp_usermeta tableau avec ‘wp_capabilities’ contenant ‘administrator’.
• Requêtes dans les journaux montrant POST/PUT à admin-ajax.php ou /wp-json/* depuis des comptes d'abonnés.
• Modifications inhabituelles des fichiers de thème, des fichiers de plugin ou des fichiers principaux (horodatages, tailles de fichiers modifiées).
• Nouveaux travaux WP-Cron programmés ou entrées cron personnalisées ajoutées au serveur.
• Fichiers suspects dans les téléchargements (par exemple, fichiers avec extension .php dans les téléchargements).
• Connexions sortantes ou recherches DNS depuis le site que vous ne prévoyez pas.
• Changements SEO soudains ou pages de contenu spam créées.

Requêtes utiles :

• WP-CLI pour lister les utilisateurs admin récemment créés :

  wp user list --role=administrator --fields=ID,user_login,user_registered --format=csv

• SQL pour trouver les fichiers PHP récemment modifiés (nécessite des métadonnées de modification de fichier stockées ou des journaux de serveur) — vérifiez les journaux de fichiers de votre fournisseur d'hébergement ou utilisez trouvez:

  find /path/to/wordpress -type f -name '*.php' -mtime -7 -ls

---

Pour les développeurs : comment corriger le code et éviter les futurs bugs d'escalade de privilèges.

Voici des recommandations de codage spécifiques et des exemples pour prévenir les problèmes d'autorisation.

1. Utilisez des vérifications de capacité — ne faites jamais confiance au côté client
   Toujours utiliser current_user_can() ou des vérifications de capacité appropriées pour les opérations de niveau administrateur.
   Exemple (gestionnaire admin-ajax) :

add_action( 'wp_ajax_my_plugin_do_sensitive_action', 'my_plugin_do_sensitive_action' );

2. Vérifiez les nonces et utilisez check_ajax_referer / wp_verify_nonce
   Les nonces ne sont pas une vérification de permission, mais ils protègent contre le CSRF lorsqu'ils sont combinés avec des vérifications de capacité.
   Exemple pour la route REST :

register_rest_route( 'my-plugin/v1', '/sensitive', array(;

3. Principe du moindre privilège
   N'autorisez que la capacité minimale nécessaire. Pour les paramètres du site, utilisez gérer_options; pour l'édition des articles, utilisez edit_posts; pour la création d'utilisateurs, utilisez créer_utilisateurs.
   Évitez de mapper “ authentifié ” à “ autorisé ” par défaut.
4. Assainissez et validez toutes les entrées
   N'acceptez jamais aveuglément les valeurs de rôle ou de capacité des paramètres de requête.
   Exemple:

$role = sanitize_text_field( $request['role'] );

5. Évitez de stocker des capacités ou des rôles dans des champs personnalisés spécifiques au plugin sans vérification côté serveur
   Si votre plugin permet des changements de rôle, mettez en œuvre une politique et un journal de vérification côté serveur.
6. Auditer les bibliothèques et points de terminaison tiers
   Tout chemin de code qui appelle des services externes ou modifie des utilisateurs/options doit passer les mêmes vérifications.
7. Mettez en œuvre des flux de travail d'approbation des changements de rôle
   Si votre site nécessite une élévation de rôle (par exemple, une mise à niveau d'adhésion), mettez en œuvre des processus d'approbation admin plutôt que des changements directs pilotés par l'utilisateur.
8. Journalisation et alertes
   Enregistrez les tentatives d'accès aux points de terminaison sensibles et les changements de capacité anormaux. Assurez-vous que les journaux sont stockés hors site ou dans un emplacement central sécurisé.

---

Règles de détection et exemples de signatures WAF

Bien que les charges utiles d'exploitation exactes diffèrent, vous pouvez mettre en œuvre des règles générales pour bloquer les tentatives d'exploitation probables :

• Bloquer les requêtes POST vers admin-ajax.php ou des points de terminaison REST qui incluent des paramètres de charge utile tels que :
  • “role=administrator”
  • “capabilities” ou “wp_capabilities”
  • “user_pass” ou “user_login” utilisés pour créer un admin sans privilèges admin
• Détectez les tentatives de mise à jour user_meta de clés comme 'wp_capabilities' à partir des REST/actions initiées par des utilisateurs à faible privilège.
• Limitez le taux ou bloquez les IP effectuant de nombreuses requêtes POST vers les points de terminaison de plugin dans une courte fenêtre de temps.
• Exemple de règle WAF conceptuelle (pseudo) :
  SI request.method == POST ET request.uri CONTIENT ‘/wp-json/’ ET request.body CONTIENT ‘wp_capabilities’ ET user.role == 'abonné' ALORS bloquez

Important: les règles doivent être testées sur la mise en scène pour éviter les faux positifs. Les pare-feu gérés peuvent déployer ces règles en toute sécurité et revenir en arrière si nécessaire.

---

Liste de contrôle post-incident et de récupération (détaillée)

Si vous avez confirmé un compromis, suivez cette séquence d'escalade :

1. Isoler
   Mettez le site hors ligne si nécessaire (mode maintenance) pour arrêter d'autres dommages.
2. Préserver les preuves
   Copiez les journaux (serveur web, application), les instantanés de base de données et l'ensemble du système de fichiers pour une analyse judiciaire.
3. Restaurer
   Restaurez à partir d'une sauvegarde connue propre effectuée avant le compromis.
4. Corriger et sécuriser
   Mettez à jour le cœur de WordPress, les plugins (AI Engine à 3.5.0+) et les thèmes.
   Renforcez le site : désactivez l'édition de fichiers dans wp-config.php (définir('DISALLOW_FILE_EDIT', vrai);), appliquez des mots de passe administratifs forts, activez l'authentification à deux facteurs.
5. Rotation des identifiants
   Réinitialisez les mots de passe des utilisateurs administrateurs, les mots de passe de la base de données et toutes les clés API stockées sur le site.
6. Audit
   Scannez à la recherche de webshells et de fichiers malveillants.
   Utilisez la surveillance de l'intégrité des fichiers pour comparer les fichiers restaurés avec les copies originales.
   Passez en revue les tâches planifiées et options_wp pour des entrées suspectes.
7. Informer les parties prenantes
   Si des données clients ou utilisateurs ont été exposées, suivez les règles de notification de violation applicables (juridiques/conformité).
8. Moniteur
   Après la restauration, surveillez les journaux pour toute tentative de réinfection ou accès non autorisé.

---

Renforcement à long terme : réduisez le rayon d'explosion des vulnérabilités des plugins

• Limitez l'utilisation des plugins à des extensions de confiance et bien entretenues. Supprimez les plugins que vous n'utilisez pas.
• Testez les mises à jour des plugins sur la mise en scène avant de les déployer en production, mais planifiez des mises à jour en temps opportun.
• Restreignez l'enregistrement de nouveaux utilisateurs sauf si nécessaire.
• Appliquez des mots de passe forts et une authentification à deux facteurs pour tous les utilisateurs privilégiés.
• Appliquez le principe du moindre privilège pour tous les comptes et les jetons API.
• Utilisez un WAF géré et un service de surveillance pour recevoir des correctifs virtuels pour les problèmes de jour zéro.
• Maintenez des sauvegardes régulières stockées hors site et testez les procédures de restauration.
• Créez un plan de réponse aux incidents et réalisez des exercices de simulation avec votre équipe.

---

Comment confirmer que vous êtes à jour (vérification rapide)

1. Version du plugin
   WP Admin → Plugins : AI Engine doit afficher la version 3.5.0 ou supérieure.
2. Testez une opération critique (en staging)
   Essayez d'effectuer des opérations privilégiées tout en étant connecté en tant qu'abonné dans un environnement de staging contrôlé. Le comportement correct est d'être bloqué ou de recevoir une erreur de permissions.
3. Vérifiez les règles WAF
   Confirmez que votre WAF (si vous en utilisez un) a les règles de correctifs virtuels supprimées après l'application de la mise à jour ou qu'elles sont réglées en mode alerte uniquement si elles ne sont plus nécessaires.

---

Liste de contrôle pour les développeurs afin d'éviter les futures failles d'escalade de privilèges

• Chaque action sensible doit vérifier current_user_can() et assainir les entrées.
• Les points de terminaison REST doivent inclure permission_callback qui renvoie un booléen basé sur les vérifications de capacité.
• Les nonces doivent être validés côté serveur pour admin-ajax et les publications front-end.
• Évitez d'exposer des fonctionnalités administratives via des points de terminaison accessibles par tout utilisateur authentifié.
• Documentez la capacité minimale requise pour chaque route API ou action AJAX.
• Ajoutez des tests automatisés qui vérifient que les points de terminaison sont bloqués pour les utilisateurs à faible privilège.
• Auditez régulièrement le code et les dépendances tiers.

---

“ Commencez à protéger avec un plan de pare-feu géré gratuit ” — pourquoi cela a du sens maintenant

Si vous recherchez une protection immédiate pendant que vous mettez à jour et validez les modifications de plugin, envisagez notre plan gratuit géré. Le plan gratuit de base fournit des protections essentielles — un pare-feu géré, une bande passante illimitée, un WAF, un scanner de logiciels malveillants et une atténuation des risques OWASP Top 10 — qui sont particulièrement précieuses lorsqu'une vulnérabilité de plugin est découverte. Il vous offre un filet de sécurité pratique : un patch virtuel et une atténuation basée sur des règles qui peuvent bloquer les tentatives d'exploitation de manière proactive, réduire les fenêtres d'exposition et vous donner le temps nécessaire pour mettre à jour, auditer et récupérer.

Prêt à commencer ? Inscrivez-vous au plan gratuit WP-Firewall ici :
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Points forts du plan (référence rapide)

• Basique (gratuit) : pare-feu géré, bande passante illimitée, WAF, scanner de logiciels malveillants, atténuation pour OWASP Top 10.
• Standard ($50/an) : ajoute la suppression automatique de logiciels malveillants et le blocage/liste blanche d'IP (jusqu'à 20 IP).
• Pro ($299/an) : inclut des rapports de sécurité mensuels, un patch virtuel automatique et des modules complémentaires premium (Gestionnaire de compte dédié, Optimisation de la sécurité, Jeton de support WP, Service WP géré, Service de sécurité géré).

Un pare-feu géré fournit une protection immédiate pendant que vous appliquez des correctifs et auditez votre environnement. C'est une couche de sécurité à faible coût avec des avantages mesurables pendant les périodes à haut risque.

---

Foire aux questions (FAQ)

Q : Dois-je désactiver immédiatement l'AI Engine ?
R : L'option la plus sûre est de mettre à jour vers la version corrigée (3.5.0+) immédiatement. Si vous ne pouvez pas mettre à jour pour une raison quelconque, désactiver temporairement le plugin est une atténuation à court terme solide.

Q : Un abonné peut-il vraiment obtenir un accès administrateur ?
R : Oui — lorsque les vérifications d'autorisation sont manquantes ou défectueuses, des données contrôlées par un attaquant peuvent être utilisées pour définir des privilèges. Un abonné est considéré comme un utilisateur authentifié, rendant ces attaques plus susceptibles de réussir que celles non authentifiées.

Q : Un WAF empêchera-t-il tous les risques ?
R : Un WAF est une atténuation puissante, surtout avec le patch virtuel, mais ce n'est pas un substitut à l'application de correctifs de sécurité officiels. Les WAF réduisent le risque et achètent du temps ; les mises à jour éliminent la cause profonde.

Q : Que faire si je trouve un utilisateur administrateur inattendu ?
R : Désactivez immédiatement le compte et préservez-le pour des analyses judiciaires. Auditez les fichiers et les journaux du site, faites tourner les identifiants et envisagez de restaurer à partir d'une sauvegarde propre si des indicateurs de compromission sont présents.

---

Recommandations finales — une liste de contrôle concise

• Mettez à jour l'AI Engine vers 3.5.0 ou une version ultérieure maintenant. C'est l'action la plus importante.
• Si vous ne pouvez pas mettre à jour immédiatement, désactivez le plugin ou activez la protection WAF gérée avec un patch virtuel.
• Auditez les rôles des utilisateurs et les modifications récentes des fichiers.
• Renforcez l'enregistrement des utilisateurs, appliquez l'authentification à deux facteurs pour les administrateurs et faites tourner les identifiants.
• Mettez en œuvre la journalisation, la surveillance et des analyses de logiciels malveillants programmées.
• Pour les développeurs : ajoutez des vérifications de capacité robustes, validez les entrées et implémentez permission_callback pour les routes REST.

---

Merci de votre lecture. Si vous gérez plusieurs sites WordPress ou avez besoin d'aide immédiate pour trier ce problème, notre équipe WP-Firewall peut fournir des correctifs virtuels, déployer des règles WAF sur vos instances et aider à la réponse aux incidents. Inscrivez-vous au plan gratuit pour obtenir une protection essentielle immédiatement : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Si vous souhaitez une liste de contrôle spécifique au site ou de l'aide pour exécuter les requêtes de détection et les étapes de récupération ci-dessus, nos spécialistes en sécurité peuvent jeter un œil — contactez-nous via votre tableau de bord WP-Firewall après vous être inscrit.