Le 20 octobre 2026, IBM a publié CVE-2026-81212, notée 10.0 — le maximum de l'échelle CVSS 3.1 — dans IBM DataStage on Cloud Pak for Data 5.4.0.0. C'est la troisième faille critique sur cette même version en huit jours, après les deux traversées de chemin publiées le 12 octobre.
Celle-ci est d'une autre nature : elle ne vise pas un serveur mais la frontière entre clients d'une plateforme partagée.
| CVE | CVE-2026-81212 |
| Produit | IBM DataStage on Cloud Pak for Data |
| Version citée | 5.4.0.0 |
| CVSS 3.1 | 10.0 (IBM PSIRT) |
| Vecteur | AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N |
| CWE | CWE-285 (autorisation incorrecte) |
| Statut NVD | Awaiting Analysis |
| CISA KEV | Non, à la date de rédaction |
La vulnérabilité
Selon la description publiée, un utilisateur non authentifié peut effectuer une écriture arbitraire dans le Redis partagé de la plateforme, sous la clé de n'importe quel tenant. IBM en tire deux conséquences :
- la frontière de chiffrement des identifiants de la plateforme s'effondre ;
- un appelant anonyme peut empoisonner les paramètres de flux mis en cache de n'importe quel tenant.
Le CWE retenu, CWE-285, résume le défaut : l'accès en écriture au cache n'est pas soumis au contrôle d'autorisation qui devrait cloisonner les tenants.
Ce que ça implique
DataStage est un outil d'intégration de données : ses flux lisent dans des sources, transforment, écrivent dans des cibles. Leurs paramètres désignent donc typiquement des connexions, des chemins, des bases. Pouvoir réécrire ces paramètres en cache, c'est pouvoir modifier ce qu'un flux d'un autre tenant va faire à sa prochaine exécution.
Le vecteur publié le traduit ainsi :
PR:NetUI:N: aucun compte, aucune action d'un utilisateur nécessaires ;S:C: l'impact dépasse le composant vulnérable — ici, il atteint les autres tenants ;C:H/I:H: confidentialité et intégrité totalement compromises ;A:N: pas d'impact sur la disponibilité.
L'impact sur la confidentialité, alors que l'attaque décrite est une écriture, est cohérent avec la mention de la frontière de chiffrement des identifiants : on peut supposer qu'en plaçant ses propres valeurs là où la plateforme attend des éléments liés au chiffrement, ou en détournant la destination d'un flux, l'attaquant obtient des données d'un autre tenant. C'est une déduction : IBM ne détaille pas le chemin d'exploitation, et aucune exploitation n'est signalée dans NVD.
Le scénario le plus exposé est celui d'une instance Cloud Pak for Data partagée entre plusieurs équipes ou entités, chacune dans son tenant, et dont l'accès réseau n'est pas restreint.
Versions affectées
NVD n'a pas encore analysé l'entrée et ne fournit aucune configuration CPE. La description ne cite que la version 5.4.0.0 ; elle ne dit pas quelle version corrige. Le bulletin IBM référencé dans NVD (support IBM, node 7289603) est la source à suivre pour le correctif ou l'interim fix à appliquer.
Détection
- Inventaire : identifier les déploiements Cloud Pak for Data qui font tourner DataStage en 5.4.0.0, en particulier ceux qui hébergent plusieurs tenants.
- Exposition : vérifier depuis quels réseaux l'instance est joignable. L'attaque ne demande pas de compte : seul l'accès réseau la limite.
- Intégrité des flux : comparer les paramètres de flux effectivement utilisés aux dernières exécutions avec leur définition attendue (connexions, cibles d'écriture).
- Redis : si la supervision de la plateforme le permet, rechercher des écritures sur des clés de tenant provenant de sessions non authentifiées.
Mitigation
- Appliquer le correctif IBM indiqué dans le bulletin.
- En attendant, restreindre l'accès réseau à l'instance aux seuls réseaux des utilisateurs légitimes.
- Après correction, purger le cache des paramètres de flux si la plateforme le permet, pour éliminer d'éventuelles valeurs empoisonnées, et faire tourner les identifiants utilisés par les flux sur les instances qui étaient exposées.
Pourquoi surveiller en continu tes plateformes de données
Trois CVE critiques en huit jours sur une même version de DataStage : sur un produit de ce type, les bulletins s'enchaînent et chacun appelle une action. Les suivre à la main, éditeur par éditeur, c'est en laisser passer.
Avec cveo.tech, déclare tes plateformes avec leur version exacte et reçois une alerte dès qu'une CVE les concerne, même quand NVD ne l'a pas encore analysée.