CVE-2026-103977

Résumé

Les versions de FileRise antérieures à 3.23.0 stockaient les tentatives de vérification TOTP échouées dans l'état de session PHP. Le compteur limitait les tentatives au sein d'une même session, mais ne persistait pas à travers les sessions nouvellement créées.

Un attaquant qui possède déjà le credential principal valide d'un compte cible pouvait redémarrer le workflow de connexion, recevoir une nouvelle session de connexion en attente, et restaurer l'allocation de tentatives TOTP. La répétition de ce processus permettait de continuer à deviner le TOTP en ligne au-delà de la limite prévue de cinq tentatives.

Détails

Le flux de vérification TOTP maintenait son compteur d'échecs dans $_SESSION. Après cinq soumissions échouées, les tentatives suivantes dans cette session renvoyaient HTTP 429.

Cependant, la réussite de l'authentification primaire dans une nouvelle session créait un nouvel état de connexion en attente avec un nouveau compteur d'échecs TOTP. Les échecs TOTP du compte précédent n'étaient donc pas reportés.

Le problème affectait également un autre gestionnaire TOTP de connexion en attente qui n'appliquait pas la même limite durable. La remédiation a par conséquent été appliquée de manière centralisée sur tous les chemins de vérification TOTP de connexion en attente.

Ce problème est classifié comme CWE-307 : Restriction inappropriée des tentatives d'authentification excessives.

Impact

L'exploitation nécessite la possession du credential principal valide du compte cible, tel qu'un mot de passe obtenu par réutilisation de credentials, hameçonnage, ou une autre compromission.

La vulnérabilité ne divulgue pas de credentials et ne contourne pas immédiatement le TOTP. Elle permet de continuer à deviner le TOTP de manière automatisée sans limite durable à l'échelle du compte. Une tentative réussie complète l'authentification avec les privilèges du compte affecté, potentiellement y compris les privilèges d'administrateur.

Les comptes sans TOTP activé ne sont pas affectés par ce problème spécifique de limitation de débit du second facteur.

Remédiation

FileRise 3.23.0 introduit une limitation centralisée et persistante des tentatives TOTP :

• Chaque compte est limité à cinq tentatives de vérification TOTP par fenêtre de 15 minutes.
• La limite du compte persiste à travers les sessions PHP et les changements d'adresse client.
• Une limite plus élevée à l'échelle de la source restreint les tentatives réparties entre les comptes.
• Les tentatives sont réservées avant la vérification en utilisant un état persistant verrouillé.
• Tous les chemins de vérification TOTP de connexion en attente utilisent le même limiteur.
• Une vérification TOTP réussie efface le budget de tentatives du compte.
• L'authentification par mot de passe ou par fournisseur d'identité ne réinitialise pas les échecs TOTP.

Les comptes existants, les secrets TOTP, les sessions, les installations Docker et la configuration de déploiement ne nécessitent aucune migration.

Les utilisateurs doivent mettre à niveau vers FileRise 3.23.0 ou une version ultérieure.

Réponse du mainteneur

Merci pour la divulgation responsable et les étapes de reproduction détaillées.

Nous avons examiné le workflow de vérification TOTP et confirmé le problème sous-jacent. Les soumissions TOTP échouées n'étaient limitées que par un compteur de session PHP dans le point de terminaison principal de vérification du frontend. Répéter l'étape réussie d'authentification primaire dans une nouvelle session pouvait donc restaurer le budget de tentatives du second facteur. Notre examen a également identifié un autre gestionnaire TOTP de connexion en attente qui n'appliquait pas le même compteur de tentatives, de sorte que la remédiation a été appliquée de manière centralisée sur les chemins de vérification plutôt que seulement sur le point de terminaison signalé.

Le correctif a été implémenté pour FileRise v3.23.0 :

• Les soumissions TOTP syntaxiquement valides réservent désormais une tentative à partir d'un budget persistant à l'échelle du compte avant la vérification.
• Le budget du compte est indépendant de la session PHP et de l'adresse client, de sorte que remplacer la session ou faire tourner les adresses sources ne restaure pas les tentatives.
• Un budget persistant plus élevé à l'échelle de la source limite les tentatives réparties entre les comptes.
• Les deux gestionnaires TOTP de connexion en attente utilisent le même limiteur, couvrant les sessions de connexion en attente établies par formulaire, Basic Auth et OIDC.
• Le succès par mot de passe ou par fournisseur d'identité ne réinitialise plus le budget d'échecs du second facteur.
• Une vérification TOTP réussie efface le budget du compte et retire la réservation réussie du budget de la source, de sorte que les utilisateurs ordinaires réussissant sur des réseaux partagés n'accumulent pas d'échecs.
• L'état des tentatives utilise des identifiants de compte/source hachés, des mises à jour verrouillées, un remplacement atomique de fichier, une expiration automatique, et une gestion fail-closed si le stockage du limiteur est indisponible ou corrompu.
• L'utilisation réussie d'un code de récupération efface l'état des tentatives TOTP du compte.

La limite du compte est de cinq tentatives dans une fenêtre de 15 minutes. La limite à l'échelle de la source est intentionnellement plus élevée, à 50 tentatives dans la même fenêtre, afin de réduire les faux positifs pour les réseaux partagés. Les comptes existants, les secrets TOTP, les sessions, les installations Docker et la configuration de déploiement ne nécessitent aucune migration.

---

Crédit : Pervin Zahidli (@ech0void ) Réf : https://github.com/error311/FileRise/security/advisories/GHSA-4hfj-6478-5cv7