ShinyHunters contourne les WAF d'Oracle PeopleSoft

Ce qui s'est passé

Le 27 septembre 2026, les équipes de Google Mandiant et du Threat Intelligence Group (GTIG) ont publié un rapport documentant une nouvelle vague d'attaques orchestrée par UNC6240, le groupe derrière l'entité d'extorsion ShinyHunters. Cette campagne reprend l'exploitation de CVE-2026-35273, une vulnérabilité critique dans le composant PSEMHUB d'Oracle PeopleSoft, mais avec une technique inédite permettant de contourner les règles des pare-feux applicatifs web (WAF) que de nombreuses organisations avaient mises en place à titre de mesure compensatoire.

CVE-2026-35273 est une faille d'exécution de code à distance non authentifiée (RCE) dans Oracle PeopleSoft, affectant le module d'intégration PSEMHUB. Notée CVSS 9.8, elle permet à un attaquant sans aucun compte valide d'obtenir une exécution de code arbitraire sur le serveur WebLogic sous-jacent. Oracle a publié un correctif lors de son cycle de mises à jour en juin 2026. À cette époque, Mandiant et GTIG avaient identifié plus de 100 organisations avec des instances PeopleSoft exposées sur Internet, dont 68 % étaient des établissements d'enseignement supérieur américains.

Face à l'ampleur des attaques initiales et aux délais de déploiement des correctifs — souvent longs dans les environnements universitaires et hospitaliers où les fenêtres de maintenance sont contraintes — de nombreux administrateurs système avaient opté pour une solution intermédiaire : bloquer via le WAF toutes les requêtes HTTP contenant la chaîne littérale /PSEMHUB/. Cette mesure avait temporairement ralenti les attaquants. Mais ShinyHunters vient d'en démontrer les limites.

La technique de bypass découverte par les chercheurs de Google est élégante dans sa simplicité. Les attaquants ont remplacé la lettre « P » de PSEMHUB par son équivalent URL-encodé, %50, produisant la chaîne /%50SEMHUB/. La plupart des moteurs WAF effectuent une correspondance simple sur les chaînes de caractères brutes, sans décoder préalablement l'URL. La règle de blocage ne trouve plus le pattern /PSEMHUB/ et laisse passer la requête. Le serveur WebLogic en backend, lui, decode systématiquement les URLs avant de les router vers le gestionnaire interne adéquat — et traite donc la requête normalement, déclenchant la vulnérabilité.

Cette discordance entre la normalisation des URLs appliquée par le WAF et celle du serveur backend est un problème connu en sécurité applicative, mais régulièrement sous-estimé. Elle constitue la base de nombreuses techniques de bypass documentées depuis des années dans les communautés de tests d'intrusion. Sa résurgence dans une campagne d'attaques en masse contre un ERP critique comme PeopleSoft illustre à quel point les mesures compensatoires peuvent donner un faux sentiment de sécurité.

Suite à cette nouvelle vague de compromissions, Google a recensé des web shells déployés sur des dizaines de systèmes à travers le monde dans des secteurs variés : enseignement supérieur, technologie, services informatiques, santé, agriculture, transport et administration publique. Selon Mandiant, la chaîne d'attaque commence par une phase de reconnaissance via le RCE initial, suivie du déploiement de l'agent de gestion à distance MeshCentral pour assurer la persistance. Les attaquants procèdent ensuite à un mouvement latéral sur SSH et à l'exfiltration de données. Un backdoor désigné SIDEEYE a également été retrouvé sur certains systèmes compromis, suggérant une infrastructure d'accès persistant maintenue pour une réutilisation ultérieure.

Oracle PeopleSoft est particulièrement répandu dans le milieu universitaire américain pour la gestion des ressources humaines, des finances et des inscriptions étudiantes. Ces systèmes contiennent des données particulièrement sensibles : numéros de sécurité sociale, informations bancaires pour les remboursements, dossiers académiques et données de santé pour les étudiants couverts par les assurances institutionnelles. Pour les organisations de santé touchées, les implications réglementaires liées à HIPAA sont significatives. Google n'a pas publié la liste des organisations compromises pour protéger les victimes en cours de remédiation.

Le fait que ShinyHunters soit à l'origine de cette campagne mérite une attention particulière. Le groupe, actif depuis plusieurs années sur BreachForums, a fait la une de l'actualité cybersécurité en septembre 2026 pour une série d'opérations d'envergure, dont la compromission alléguée du portail recrutement du FBI via un zero-day distinct dans Oracle PeopleSoft. Cette activité frénétique suggère que le groupe cherche à accumuler un maximum d'accès et de données monétisables, possiblement en réponse à la pression des forces de l'ordre qui s'intensifie à son encontre.

Pourquoi c'est important

L'incident remet au premier plan un débat fondamental en gestion des correctifs : la différence entre une mesure compensatoire et un vrai correctif. Face à une vulnérabilité critique dans un système métier critique, la tentation est forte de déployer une règle WAF — plus rapide qu'un patch nécessitant des tests de non-régression, des fenêtres de maintenance et des redémarrages de services. Mais comme le démontre cette campagne, les mesures compensatoires présentent des surfaces de contournement que des attaquants déterminés finissent par trouver.

La technique d'URL-encoding utilisée ici n'est pas nouvelle. Elle figure dans des référentiels publics de test d'intrusion et fait partie des vecteurs documentés dans les guides de test de l'OWASP depuis plus d'une décennie. Ce qui est remarquable, c'est la rapidité avec laquelle ShinyHunters l'a opérationnalisée à grande échelle dès que les organisations ont commencé à déployer leurs règles WAF. Cela témoigne d'une veille active sur les mesures défensives déployées et d'une capacité d'adaptation tactique rapide qui caractérise les groupes de menace les plus sophistiqués.

Pour les RSSI et équipes de sécurité, cet épisode soulève une question structurelle sur la gouvernance des correctifs. Dans les environnements où le déploiement des patches prend des semaines ou des mois — universités avec des systèmes PeopleSoft fortement personnalisés, hôpitaux sous contrainte réglementaire pour les modifications de systèmes critiques — les mesures compensatoires restent nécessaires mais doivent être accompagnées d'une surveillance accrue et d'une communication transparente avec les fournisseurs de WAF pour s'assurer que leurs règles couvrent les variantes d'encodage. Des WAF de nouvelle génération capables de normaliser les URLs avant d'appliquer leurs règles constituent désormais un prérequis pour ce type de protection.

Du côté réglementaire, les organisations touchées dans l'Union européenne et au Royaume-Uni sont soumises aux obligations de notification de NIS2, qui impose un délai de 24 heures pour la notification initiale aux autorités compétentes en cas d'incident significatif. En France, l'ANSSI rappelle régulièrement que la compromission de systèmes d'information critiques via des vulnérabilités publiquement connues constitue une faute grave au regard des obligations de sécurisation des systèmes essentiels. Les organisations de santé américaines touchées devront quant à elles évaluer leurs obligations HIPAA Breach Notification.

Ce qu'il faut retenir

• Appliquer immédiatement le patch Oracle pour CVE-2026-35273 ; les règles WAF de blocage de /PSEMHUB/ sont contournables via URL-encoding (%50SEMHUB, %50%53EMHUB et autres variantes).
• Auditer les logs de vos instances PeopleSoft pour détecter des requêtes vers /PSEMHUB/ avec des caractères encodés, ainsi que des indicateurs de compromission MeshCentral et SIDEEYE.
• Les mesures compensatoires WAF doivent être temporaires et doublées d'une surveillance renforcée — elles ne remplacent pas les correctifs officiels des éditeurs.