WHMCS CVE-2026-29204 : contournement d'autorisation de la zone client et comment mettre à jour votre installation WHMCS

Le 13 mai 2026, WHMCS a publié deux mises à jour de maintenance de sécurité (WHMCS 9.0.4 et WHMCS 8.13.3) traitant CVE-2026-29204, un contournement d'autorisation de la zone client affectant toutes les versions WHMCS depuis 7.4. La divulgation s'est produite plus tôt que WHMCS ne l'avait prévu en raison d'un problème de soumission du côté du fournisseur, ce qui a accéléré la publication du correctif. Un contournement communautaire fonctionnel circulait déjà avant le correctif officiel, ce qui signifie que des tentatives d'exploitation dans la nature sont possibles même si aucune campagne à grande échelle n'a été confirmée.

Si vous exploitez WHMCS en tant que revendeur d'hébergement, agence ou fournisseur d'infrastructure, vous devez mettre à jour aujourd'hui. Ce n'est pas le genre de vulnérabilité que vous pouvez atténuer par d'autres moyens sans casser la fonctionnalité de la zone client. Le correctif est simple à appliquer, disponible via l'Auto Updater WHMCS à l'intérieur de votre zone administrateur et pris en charge sur toutes les versions majeures WHMCS prises en charge.

Ce que CVE-2026-29204 fait réellement

La vulnérabilité est une vérification de propriété insuffisante à l'intérieur de clientarea.php. Quand un utilisateur de zone client connecté soumet une requête qui référence un addonId appartenant à un autre client, WHMCS ne vérifie pas que l'addonId appartient réellement à l'utilisateur connecté avant de traiter la requête. Le résultat est un accès non autorisé au contexte de compte d'un autre client, incluant la capacité d'agir sur les services et addons appartenant aux victimes du contournement.

La vulnérabilité nécessite que l'attaquant soit un utilisateur authentifié de la zone client, ce qui signifie que ce n'est pas un exploit distant non authentifié. Un attaquant a besoin d'un compte sur votre installation WHMCS. Pour la plupart des hébergeurs, ce compte est trivial à obtenir car n'importe qui peut s'inscrire. La barrière est essentiellement nulle. Une fois connecté en tant que n'importe quel client, l'attaquant peut cibler les valeurs addonId de tout autre client et accéder à leur contexte de compte.

La catégorie est ce que les chercheurs en sécurité appellent IDOR (Insecure Direct Object Reference), une classe de bogue où l'application vérifie que l'utilisateur est authentifié mais ne vérifie pas que l'utilisateur est autorisé à agir sur l'objet spécifique demandé. Les vulnérabilités IDOR dans les plateformes de facturation sont particulièrement dangereuses car elles accordent typiquement l'accès aux données de facture, à la configuration des services, aux métadonnées de cartes de crédit et aux renseignements personnels des clients. La portée exacte de ce que CVE-2026-29204 expose est déterminée par les points de terminaison de la zone client qui acceptent des valeurs addonId sans vérification de propriété, et WHMCS n'a pas publié d'énumération complète de ces points de terminaison.

Versions affectées et les versions corrigées

Toutes les versions WHMCS depuis 7.4 sont affectées. Les versions WHMCS plus anciennes que 7.4 sont en fin de vie et ne recevront pas de correctif. Les versions corrigées sont :

• WHMCS 9.x : mettez à jour vers WHMCS 9.0.4
• WHMCS 8.x : mettez à jour vers WHMCS 8.13.3
• WHMCS 7.4 à 8.12 : mettez à jour vers 9.0.4 ou 8.13.3. Il n'y a pas de version corrigée séparée pour les branches 8.x ou 7.x plus anciennes.

Si vous exécutez une version non prise en charge (toute version antérieure à 7.4 ou toute version 8.x avant 8.13), cette vulnérabilité ne sera pas corrigée pour votre installation. Votre seule option est de mettre à niveau vers une branche prise en charge. Le chemin de mise à niveau depuis des versions plus anciennes peut impliquer des migrations de schéma de base de données et du travail de compatibilité des modules complémentaires, donc planifiez du temps en conséquence, mais traitez le travail comme urgent : une installation WHMCS non corrigée qui gère des données de facturation est maintenant une responsabilité connue.

Comment Gotekky gère WHMCS pour ses propres opérations et pour les clients gérés

Gotekky utilise WHMCS comme plateforme de facturation et a corrigé son installation immédiatement après la publication du 13 mai. Pour les clients dont la couche applicative WHMCS faisait alors partie d’une portée gérée par Gotekky, nous avons appliqué le correctif aux instances concernées et vérifié la version dans l’interface administrateur WHMCS.

Lorsque WHMCS se trouvait hors de la portée de gestion documentée de Gotekky, notamment sur un ancien service autogéré, l’application et sa mise à jour demeuraient sous la responsabilité du client. Les étapes ci-dessous s’appliquent à cette situation.

Comment mettre à jour votre installation WHMCS

WHMCS fournit deux façons d'appliquer la mise à jour.

Méthode 1 : Auto Updater à l'intérieur de la zone administrateur WHMCS

C'est l'approche recommandée pour la plupart des installations. Connectez-vous à votre zone administrateur WHMCS, naviguez vers Utilities, puis Update WHMCS. L'updater détectera que 9.0.4 (si vous êtes sur 9.x) ou 8.13.3 (si vous êtes sur 8.x) est disponible, présentera un bouton de mise à jour en un clic et appliquera le correctif incluant les migrations de schéma de base de données que la version requiert. Le processus complet prend typiquement une à trois minutes sur une petite installation, plus longtemps sur les plus grandes.

Avant de cliquer sur mettre à jour, prenez une sauvegarde complète à la fois de vos fichiers WHMCS et de votre base de données WHMCS. L'Auto Updater est fiable, mais un correctif de sécurité sur une infrastructure de facturation de production n'est pas l'endroit pour opérer sans chemin de récupération. La séquence de sauvegarde recommandée est : faire un dump de la base de données avec mysqldump, puis créer une archive compressée de l'arborescence complète des fichiers WHMCS. Gardez les deux sauvegardes hors du serveur WHMCS lui-même.

Méthode 2 : mise à jour manuelle via les paquets de version

Si vous préférez contrôler la mise à jour manuellement (ce qui a du sens pour les installations de production avec personnalisation ou fichiers core modifiés), téléchargez le paquet de version approprié ou la mise à jour incrémentale depuis la page de téléchargement WHMCS à download.whmcs.com. La mise à jour incrémentale de 9.0.x à 9.0.4 est plus petite et plus rapide à déployer si vous venez d'une version 9.0.x récente. Le paquet de version complet remplace l'installation WHMCS entière, ce qui est le bon choix si vous mettez à niveau à travers plusieurs versions mineures ou de 8.x à 9.x.

La procédure de mise à jour manuelle : téléchargez les nouveaux fichiers sur votre serveur en remplaçant les fichiers existants (à l'exclusion de configuration.php et de vos répertoires /attachments/, /downloads/, /templates_c/ qui contiennent des données spécifiques à l'instance ou générées), puis visitez la page de connexion administrateur WHMCS une fois pour déclencher la routine de mise à niveau de la base de données. Référez-vous à la documentation officielle de mise à niveau WHMCS pour la procédure canonique.

Vérification après la mise à jour

Après avoir appliqué la mise à jour, confirmez la version installée à deux endroits. Dans la zone administrateur WHMCS, naviguez vers Help, puis About WHMCS. La version affichée devrait être 9.0.4 ou 8.13.3 selon la branche vers laquelle vous avez mis à jour. Vérifiez aussi la balise meta version dans la source de la page d'accueil de votre zone client, qui expose la version pour l'outillage de diagnostic. Les deux devraient concorder.

Testez le flux de connexion de la zone client avec un compte de test non administratif pour vérifier que rien n'a été cassé pendant la mise à jour. Les mises à jour WHMCS interagissent occasionnellement avec des hooks personnalisés, des modules personnalisés ou des personnalisations de thème de manières qui apparaissent pendant le fonctionnement normal de la zone client. Un passage de test de 30 secondes à travers la connexion, le profil et une page de détail de service attrape les modes de défaillance courants.

Que faire si vous ne pouvez pas mettre à jour immédiatement

Si vous ne pouvez pas mettre à jour aujourd'hui pour des raisons de contrôle des changements ou de coordination, le contournement communautaire qui circulait avant le correctif officiel est de bloquer les requêtes contenant le paramètre addonId contre clientarea.php au niveau du serveur web. Cela casse la fonctionnalité légitime de la zone client liée aux addons mais arrête le chemin d'exploitation. La règle exacte dépend de votre serveur web, mais le schéma est simple : refuser toute requête vers clientarea.php qui inclut addonId dans la chaîne de requête ou le corps POST. C'est une mesure provisoire, pas un correctif. Appliquez-la seulement si vous ne pouvez pas exécuter le correctif officiel dans les heures, et retirez-la dès que vous avez appliqué la mise à jour du fournisseur.

Pourquoi la sécurité WHMCS importe spécifiquement pour l'infrastructure d'hébergement

WHMCS occupe une position particulièrement sensible. Il détient la relation client complète pour les entreprises d'hébergement : données de facturation, inventaire de services, tickets de support, métadonnées de cartes de crédit (typiquement tokenisées mais toujours sensibles), informations de renouvellement de domaine et identifiants de connexion client. Une vulnérabilité IDOR qui accorde l'accès au contexte de compte d'un autre client est un pivot direct vers des données client que les hébergeurs sont obligés de protéger en vertu de la LPRPDE au Canada, du RGPD en Europe et de diverses autres réglementations.

Pour les hébergeurs québécois opérant sous la Loi 25, l'obligation s'étend à démontrer que vous avez des sauvegardes techniques proportionnelles à la sensibilité des données que vous traitez. Une installation WHMCS non corrigée avec un contournement d'autorisation connu affectant les comptes clients est difficile à justifier dans un contexte réglementaire ou de réponse aux violations. Corriger immédiatement et documenter le déploiement du correctif est la posture défendable.

C'est la deuxième divulgation de sécurité significative dans la pile d'infrastructure d'hébergement en trois semaines, après CVE-2026-41940 dans cPanel et WHM. Les deux accordent un accès non autorisé aux systèmes orientés client. Les deux ont des contournements communautaires fonctionnels ou des preuves de concept en circulation. Le schéma est cohérent : les composants d'infrastructure d'hébergement reçoivent une attention agressive de la recherche en sécurité, et la cadence de réponse pour les opérateurs doit correspondre. Appliquez le correctif WHMCS aujourd'hui, le correctif cPanel de fin avril s'il n'est pas déjà fait, et les atténuations du noyau pour Copy Fail, Dirty Frag et Fragnesia que nous avons couvertes dans des guides séparés. Le tableau complet est que c'est maintenant la base opérationnelle pour une entreprise d'hébergement canadienne.