Une vulnérabilité dans la bibliothèque better-auth pourrait permettre à des attaquants de prendre le contrôle de comptes utilisateur sans jamais se connecter.
La faille affecte le module de clés API de la bibliothèque et permet à des attaquants non authentifiés de générer des clés API dotées de privilèges pour n’importe quel utilisateur.
L’exploitation de la vulnérabilité accorde « … un accès authentifié complet en tant que l’utilisateur ciblé et, selon ses privilèges, pourrait entraîner la compromission du compte, l’accès à des données sensibles ou une prise de contrôle plus étendue de l’application », ont déclaré les chercheurs dans l’avis.
Le contournement de l’authentification dans better-auth
La bibliothèque better-auth totalise environ 300 000 téléchargements hebdomadaires sur npm.
Dans certains environnements, les clés API servent de jetons d’authentification persistants pour l’automatisation, les intégrations et la communication de service à service.
Contrairement aux connexions interactives, les clés API contournent souvent l’authentification multifacteur (MFA) et restent valides longtemps après la déconnexion d’un utilisateur. Si elle est compromise, une seule clé peut permettre à des attaquants d’automatiser l’accès à des données sensibles, de déclencher des workflows côté serveur ou d’usurper l’identité d’utilisateurs privilégiés à grande échelle.
Fonctionnement de CVE-2025-61928
La vulnérabilité, suivie sous l’identifiant CVE-2025-61928, provient d’une logique d’autorisation défaillante dans les gestionnaires createApiKey et updateApiKey du module de clés API.
Ces gestionnaires déterminent si une authentification est requise en vérifiant l’existence d’une session valide et en évaluant si un champ userId est présent dans le corps de la requête.
Dans des conditions normales, le système devrait déduire l’utilisateur à l’origine de l’action à partir d’une session validée avant d’autoriser la création ou la modification d’une clé.
Cependant, lorsqu’aucune session authentifiée n’existe mais qu’un userId est fourni dans la charge utile JSON, l’application considère à tort qu’aucune authentification n’est nécessaire.
Au lieu de rejeter la requête, le gestionnaire construit directement le contexte utilisateur à partir de données contrôlées par l’attaquant.
Comme les routines de validation côté serveur ne s’exécutent que lorsqu’une authentification est requise, cette faille dans le flux de contrôle contourne les garde-fous conçus pour protéger des champs privilégiés tels que permissions, rateLimitMax, remaining et refillAmount.
Exploitation et impact réel
Par conséquent, un attaquant peut envoyer une seule requête POST à /api/auth/api-key/create contenant le userId d’une victime et recevoir une clé API valide liée à ce compte.
La même faille logique affecte /api/auth/api-key/update, ce qui permet de modifier des clés existantes sans autorisation. L’exploitation nécessite uniquement de connaître ou d’énumérer un identifiant utilisateur valide, ce qui rend la complexité de l’attaque faible.
En pratique, il s’agit d’un contournement de l’authentification dû à une validation incorrecte des entrées et à une dérivation défaillante du contexte utilisateur.
Avec une clé API valide, un attaquant peut s’authentifier en tant que l’utilisateur ciblé, contourner les protections MFA et potentiellement accroître l’impact selon les privilèges du compte.
Une version corrigée de better-auth a été publiée pour rectifier le contrôle d’autorisation.
Mesures pour réduire le risque d’utilisation abusive des clés API
Face à ce contournement de l’authentification, les organisations devraient prendre des mesures pour réduire les risques et confirmer l’intégrité des systèmes concernés.
La résolution du problème devrait aller au-delà de l’installation du correctif et inclure la gestion des identifiants, la surveillance et l’amélioration des pratiques de gouvernance.
Comme les clés API servent souvent de jetons d’accès persistants, toute création ou modification non autorisée peut rester effective jusqu’à sa révocation explicite.
- Mettez à niveau better-auth vers la dernière version et vérifiez que le correctif est correctement déployé dans tous les environnements.
- Faites pivoter toutes les clés API générées pendant la période d’exposition potentielle, invalidez les identifiants inutilisés ou obsolètes et rééditez les clés des comptes à privilèges élevés si nécessaire.
- Examinez les journaux de l’application et du proxy inverse pour y rechercher les requêtes non authentifiées vers /api/auth/api-key/create ou /api/auth/api-key/update, et surveillez toute activité API suspecte provenant d’adresses IP ou de jetons de service inconnus.
- Appliquez strictement le principe du moindre privilège et limitez les autorisations des clés API, mettez en place des politiques d’expiration des clés et exigez une réauthentification ou une MFA renforcée pour les opérations sensibles de création ou de modification de clés.
- Appliquez une limitation de débit, des alertes et une détection des abus lors de la création de clés API et de la mise à jour des points de terminaison afin d’identifier les tentatives d’énumération ou les schémas d’automatisation anormaux.
- Renforcez la gouvernance des dépendances en activant l’analyse de la composition logicielle (SCA), en surveillant les avis de sécurité et en tenant à jour la liste des composants logiciels (SBOM).
- Testez les plans de réponse aux incidents en prévision de scénarios de contournement de l’authentification et d’utilisation abusive d’identifiants.
Ensemble, ces mesures peuvent aider les organisations à limiter le rayon d’action d’une éventuelle utilisation abusive d’identifiants et à renforcer leur résilience.
Risques liés aux bibliothèques d’authentification tierces
CVE-2025-61928 montre comment des problèmes de logique d’autorisation dans des bibliothèques largement utilisées peuvent affaiblir les contrôles d’authentification et introduire des risques dans les environnements applicatifs.
Alors que les organisations continuent de dépendre des intégrations pilotées par API et des composants tiers, une validation cohérente du contexte utilisateur, une gestion rigoureuse des identifiants et une surveillance continue restent des garde-fous importants.
Les risques liés aux bibliothèques tierces incitent les organisations à adopter des solutions zero-trust qui vérifient en continu l’identité et réduisent la confiance implicite entre les applications et les services.