WSO2 CVE-2026-5430 au CISA KEV : une CVE 10.0, deux descriptions qui ne concordent pas

Le 24 septembre 2026, la CISA a ajouté CVE-2026-5430 à son catalogue KEV, avec une échéance au 27. Elle touche WSO2 API Manager, API Control Plane, Traffic Manager et Universal Gateway, et elle est notée 10.0.

Avant d'aller plus loin, un point que je ne veux pas lisser : les deux sources de référence ne décrivent pas la même faille pour cet identifiant. C'est inhabituel, et la bonne réaction n'est pas de choisir l'une des deux, mais de traiter les deux.

Deux descriptions pour un même identifiant

Ce que dit la CISA (fiche KEV, intitulée WSO2 Multiple Products Path Traversal Vulnerability) :

WSO2 API Control Plane, API Manager, Traffic Manager & Universal Gateway contain a path traversal vulnerability that could allow for unrestricted file upload and lead to remote code execution.

Ce que dit NVD (publication du 6 août 2026) :

The JWT authentication mechanism accepts tokens signed with algorithms other than those explicitly configured or supported. This allows an attacker to craft a JWT with an unsupported algorithm, which is then incorrectly validated, leading to unauthorized access. [...] may result in unauthorized access to the system, including the potential compromise of administrative accounts and full account takeover.

Une traversée de chemin menant à l'upload de fichiers d'un côté, une confusion d'algorithme JWT de l'autre. Les deux mènent à une compromission complète, mais par des mécanismes sans rapport.

Explications possibles : un avis WSO2 regroupant plusieurs défauts sous un même identifiant, une erreur d'étiquetage d'un côté ou de l'autre, ou une chaîne où le contournement JWT ouvre l'accès à la fonction d'upload. Je ne sais pas laquelle est la bonne, et je ne vais pas prétendre le contraire. L'avis de sécurité WSO2 fait foi.

Ce qui est certain : la faille est exploitée, et elle est notée 10.0.

Pourquoi les deux lectures sont graves

Si c'est la confusion d'algorithme JWT

C'est une classe de faille bien connue. Un vérificateur de jetons qui accepte l'algorithme annoncé par le jeton lui-même, au lieu d'imposer celui qu'il attend, peut être trompé :

• avec alg: none, un jeton sans signature est accepté
• avec une confusion RS256 → HS256, l'attaquant signe un jeton avec la clé publique du serveur utilisée comme secret HMAC — clé que, par définition, tout le monde connaît

Sur une passerelle d'API, les jetons JWT sont le contrôle d'accès de toutes les API qu'elle protège. Forger un jeton accepté, c'est se présenter comme n'importe quel utilisateur ou administrateur.

Si c'est la traversée de chemin avec upload

Déposer un fichier arbitraire à un emplacement choisi sur une passerelle Java, c'est typiquement déposer un composant déployable — donc exécuter du code dans la passerelle, avec accès à tous les secrets des API qu'elle relaie.

NVD précise le vecteur : S:C en déploiement multi-tenant (10.0), ajusté à 9.8 en mono-tenant, où l'impact reste contenu dans une seule autorité de sécurité.

Versions

NVD liste les bornes suivantes — ce sont des niveaux de mise à jour WSO2, pas des versions produit :

WSO2 distribue ses correctifs via son système de mises à jour (WSO2 Updates). Vérifie le niveau appliqué sur chaque nœud et compare-le à l'avis WSO2.

Détection — couvrir les deux hypothèses

Pour l'hypothèse JWT :

• Jetons dont l'en-tête annonce un algorithme différent de celui configuré (none, HS256 là où tu utilises RS256)
• Accès administrateurs ou appels d'API privilégiés sans connexion correspondante au portail
• Jetons acceptés pour des utilisateurs qui ne se sont pas authentifiés dans la période

Pour l'hypothèse traversée / upload :

• Fichiers récemment créés dans les répertoires de déploiement (repository/deployment/server/) sans déploiement documenté
• Requêtes d'upload contenant des séquences ../ ou leurs encodages
• Processus enfants inattendus de la JVM WSO2

Mitigation

1. Appliquer la mise à jour WSO2 qui corrige CVE-2026-5430 sur chaque nœud — Control Plane, Gateway, Traffic Manager. L'échéance CISA est le 27 septembre.
2. Restreindre les consoles d'administration (Publisher, Admin, Carbon) aux réseaux d'administration. Seule la passerelle doit être exposée.
3. Imposer l'algorithme de signature attendu dans toute validation JWT que tu contrôles en aval de la passerelle — la défense qui rend la première hypothèse inopérante, quel que soit le produit.
4. En cas de compromission : faire tourner les clés de signature des jetons, les secrets des applications clientes, les identifiants administrateurs, et considérer les secrets des API relayées comme exposés.

Pourquoi surveiller en continu vos passerelles d'API

Une passerelle d'API concentre l'authentification de toutes les API qu'elle expose. Quand une CVE 10.0 y est exploitée et que les sources ne s'accordent même pas sur sa nature, le seul point d'appui fiable est de savoir exactement quel niveau de mise à jour tourne sur chaque nœud.

Avec cveo.tech, inventorie tes passerelles d'API avec leur version exacte, et reçois une alerte dès qu'une CVE au CISA KEV les concerne.