Faille PeopleSoft : le zero-day de ShinyHunters en cachait trois

La faille PeopleSoft CVE-2026-35273, exploitée par ShinyHunters depuis mai, combine en réalité trois vulnérabilités.
Le zero-day Oracle exploité par ShinyHunters n’est pas une vulnérabilité isolée. Selon les chercheurs qui l’ont signalée, cette faille PeopleSoft en réunit en fait trois, enchaînées les unes après les autres. Cette précision, publiée cette semaine, change la lecture de l’incident. Elle montre également pourquoi l’attaque a été aussi efficace.
Oracle a corrigé l’ensemble sous un seul identifiant, CVE-2026-35273, en juin. Or le groupe malveillant ShinyHunters l’exploitait déjà depuis mai. Par conséquent, le correctif est arrivé après plusieurs semaines d’attaques.
Une faille PeopleSoft qui en cache trois
À première vue, la CVE-2026-35273 ressemblait à un bogue critique unique. Pourtant, les chercheurs expliquent qu’il s’agit d’une chaîne d’exploitation. Chaque maillon seul aurait eu un impact limité. En revanche, ensemble, ils ouvrent une voie royale vers le système visé.
Le point de départ est une vulnérabilité de type SSRF (server-side request forgery). Autrement dit, l’attaquant pousse le serveur à émettre une requête à sa place. Cette requête n’est pas destinée à un site externe. En effet, elle vise une ressource interne, normalement inaccessible depuis Internet.
Dans le cas présent, cette ressource est une interface de gestion interne de PeopleSoft. Un pirate extérieur ne devrait jamais pouvoir l’atteindre directement. Pourtant, grâce à la SSRF, il y parvient par rebond.
Un identifiant unique pour trois défauts
Oracle a choisi de regrouper les trois corrections sous une seule référence. Cette pratique est courante lorsque plusieurs défauts concourent à un même scénario d’attaque. Toutefois, elle peut brouiller la perception du risque. Ainsi, une équipe de sécurité qui lit une seule CVE peut penser à un défaut ponctuel. En réalité, le correctif referme plusieurs portes à la fois.
Pourquoi la confiance en loopback pose problème
Le cœur du problème tient à une hypothèse de conception. En effet, PeopleSoft fait confiance à sa propre adresse de bouclage, c’est-à-dire la loopback. Cette adresse désigne la machine elle-même. Par conséquent, les requêtes qui en proviennent sont considérées comme légitimes.
Cette logique paraît raisonnable. En effet, un trafic local est censé venir d’un composant de confiance. Cependant, elle devient dangereuse dès qu’une SSRF existe. Le serveur envoie alors la requête malveillante vers lui-même. Dès lors, l’interface de gestion voit une demande locale et l’accepte.
Ainsi, la barrière censée protéger l’interface s’effondre. L’attaquant n’a pas besoin de contourner le pare-feu. Il utilise l’application comme relais. C’est elle qui ouvre la porte.
Un schéma déjà bien connu
Ce type de scénario n’est pas nouveau. Les interfaces d’administration protégées uniquement par leur emplacement réseau sont une cible classique. Dès qu’un défaut permet de simuler une origine locale, la protection disparaît. C’est pourquoi les bonnes pratiques recommandent une authentification forte, même pour les accès internes.
ShinyHunters exploite la faille PeopleSoft depuis mai
ShinyHunters est un groupe connu pour ses campagnes de vol de données et d’extorsion. Il s’intéresse aux logiciels d’entreprise qui concentrent des informations sensibles. PeopleSoft en fait partie. En effet, cette suite d’Oracle sert notamment à gérer les ressources humaines, la paie et les finances.
L’exploitation a débuté en mai, soit avant la publication du correctif de juin. Pendant cette période, les organisations concernées n’avaient aucune solution officielle. Par conséquent, la surveillance et la réduction de l’exposition étaient leurs seuls leviers.
Les chercheurs ont révélé cette semaine la nature composite de la faille. Cette information est utile aux défenseurs. Elle aide à comprendre comment l’attaque se déroule. Elle permet également de mieux chercher des traces de compromission.
Des conséquences à évaluer au cas par cas
Une organisation qui utilise PeopleSoft ne doit pas se contenter d’installer le correctif. Elle doit aussi vérifier qu’elle n’a pas été touchée avant son application. En effet, une exploitation entre mai et juin reste possible. Une analyse des journaux d’accès et des requêtes internes est donc nécessaire.
Ce qu’il faut retenir
- Identifiant : la CVE-2026-35273 regroupe trois vulnérabilités enchaînées, et non une seule.
- Racine du problème : une SSRF atteint une interface de gestion interne, car PeopleSoft fait confiance à sa propre adresse loopback.
- Chronologie : ShinyHunters exploite la faille depuis mai, et Oracle a publié le correctif en juin.
- Priorité 1 : appliquer sans délai le correctif d’Oracle de juin sur tous les environnements PeopleSoft.
- Priorité 2 : rechercher des signes d’intrusion couvrant la période depuis mai, notamment des requêtes inhabituelles vers l’interface de gestion.
- Durcissement : limiter l’accès aux interfaces d’administration et ne pas considérer le trafic local comme automatiquement fiable.
Cet épisode rappelle qu’une CVE unique peut masquer une chaîne complexe. Il rappelle également qu’une confiance implicite envers le réseau interne suffit à transformer un défaut mineur en brèche majeure.
Source : ShinyHunters-Exploited Oracle PeopleSoft Zero-Day Turns Out to Be Three Chained Flaws