Fin septembre 2026, Google/Mandiant a décrit une nouvelle vague d’attaques du groupe ShinyHunters contre des serveurs Oracle PeopleSoft. Les victimes n’avaient pas installé le correctif d’une faille connue depuis juin : elles comptaient sur une règle de pare-feu posée « en attendant ». Cette règle a été contournée avec une astuce très simple.
Mis à jour le 12 octobre 2026 : selon l’agence Reuters, citée par The Hacker News le 6 octobre 2026, le FBI explique que le piratage de son portail de recrutement, revendiqué par ShinyHunters, vient d’un correctif de sécurité qu’un prestataire n’avait pas installé ; Reuters précise que la plateforme concernée est PeopleSoft. Deux membres présumés du groupe ont été arrêtés, aux Pays-Bas puis en Jordanie selon Reuters. La seconde faille de PeopleSoft revendiquée par le groupe n’est toujours pas confirmée par Oracle (CSO Online / CIO, 5 octobre 2026).
Ce qui s’est passé
PeopleSoft est un progiciel d’Oracle utilisé pour les ressources humaines, la finance ou la scolarité, souvent accessible depuis Internet. En juin 2026, ShinyHunters, un groupe spécialisé dans le vol de données suivi de chantage à la publication, a exploité une faille critique de ce logiciel (CVE-2026-35273). Elle permettait d’exécuter des commandes sur le serveur sans aucun mot de passe. Selon BleepingComputer, une centaine d’organisations avaient alors été touchées. Oracle a publié un correctif.
Toutes les organisations n’ont pas pu l’installer tout de suite. Beaucoup ont choisi une mesure d’attente : bloquer l’accès au composant vulnérable avec une règle de pare-feu applicatif (WAF, un filtre placé devant un site web qui rejette les requêtes suspectes). D’après le rapport de Google/Mandiant relayé par BleepingComputer le 26 septembre 2026, ShinyHunters a trouvé comment passer outre et a installé des portes dérobées sur des dizaines de systèmes dans le monde : enseignement supérieur, santé, transports, services informatiques, administrations. Aucune victime de cette nouvelle vague n’a été nommée publiquement.
Comment l’attaque a fonctionné
Sur le web, une même adresse peut s’écrire de plusieurs façons : une lettre peut être remplacée par son code (on parle d’encodage). Le serveur « traduit » ce code avant de traiter la demande.
La règle de pare-feu comparait le texte brut de l’adresse avec le nom du composant interdit. Les attaquants ont écrit ce nom en remplaçant une seule lettre par son code. Le pare-feu n’a pas reconnu le nom et a laissé passer. Le serveur, lui, a décodé l’adresse, retrouvé le composant vulnérable et exécuté l’attaque. Google prévient que d’autres variantes existent (autres codages, mélange de majuscules et de minuscules).
Une fois entrés, les attaquants ont, selon le rapport :
- vérifié discrètement si le serveur était vulnérable, sans écrire de fichier ni perturber le service ;
- déposé des « web shells » (de petits programmes cachés sur le serveur web, qui permettent de le piloter à distance) ;
- installé, selon les cas, un outil légitime d’administration à distance ou une porte dérobée déguisée en logiciel connu, capable de voler des identifiants ;
- ouvert un tunnel pour rebondir du serveur PeopleSoft vers le reste du réseau interne.
Le but habituel du groupe est de voler des données pour faire chanter la victime. Pour cette vague, les volumes volés n’ont pas été détaillés.
Le cœur du problème n’est donc pas une nouvelle faille, mais un décalage : deux équipements, le pare-feu et le serveur, qui ne lisent pas l’adresse de la même manière.
Ce qu’on ne sait pas encore
La date de début de cette vague n’a pas été précisée. ShinyHunters affirme aussi avoir utilisé une autre faille, encore inconnue, de PeopleSoft : c’est une revendication du groupe, non confirmée par Oracle à ce stade.
Ce que ça change pour une PME
Vous n’utilisez peut-être pas PeopleSoft, mais le piège est universel : une mesure « provisoire » qui dure.
- Donnez une date de fin à chaque mesure d’attente. Quand un correctif ne peut pas être installé tout de suite, notez la mesure prise à la place, qui l’a validée et la date limite à laquelle le vrai correctif doit être appliqué.
- Demandez à votre prestataire de tester la mesure. Une règle de pare-feu doit être vérifiée contre les contournements courants (adresse encodée, majuscules et minuscules). Demandez une trace de ce test.
- Installez le correctif : c’est la seule vraie protection. Si un logiciel exposé sur Internet n’est pas à jour depuis plusieurs mois, faites-en une priorité et faites vérifier qu’aucune intrusion n’a eu lieu entre-temps.
- Conservez les journaux du serveur, pas seulement ceux du pare-feu. Ce sont eux qui permettent de savoir après coup si quelqu’un est entré.
Dossier : Équipements exposés et correctifs
Cet article prolonge notre bulletin de veille du 28 septembre 2026.
Analyse préparée avec l’aide d’une intelligence artificielle à partir de sources publiques, sous la responsabilité de KyNeo. Malgré nos contrôles, des erreurs peuvent subsister : en cas de doute, référez-vous aux sources citées. Les informations non confirmées sont signalées comme telles.