ShinyHunters contourne des règles WAF et relance les attaques contre PeopleSoft

Oct 1, 2026 | L'actu IT à 360

Mandiant et Google Threat Intelligence Group signalent une reprise des attaques de ShinyHunters contre Oracle PeopleSoft. Certaines protections WAF sont contournées alors que la vulnérabilité reste présente.[1] Pour les entreprises, cette campagne rappelle la nécessité de vérifier ce qui a réellement été corrigé derrière les équipements de sécurité.

01

Une faille connue depuis juin revient au premier plan

CVE-2026-35273 concerne le composant Updates Environment Management de PeopleSoft PeopleTools. Oracle indique qu’elle permet une exploitation à distance sans authentification, avec un risque d’exécution de code sur le serveur. Son score de sévérité CVSS 3.1 atteint 9,8 sur 10. L’alerte publiée le 10 juin 2026 cite les versions supportées 8.61 et 8.62.[2]

Le premier rapport de Mandiant, daté du 11 juin, situait les attaques observées entre le 27 mai et le 9 juin. Elles précédaient donc l’alerte de l’éditeur. Les établissements d’enseignement supérieur étaient particulièrement concernés. Le rapport évoquait plus de 100 organisations averties d’une exposition potentielle, un chiffre qui ne constitue pas un décompte de victimes confirmées.[3]

La distinction est essentielle pour lire l’actualité de septembre : une vulnérabilité déjà documentée peut rester exploitable lorsque sa prise en charge se limite à une mesure temporaire. Une alerte traitée dans un outil de suivi ne prouve pas, à elle seule, que le composant concerné a été corrigé.

02

Un décalage de lecture suffit à fragiliser le filtrage

Un WAF, ou pare-feu applicatif web, analyse les échanges destinés à une application. Selon Mandiant, les attaquants ont encodé un caractère du chemin demandé : certaines règles comparaient sa forme littérale, tandis que le serveur décodait la requête et atteignait le composant vulnérable.[1]

Le constat porte sur des règles particulières. Il ne démontre pas une inefficacité générale des WAF. L’enjeu technique est la cohérence entre ce que le dispositif de sécurité examine et ce que l’application interprète ensuite. Un filtrage doit être évalué dans l’architecture réelle, avec ses intermédiaires et ses configurations.

03

Les observations doivent rester distinctes du risque potentiel

Le rapport de septembre attribue la campagne à UNC6240, associé à ShinyHunters. Il décrit des implants web sur des dizaines de systèmes dans plusieurs secteurs, ainsi qu’une méthode d’exécution sans fichier déposé.[1]

Ces observations établissent une activité malveillante, mais ne permettent pas d’affirmer que toutes les organisations exposées ont subi un vol de données. Dans une entreprise donnée, l’évaluation doit relier les événements constatés aux accès réellement obtenus et aux ressources concernées.

La campagne de juin avait, elle, été associée à des publications de données volées et à des opérations d’extorsion.[3] Ce précédent justifie d’examiner la confidentialité des informations, en complément du maintien en fonctionnement de l’application.

04

La protection applicative engage toute la chaîne IT

Notre lecture de cette campagne est organisationnelle autant que technique. L’administrateur de l’application connaît ses contraintes de maintenance ; l’équipe réseau gère les accès ; la sécurité examine les alertes ; les responsables métier évaluent les effets d’une interruption. Sans coordination, chacun peut avoir réalisé sa tâche alors que le risque reste ouvert.

Pour une PME utilisant PeopleSoft, directement ou par l’intermédiaire d’un prestataire, la question utile est de savoir qui confirme la version déployée, applique les mesures de l’éditeur et vérifie leur résultat. Une réponse limitée à la présence d’un WAF ne suffit pas à documenter l’état de sécurité du logiciel.

05

Quatre situations appellent des réponses différentes

Cette grille propose une lecture opérationnelle des situations à examiner. Elle ne remplace pas les instructions applicables à chaque installation.

Situation Décision à organiser Élément à vérifier
Version ou exposition inconnue Recenser les instances avec leur responsable. Inventaire daté et périmètre confirmé.
Protection limitée au filtrage Traiter la vulnérabilité selon les consignes Oracle. État du composant et validation du changement.
Traces suspectes identifiées Déclencher une investigation et décider du confinement. Chronologie des événements et étendue des accès.
Correction annoncée comme terminée Contrôler la sécurité et les fonctions métier. Résultats des vérifications et surveillance prévue.

06

Corriger et rechercher une intrusion sont deux travaux complémentaires

Oracle demande une prise en charge immédiate et renvoie à sa documentation de support pour les mesures et instructions d’installation. L’éditeur précise aussi que les anciennes versions non supportées ne sont pas testées systématiquement : leur absence de la liste ne permet pas de les considérer comme sûres.[2]

Mandiant recommande notamment d’examiner les journaux et les fichiers, de contrôler tous les nœuds WebLogic et de renouveler les identifiants accessibles au compte applicatif.[1] Ces vérifications doivent être coordonnées avec la réponse à incident, en conservant les éléments utiles à l’analyse.

Le NIST décrit la gestion des correctifs comme un processus qui va de l’identification à la vérification de l’installation.[4] Il intègre également la préparation, la détection, la réponse et la reprise dans la gestion du risque cyber.[5] En pratique, fermer une voie d’entrée ne démontre pas qu’un accès obtenu auparavant a disparu.

07

Le professionnel doit démontrer que la protection fonctionne

Cette campagne donne une dimension concrète à la Cybersécurité. Le professionnel doit comprendre le rôle de chaque protection, identifier ses limites et relier les alertes aux composants réellement utilisés. Savoir configurer une règle doit s’accompagner de la capacité à en vérifier les effets.

Son rôle consiste aussi à traduire le risque en décisions compréhensibles : quel service doit être corrigé, quelle interruption faut-il préparer et quelles vérifications permettront de reprendre confiance ? Cette démarche demande de travailler avec les exploitants et les responsables métier, en documentant les incertitudes.

Pour l’entreprise, la valeur de cette compétence se mesure dans la capacité à réduire une exposition et à justifier le résultat obtenu. La présence d’un outil de sécurité devient ainsi le point de départ d’un contrôle, plutôt qu’une preuve suffisante de protection.

08

Une mesure provisoire doit avoir une date de fin

L’enseignement à tirer est de donner à toute protection temporaire un responsable, un périmètre vérifié et une échéance de réévaluation. Le suivi doit rendre visible ce qui reste à corriger et ce qui reste à investiguer. La question à poser aux équipes devient alors précise : quelles preuves permettent aujourd’hui de considérer cette exposition comme maîtrisée ?

À LIRE AUSSI

Ces quatre articles CCCLX prolongent les enjeux de protection des applications, de gestion des correctifs et de sécurité des identifiants.

Sécurité applicative

F5 renforce son WAF pour faire face aux cybermenaces de l’ère IA

Le rôle des pare-feu applicatifs face à des attaques qui évoluent.
Gestion des correctifs

Lightwell : IBM et Red Hat s’attaquent au casse-tête des patchs open source

La gestion des mises à jour de sécurité dans les environnements open source.
Identifiants et cloud

Djinn Stealer : le malware qui s’attaque aux identifiants cloud et IA des entreprises

Pourquoi la protection des accès reste déterminante après une intrusion.
Sécurité open source

La sécurité de l’open source change d’échelle : IBM, Red Hat et Palo Alto s’allient

La coopération des éditeurs pour renforcer la sécurité des logiciels.

Sources

  1. 01

    Mandiant et Google Threat Intelligence Group (25 septembre 2026). « ShinyHunters Renewed Mass Exploitation Campaign Targeting Oracle PeopleSoft ». Analyse de la reprise des attaques et du contournement des règles WAF.

    Consulter la source →

  2. 02

    Oracle (10 juin 2026). « Oracle Security Alert Advisory – CVE-2026-35273 ». Informations sur les versions concernées, la gravité et les mesures de l’éditeur.

    Consulter la source →

  3. 03

    Mandiant et Google Threat Intelligence Group (11 juin 2026). « ShinyHunters Targets Education Sector with Oracle PeopleSoft Exploit ». Premier compte rendu des attaques observées en mai et juin 2026.

    Consulter la source →

  4. 04

    NIST (2022). « Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology », SP 800-40 Rev. 4. Repères sur l’identification, l’installation et la vérification des correctifs.

    Consulter la source →

  5. 05

    NIST (2025). « Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile », SP 800-61 Rev. 3. Cadre de préparation, de détection, de réponse et de reprise après incident.

    Consulter la source →

L’Actu IT à 360°, décrypter la technologie pour comprendre les métiers de demain.

Découvrir CCCLX →