Le 24 septembre 2026, CISA a ajouté CVE-2026-5430 à son catalogue Known Exploited Vulnerabilities (KEV). La faille contourne l’authentification JWT de plusieurs produits WSO2 et peut permettre une prise de contrôle de compte. WSO2 avait publié son avis de sécurité le 3 mai ; WatchTowr a ensuite signalé une tentative avec un jeton forgé captée par son honeypot le 13 septembre.
L’inscription au KEV renforce l’urgence de vérifier les déploiements et d’appliquer le correctif correspondant. Elle ne prouve pas qu’une instance donnée a été compromise ni que l’activité observée par le honeypot a touché tous les clients WSO2.
Le mécanisme documenté
Selon l’avis WSO2, l’authentification JWT peut être contournée lorsqu’un jeton est signé avec un algorithme non pris en charge. L’avis cite API Control Plane (4.5.0 et 4.6.0), API Manager (4.1.0 à 4.6.0), Traffic Manager et Universal Gateway (4.5.0 et 4.6.0).
Les niveaux de correctif varient selon le produit et la version. Comparez chaque installation au tableau de l’avis WSO2 : par exemple, API Manager 4.5.0 nécessite le niveau de mise à jour 57 ou supérieur pour les abonnés au support. Les utilisateurs de l’édition open source doivent appliquer les correctifs publics indiqués par WSO2.
Pourquoi le KEV compte
L’inscription au KEV s’appuie sur des éléments d’exploitation. Le signalement indépendant de WatchTowr, relayé par SecurityWeek, décrit une tentative captée dans un honeypot le 13 septembre et un jeton JWT forgé avec des privilèges administrateur. C’est un indice d’exploitation, pas une liste de victimes ni la preuve qu’une instance précise a été atteinte.
Pour les équipes qui exploitent WSO2, il faut traiter la mise à jour comme prioritaire et mener séparément l’enquête : installer un correctif n’efface pas d’éventuelles traces d’accès antérieures.
Les vérifications immédiates
Inventoriez les produits WSO2 concernés, leurs versions et leurs niveaux de mise à jour. Appliquez le correctif publié pour chaque produit et limitez l’accès réseau aux interfaces d’administration lorsque cela est possible.
Préservez les journaux d’authentification, d’API et de passerelle. Recherchez notamment des authentifications inattendues, la création ou l’élévation de comptes administrateurs, ainsi que des changements de configuration et d’accès. Les indicateurs détaillés doivent être interprétés selon votre configuration et les journaux disponibles.
Rotation et réponse
Si les journaux montrent une activité suspecte, ou si l’exposition ne peut pas être écartée, révoquez puis remplacez les jetons et secrets susceptibles d’avoir été accessibles. Évaluez aussi les services en aval auxquels les applications WSO2 pouvaient accéder. Ne remplacez pas indistinctement tous les secrets sans examiner leur lien avec le déploiement touché.
Évitez de recopier les secrets dans les tickets ou les messages d’incident. Pour organiser les accès partagés pendant la réponse, consultez le guide de partage des mots de passe en équipe.
Le lien avec Soclyde
Soclyde ne corrige pas WSO2 et ne détecte pas l’utilisation de jetons forgés. Son générateur peut aider à créer des mots de passe robustes pour les accès qui doivent être remplacés ; son coffre local-first peut aider une équipe à retrouver et partager les accès autorisés. Il ne révoque pas les jetons WSO2 et n’effectue pas leur rotation à votre place.
Cette organisation complète les correctifs et l’analyse des journaux, sans protéger automatiquement la passerelle. Pour préparer le renouvellement d’autres mots de passe, consultez le guide du générateur de mots de passe sécurisé ; pour vérifier les pratiques existantes, voyez le guide d’audit d’un gestionnaire de mots de passe.
À retenir
CVE-2026-5430 contourne l’authentification JWT de produits WSO2 précis. Vérifiez les versions et correctifs dans l’avis officiel, appliquez-les, puis examinez les journaux avant de renouveler les secrets exposés ou susceptibles de l’être. Pour une question sur Soclyde, contactez l’équipe.
