Quand l'authentification d'une API repose sur un hash devinable en quelques heures
osTicket est le système de helpdesk open source le plus déployé au monde : 5 millions d'utilisateurs, plus de 15 000 entreprises, des clients allant de NetApp à des organismes gouvernementaux. Sa couche API est le seul point d'entrée programmatique vers toutes les données de tickets. Aucun OAuth, aucune rotation de jeton, aucun second facteur : la clé API est la frontière d'authentification unique.
La CVE-2026-38447, publiée avec un score CVSS de 9.8, révèle que cette frontière est construite sur du sable.
Le problème technique : MD5 sur des entrées connues
La version 1.18.3 d'osTicket génère ses clés API en calculant un hash MD5 à partir de trois valeurs :
- le timestamp courant au moment de la génération
- l'adresse IP du client
- une seed constante embarquée dans le code
Chacune de ces entrées est soit observable, soit inférable par un attaquant avec un accès réseau basique. Le timestamp peut être approché à partir des en-têtes HTTP ou d'autres signaux temporels. L'adresse IP du serveur est généralement publique. La seed constante est dans le dépôt de code.
MD5 n'est pas cryptographiquement sûr pour cet usage, mais le vrai problème est en amont : même un SHA-512 appliqué à des entrées prévisibles resterait vulnérable. L'entropie de la clé générée est bornée par l'entropie des entrées, pas par celle du hash. Un attaquant qui peut estimer la fenêtre temporelle de génération peut énumérer l'espace des clés possibles et retrouver la clé valide par force brute dans un délai raisonnable.
Ce que permet une clé valide
L'API d'osTicket expose la création de tickets, la consultation des données clients, la gestion du workflow de support. Une clé valide donne un accès complet à ces fonctionnalités sans restriction supplémentaire. Il n'existe pas de scope, pas de permission granulaire : obtenir la clé, c'est obtenir l'instance.
Le vecteur d'attaque est réseau, sans authentification préalable, sans interaction utilisateur requise. C'est pourquoi le score CVSS atteint 9.8.
Comment corriger la génération de clés API en PHP
La correction documentée dans le dépôt principal d'osTicket consiste à remplacer la génération déterministe par une source d'aléatoire cryptographiquement sûre. En PHP, la fonction de référence est random_bytes(), disponible nativement depuis PHP 7 :
// Mauvaise approche : entropie bornée par des entrées connues
$key = md5(time() . $_SERVER['REMOTE_ADDR'] . SEED);
// Approche correcte : entropie cryptographiquement sûre
$key = bin2hex(random_bytes(32));
random_bytes() utilise le CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) du système d'exploitation, ce qui garantit une entropie réelle indépendante de toute entrée observable.
Pour les projets PHP qui gèrent eux-mêmes des secrets similaires, les points de contrôle sont les suivants :
- aucun identifiant ou token ne doit être dérivé d'entrées prévisibles (timestamp, IP, constantes de code)
random_bytes() ou random_int() pour toute génération de secret, jamais rand(), mt_rand() ni uniqid()- les clés API longue durée méritent une politique de rotation, même si la génération est sûre
- stocker les clés hachées côté serveur (avec
hash('sha256', $key)) plutôt qu'en clair
Mise à jour et vérification de l'exposition
Le correctif est disponible dans le dernier commit sur la branche main du dépôt officiel d'osTicket. Il n'existe pas encore, à la date de publication de l'article source, de release taguée incluant ce correctif : il faut appliquer le commit directement ou surveiller la sortie d'une version stable corrigée.
Pour évaluer l'exposition d'une instance :
- vérifier la version déployée : 1.18.3 est confirmée vulnérable
- auditer les journaux d'accès à l'endpoint
/api/ pour des patterns d'énumération ou des volumes de requêtes anormaux
- régénérer toutes les clés API existantes après mise à jour, car les clés générées avant le correctif restent potentiellement devinables si un attaquant a pu observer les logs ou les timestamps
- restreindre l'accès à l'API par IP au niveau du pare-feu ou du serveur web si l'usage le permet
La source originale de cette analyse est un article de Michael Kantor publié sur DEV Community pour HOL (Hashgraph Online), disponible ici.
Ce que ça change pour vous
Si votre entreprise utilise osTicket pour gérer vos demandes clients ou vos tickets de support, cette faille concerne directement vos données. Un attaquant externe peut, sans mot de passe ni compte, accéder à l'ensemble de votre historique client, vos échanges internes et les informations personnelles de vos contacts. Cela représente un risque de fuite de données soumis aux obligations du RGPD, avec des conséquences potentielles en termes de notification obligatoire et de responsabilité. La correction existe et est simple à appliquer : demandez à votre prestataire technique de mettre à jour osTicket dès que possible et de régénérer toutes les clés d'accès à l'API.
