Boucle 2FA cPanel 134.0.34 lors de l'accès aux comptes cPanel depuis WHM : bogue connu CPANEL-53684 et comment le corriger

Si vous administrez un serveur cPanel et que vous avez récemment mis à jour vers la version 11.134.0.34, vous avez peut-être remarqué un comportement étrange : lorsque vous (en tant que root ou en tant qu'utilisateur revendeur) essayez d'accéder directement au compte cPanel d'un client depuis votre session WHM, vous êtes invité de façon inattendue à entrer le code d'authentification à deux facteurs de votre propre utilisateur WHM. Pire encore, entrer un code 2FA valide ne termine pas la connexion. L'invite se contente de boucler, demandant un autre code, puis un autre, sans message d'erreur et sans chemin pour avancer. Cet article explique pourquoi cela se produit, le correctif officiel cPanel et ce qu'il faut faire si vous ne pouvez pas appliquer le correctif immédiatement.

Le symptôme en détail

Le bogue se manifeste dans un flux de travail spécifique qui est courant pour les administrateurs d'hébergement et les revendeurs : se connecter à WHM en tant que root ou en tant qu'utilisateur revendeur, naviguer vers un compte cPanel dans la liste et cliquer sur l'option pour accéder à l'interface cPanel de ce compte. Sur les versions affectées, ce flux de travail ne vous amène plus à la page d'accueil cPanel de l'utilisateur. À la place, il affiche l'invite 2FA de l'utilisateur WHM (celle pour la session WHM, pas la propre 2FA de l'utilisateur cPanel) et tout code que vous entrez est rejeté en étant redemandé.

Le bogue n'est pas un problème d'identifiants. Les codes 2FA que vous entrez sont corrects. Le bogue se trouve dans la logique de gestion de session cPanel introduite dans 11.134.0.34 qui évalue incorrectement l'état de vérification 2FA lors de la transition d'une session WHM vers une session utilisateur cPanel. La vérification réussit techniquement mais la machine d'état de session ne progresse pas à l'étape suivante, donc elle redemande la vérification indéfiniment.

Ce bogue n'affecte pas les connexions cPanel directes (où le client se connecte à son propre cPanel depuis la page de connexion publique). Il n'affecte que le chemin de transition WHM-vers-cPanel sur lequel les utilisateurs root et revendeurs comptent pour le travail de support.

La référence officielle cPanel

cPanel a confirmé qu'il s'agit d'un véritable bogue sous le cas développeur interne CPANEL-53684. L'article de support officiel cPanel documente le comportement et le chemin de correctif. Le bogue a été introduit dans 11.134.0.34 et corrigé dans 11.134.0.35. cPanel a également expédié des versions corrigées équivalentes sur les branches prises en charge qui étaient affectées, donc la résolution est disponible quelle que soit le niveau de version sur lequel votre serveur fonctionne.

Si votre hébergeur ou vous-même pouvez confirmer la version cPanel sur votre serveur, cela détermine si vous êtes affecté et quel est le chemin de correctif.

Comment vérifier votre version cPanel

En tant que root sur le serveur affecté :

/usr/local/cpanel/cpanel -V

Cela retourne une chaîne comme 11.134.0.34 ou 11.134.0.35 ou similaire. Si vous voyez 11.134.0.34, vous exécutez la version affectée. Si vous voyez 11.134.0.35 ou ultérieur, vous devriez déjà avoir le correctif. Si vous voyez une version d'une branche différente (11.110, 11.126, 11.136), vérifiez si votre version spécifique est la version corrigée pour cette branche.

Le correctif

cPanel a publié des versions corrigées pour chaque branche affectée. Le chemin de correctif recommandé dépend du niveau de version sur lequel votre serveur fonctionne :

• Branche 11.134 : mettre à jour vers 11.134.0.35 ou ultérieur
• Branche 11.136 : cPanel a expédié une version corrigée correspondante, vérifiez la page d'avis CPANEL-53684 de cPanel pour le numéro de version exact
• Branche 11.126 : cPanel a expédié une version corrigée correspondante, vérifiez la page d'avis pour le numéro de version exact
• Branche 11.110 ELS : une version corrigée est disponible pour cette branche Extended Lifecycle Support

La procédure de mise à jour est le flux de mise à jour cPanel standard. En tant que root :

/scripts/upcp --force

Le drapeau --force force une mise à jour immédiate via le flux de mise à niveau normal de cPanel, ignorant tout délai planifié. Une fois la mise à jour terminée, vérifiez le nouveau numéro de version avec /usr/local/cpanel/cpanel -V et confirmez qu'il correspond à la version corrigée pour votre branche.

Redémarrez cpsrvd après la mise à jour pour vous assurer que le code de gestion de session corrigé est chargé :

/scripts/restartsrv_cpsrvd

Puis testez le flux de travail WHM-vers-cPanel qui échouait. La boucle 2FA devrait être résolue.

Contournements si vous ne pouvez pas mettre à niveau immédiatement

Si vous ne pouvez pas mettre à jour maintenant (raisons de contrôle des changements, fenêtre de maintenance non disponible, préoccupations sur l'impact client de la mise à jour elle-même), voici les contournements disponibles. Aucun n'est idéal, et tous ont des compromis :

Contournement 1 : désactiver temporairement la 2FA sur le compte utilisateur WHM

C'est le contournement le plus fiable pour faire fonctionner à nouveau l'accès WHM-vers-cPanel, mais il désactive un contrôle de sécurité significatif pour la durée. Dans WHM, naviguez vers Account Information, puis Two-Factor Authentication et désactivez la 2FA pour votre utilisateur WHM. La transition WHM-vers-cPanel fonctionnera alors normalement car l'étape de vérification 2FA boguée n'est plus dans le chemin.

Réactivez la 2FA immédiatement après la mise à niveau vers une version corrigée. Si vous opérez avec plusieurs utilisateurs WHM (plusieurs admins ou revendeurs), vous pouvez désactiver la 2FA pour seulement les utilisateurs qui ont besoin d'effectuer des transitions WHM-vers-cPanel tout en la maintenant activée pour les autres.

Contournement 2 : utiliser la connexion cPanel directe à la place

Plutôt que de passer de WHM à cPanel, connectez-vous directement au compte cPanel du client en utilisant ses identifiants cPanel à l'URL cPanel orientée client. Cela contourne entièrement la transition WHM-vers-cPanel, donc le bogue ne se déclenche pas.

Le problème pratique est que cela exige que vous ayez le mot de passe cPanel du client, ce qui est un compromis de sécurité et opérationnel (vous ne devriez normalement pas connaître les mots de passe cPanel des clients, et réinitialiser les mots de passe chaque fois que vous avez besoin d'accès est intrusif pour le client). Utilisez le flux de réinitialisation de mot de passe cPanel seulement quand nécessaire, communiquez clairement avec le client et faites tourner le mot de passe une fois le travail terminé.

Contournement 3 : utiliser l'accès API pour l'opération dont vous avez besoin

Si la raison pour laquelle vous passiez au cPanel d'un client était d'effectuer une action administrative spécifique (modifier un paramètre, installer quelque chose, exécuter un script), vérifiez si WHM API 1 ou UAPI peut effectuer la même opération depuis une session root. Beaucoup de choses que vous feriez normalement via l'interface cPanel ont des équivalents API directs qui ne déclenchent pas le bogue 2FA.

Exemples : changer les mots de passe de courriel, lister les bases de données, modifier les enregistrements DNS, gérer les certificats SSL. Tous ont des points de terminaison UAPI que root peut appeler directement sans entrer dans l'interface cPanel du client.

Ce qui ne fonctionne pas

Pour être complet, quelques approches qui semblent pouvoir fonctionner mais qui ne fonctionnent pas :

• Effacer les cookies du navigateur et se reconnecter : le bogue est côté serveur, pas côté client. Les nouvelles sessions rencontrent la même boucle.
• Essayer un autre navigateur : même raison. Bogue côté serveur.
• Se déconnecter de WHM et se reconnecter : n'aide pas, car le bogue se déclenche sur la transition elle-même.
• Désactiver la 2FA de l'utilisateur cPanel : la boucle est sur la 2FA de l'utilisateur WHM, pas celle de l'utilisateur cPanel. Désactiver la 2FA côté cPanel ne fait rien.

Pourquoi cela importe opérationnellement

Le bogue de boucle 2FA est fonctionnellement un déni de service contre les administrateurs d'hébergement et les revendeurs. Il ne compromet pas la sécurité ni n'expose de données, mais il bloque un flux de travail que les hébergeurs utilisent constamment : sauter dans le cPanel d'un client depuis WHM pour diagnostiquer un problème, effectuer un changement ou vérifier une configuration. Sur un hébergeur occupé, ce flux de travail peut se produire des dizaines de fois par jour.

Le bogue est plus perturbateur qu'il n'y paraît parce que la réaction naturelle à une boucle 2FA est de supposer que quelque chose ne va pas avec la configuration 2FA de l'utilisateur, ce qui mène les administrateurs sur des pistes de débogage qui ne révèlent pas la cause réelle. Le fait que cPanel ait attribué un cas développeur (CPANEL-53684) et expédié des versions corrigées sur plusieurs branches en peu de temps suggère qu'ils ont compris l'impact opérationnel.

Pour les clients Gotekky, c'est un non-problème : les serveurs gérés fonctionnent sur des versions corrigées et le correctif a été appliqué pendant le processus de vérification post-publication normal. Si vous exploitez une infrastructure cPanel auto-gérée, passez à une version corrigée dès que vous avez une fenêtre de maintenance et utilisez les contournements ci-dessus avec parcimonie entre-temps.

Notes de mise à niveau associées

La version 11.134.0.35 qui a corrigé CPANEL-53684 était une version de maintenance de routine sans autres correctifs de sécurité significatifs. Les principales versions de sécurité cPanel au printemps 2026 sont documentées dans des guides Gotekky séparés, incluant le contournement d'authentification CVE-2026-41940 du 28 avril, le correctif du 13 mai couvrant cinq CVE supplémentaires, l'urgence du 19 mai pour SEC-73728, SEC-73755 et le problème du plugin LiteSpeed activement exploité et l'avis de suivi du 2 juin sur le plugin LiteSpeed. Si vous rattrapez plusieurs mises à jour cPanel après une période de pause, examinez chaque guide pour comprendre ce que chaque version couvre avant le déploiement.