ShinyHunters contourne une mitigation Oracle PeopleSoft

ShinyHunters a contourné une mesure de mitigation déployée autour du servlet PSEMHUB d’Oracle PeopleSoft. Le correctif Oracle reste la protection de référence : une règle de filtrage peut limiter certaines requêtes, mais elle ne supprime pas la vulnérabilité sur un serveur qui n’a pas été mis à jour.

Le correctif Oracle n’est pas la mitigation

PSEMHUB appartient à PeopleSoft Environment Management Hub. La faille exploite une désérialisation dangereuse d’objets Java et permet une exécution de code à distance sur un serveur vulnérable. Les premières attaques ont permis de déposer des web shells ou d’exécuter des commandes sans forcément créer un fichier classique sur le disque.

Oracle a corrigé cette vulnérabilité le 10 juin 2026 dans les versions 8.61 et 8.62. Elle est référencée sous le numéro CVE-2026-35273 et sa gravité a été évaluée à 9,8 sur 10. La CISA l’a ensuite inscrite dans son catalogue des vulnérabilités exploitées connues, utilisé pour prioriser les corrections des agences fédérales américaines.

Les organisations qui ne pouvaient pas installer immédiatement la mise à jour ont reçu des mesures de réduction du risque. C’est cette protection intermédiaire que ShinyHunters est parvenu à contourner sur des environnements restés vulnérables.

Une règle de filtrage ne modifie pas le serveur

Une mitigation placée devant PeopleSoft agit sur les requêtes reçues par l’application. Elle peut bloquer un accès qui correspond à un motif connu, sans modifier le code vulnérable du serveur. Si l’attaquant trouve une autre représentation de la requête acceptée par le serveur applicatif, la mesure peut perdre son efficacité.

Cette distinction explique le risque actuel : le contournement de la mitigation ne réactive pas la faille sur un système correctement corrigé, mais il peut laisser exposé un système qui dépend encore uniquement du filtrage.

PeopleSoft concentre des données qui dépassent le serveur web

PeopleSoft est utilisé par de grandes organisations, des universités, des administrations et des entreprises pour gérer les ressources humaines, les finances, la chaîne d’approvisionnement ou l’administration des étudiants. Une intrusion ne concerne donc pas uniquement la disponibilité d’une application : elle peut ouvrir un chemin vers des données et des comptes liés à ces fonctions.

La première vague avait notamment visé des établissements d’enseignement supérieur. L’activité observée ensuite élargit le périmètre des organisations concernées. Pour les équipes de sécurité, l’exposition doit être évaluée en fonction des données accessibles depuis PeopleSoft et des connexions de l’application avec d’autres systèmes, pas seulement en recherchant un fichier suspect.

Les vérifications à mener sur un environnement concerné

La réponse doit commencer par la correction, puis chercher les signes d’une exploitation antérieure. Un ordre de travail raisonnable est le suivant :

1. Inventorier les installations PeopleSoft exposées et appliquer le correctif Oracle correspondant à CVE-2026-35273. Les environnements qui reposent encore sur une mitigation doivent être traités en priorité.
2. Examiner les journaux du serveur et des composants placés devant PeopleSoft pour repérer les accès visant PSEMHUB, les requêtes inhabituelles et les séquences qui précèdent l’apparition d’une commande ou d’un fichier.
3. Rechercher les web shells et les modifications inattendues dans l’application. Une absence de fichier suspect ne suffit pas à écarter une exécution de commandes sans écriture classique sur le disque.
4. Contrôler les comptes utilisés par PeopleSoft et renouveler leurs identifiants si une compromission ou une exposition est possible. Cette vérification doit inclure les systèmes auxquels ces comptes peuvent accéder.
5. Conserver les journaux et les éléments techniques avant de supprimer un fichier ou de reconstruire un serveur. Effacer un web shell sans établir le mode d’installation peut faire disparaître des indices et laisser la cause de l’intrusion intacte.

Une connexion sortante inhabituelle, un compte utilisé à un horaire anormal ou une modification non prévue de l’application justifie une investigation. La correction de la faille réduit le risque futur, mais elle ne permet pas à elle seule de conclure qu’aucune intrusion n’a eu lieu.

Le cas du FBI reste une revendication non confirmée

ShinyHunters a affirmé avoir compromis le portail de recrutement du FBI, FBIJobs.gov, ainsi que d’autres systèmes liés à l’agence. Le FBI a confirmé enquêter activement sur des allégations d’activité non autorisée. Il a également indiqué que le point d’entrée restait indéterminé.

À ce stade, le périmètre exact de l’incident et la quantité de données éventuellement consultées ne sont pas établis. Les affirmations du groupe sur les systèmes touchés, les personnes concernées ou le volume de données doivent donc rester présentées comme des revendications, et non comme des faits confirmés.

Le nom ShinyHunters ne suffit pas à attribuer une attaque

Quatre personnes soupçonnées d’être liées à ShinyHunters ont été arrêtées en France en 2025. Ces arrestations ne démontrent pas que les mêmes personnes contrôlent les opérations revendiquées en 2026. Le nom est également repris, revendiqué ou contesté par plusieurs acteurs de la cybercriminalité.

Pour établir l’origine d’une intrusion, les éléments les plus utiles restent les journaux, les comptes employés, les fichiers déposés, les commandes exécutées et les connexions observées. Une signature publiée sur un site de fuite peut orienter l’enquête, mais elle ne remplace pas ces preuves techniques.

Dans le cas d’Oracle PeopleSoft, le point de décision est donc concret : une mitigation contournée impose de vérifier immédiatement l’installation et les traces d’accès, tandis qu’un serveur corrigé ne doit pas être considéré comme compromis uniquement parce qu’il a été visé par une revendication.