Oracle PeopleSoft : RCE exploitée par ShinyHunters (CVE-2026-35273)

En bref

CVE-2026-35273 est une prise de contrôle distante non authentifiée d'Oracle PeopleSoft, exploitée comme zéro-day puis de nouveau exploitée des mois après son correctif.

• Trois failles signalées par la Zero Day Initiative fonctionnent comme une seule chaîne : un SSRF dans l'Integration Gateway (PSIGW), une adresse de bouclage approuvée par défaut par l'Environment Management Hub (PSEMHUB), et deux chemins d'exécution de code dans PSEMHUB. Oracle a corrigé les trois sous le CVE unique dans son alerte de sécurité du 10 juin 2026.
• PeopleSoft Enterprise PeopleTools 8.61 et 8.62 sont les versions prises en charge affectées. CVSS v3.1 9,8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), noté par Oracle.
• ShinyHunters (suivi sous le nom UNC6240 par Mandiant et le Google Threat Intelligence Group) a exploité la chaîne comme zéro-day du 27 mai au 9 juin 2026, principalement contre des universités, puis de nouveau dans une vague plus étendue en septembre touchant enseignement supérieur, technologie, services informatiques, santé, agriculture, transport et gouvernement. La CISA a ajouté le CVE à son catalogue KEV le 12 juin.
• Appliquez le correctif de l'alerte Oracle du 10 juin et restez sur une version PeopleTools prise en charge. En attendant, désactivez ou supprimez l'Environment Management Hub ; le correctif ferme la porte mais n'évince pas un attaquant déjà à l'intérieur.

Suis-je concerné ?

Vous êtes concerné si ces deux conditions sont réunies :

• Votre déploiement exécute PeopleSoft Enterprise PeopleTools 8.61 ou 8.62, les deux versions prises en charge listées comme affectées dans l'enregistrement CVE. Si vous exécutez une version PeopleTools plus ancienne et non prise en charge, l'alerte d'Oracle indique que ces versions ne sont pas testées pour cette vulnérabilité et sont probablement aussi affectées. Traitez donc la chaîne comme présente et prévoyez une migration vers une version prise en charge.
• L'Integration Gateway et l'Environment Management Hub sont déployés, ce qui correspond à l'installation par défaut de l'Environment Management Framework. Les deux fonctionnent comme des applications Oracle WebLogic distinctes, et la chaîne a besoin des deux : PSIGW pour atteindre PSEMHUB, et PSEMHUB pour exécuter du code.

Confirmez la version PeopleTools avec votre administrateur PeopleSoft ou dans My Oracle Support, puis vérifiez les deux chemins nécessaires à la chaîne. Aucun ne demande d'authentification. Testez l'Integration Gateway depuis l'extérieur de votre réseau, car c'est le point d'entrée. Testez l'Environment Management Hub depuis le serveur PeopleSoft lui-même : la chaîne l'atteint via la passerelle depuis l'adresse de bouclage, il suffit donc qu'il soit déployé, pas exposé :

# From a network outside your perimeter: the entry point should be unreachable
curl -s -o /dev/null -w "%{http_code}\n" https://<your-peoplesoft-host>/PSIGW/HttpListeningConnector
# On the PeopleSoft web server itself: any response means the Hub is deployed
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:<pia-port>/PSEMHUB/hub

Pour le premier test, toute réponse autre qu'un délai d'attente ou un refus de connexion signifie que le point d'entrée est exposé et nécessite les décisions d'exposition ci-dessous. Pour le second, toute réponse signifie que le Hub est déployé : une règle de périmètre sur /PSEMHUB/ seule n'arrête pas la chaîne, car la requête forgée vient du serveur lui-même, donc désactivez ou supprimez le Hub comme décrit ci-dessous.

L'alerte de sécurité d'Oracle est la source primaire du correctif et de la matrice de versions exacte : https://www.oracle.com/security-alerts/alert-cve-2026-35273.html

Selon son rapport de juin 2026, Mandiant a notifié plus de 100 organisations dans le monde dont les adresses IP correspondaient à des points de terminaison potentiellement vulnérables ; 68 pour cent d'entre elles étaient des établissements d'enseignement supérieur.

Comment corriger le problème ?

Appliquez le correctif de l'alerte de sécurité d'Oracle du 10 juin 2026 via votre processus de patch PeopleSoft habituel, et restez sur une version PeopleTools prise en charge. Le rapport de septembre de Mandiant est explicite : les règles de WAF et le blocage par chemin ne remplacent pas le correctif.

Si vous ne pouvez pas encore corriger, Mandiant, en s'appuyant sur les recommandations de l'alerte d'Oracle, détaille les étapes qui suppriment l'exposition dont la chaîne a besoin :

• Dans les installations multi-serveurs, désactivez le service Environment Management Hub (EMHub) si vous ne l'utilisez pas pour appliquer des correctifs. Dans les installations mono-serveur, supprimez complètement l'application PSEMHUB. Selon Mandiant, restreindre ces points d'administration ne casse pas les sessions utilisateur normales.
• Si vous ne pouvez pas désactiver le service EMHub, bloquez l'accès externe à /PSIGW/HttpListeningConnector et /PSEMHUB/* au niveau du périmètre réseau ou du pare-feu. C'est la règle sur /PSIGW/HttpListeningConnector qui arrête cette chaîne : la requête forgée atteint le Hub depuis le serveur lui-même et ne traverse donc jamais le périmètre. La règle sur /PSEMHUB/* reste utile, car lors de la vague de septembre les attaquants ont aussi envoyé des requêtes directement à un Hub exposé.
• Appliquez toute règle au chemin décodé et normalisé. Dans la vague de septembre, ShinyHunters a contourné des règles WAF bloquant /PSEMHUB/ en demandant /%50SEMHUB/ : de nombreuses règles comparent le texte brut du chemin, alors que le serveur PeopleSoft le décode et sert la page. Mandiant avertit que les attaquants peuvent utiliser toute variante encodée en pourcentage, à casse mixte ou autrement non normalisée.

Si vous êtes peut-être déjà compromis, traitez tout hôte portant un web shell comme compromis, préservez les preuves et réinitialisez chaque identifiant accessible depuis la couche PeopleSoft. ShinyHunters vole des données puis exige un paiement : préparez-vous à l'extorsion. Le correctif ferme la porte ; les sources ci-dessous ne prétendent pas qu'il évince quiconque est déjà à l'intérieur.

Quelle est la cause profonde ?

Oracle a isolé l'Environment Management Hub derrière une liste d'hôtes approuvés qui approuve l'adresse de bouclage par défaut, tout en laissant l'Integration Gateway transmettre toute requête vers n'importe quelle URL ; ensemble, le mur devient une porte.

Bobby Gould de la ZDI, avec Minh Giang et Lucas Miller de TrendAI Research, a signalé la chaîne à Oracle le 10 juin 2026 et publié la décomposition le 27 octobre 2026. Trois failles sur les deux composants :

Faille 1 : SSRF dans PSIGW (ZDI-CAN-31816). L'Integration Gateway échange des messages entre le serveur PeopleSoft et des systèmes distants via des Listening et Target Connectors. Un POST vers /PSIGW/HttpListeningConnector nommant le gestionnaire HttpTargetConnector permet à l'attaquant de choisir à la fois l'URL que la passerelle contacte et la charge complète qu'elle y transfère, dans le champ Data de la requête. La ZDI a décompilé le gestionnaire et n'y a trouvé aucune validation que le trafic est légitime ou destiné à une cible valide : il prend l'URL cible depuis la requête de l'attaquant, construit l'objet de requête, applique la méthode HTTP et envoie le contenu de l'attaquant tel quel.

Le facilitateur : PSEMHUB approuve le bouclage par défaut. L'Environment Management Hub est une interface d'administration interne censée ne répondre qu'à des hôtes de confiance. Sa méthode validateClient compare le client demandeur à /envmetadata/config/allowedhosts.properties, et le fichier par défaut livré avec PeopleSoft contient déjà une entrée localhost ; l'ensemble autorisé comprend aussi le nom d'hôte et l'adresse IP résolus du serveur. Une requête arrivée par le SSRF depuis 127.0.0.1 semble donc provenir de la machine elle-même, et la vérification de confiance réussit.

Faille 2 : contrôle externe du chemin de fichier dans PSEMHUB (ZDI-CAN-31818). Le gestionnaire ExecuteProcessActivityCommand de PSEMHUB sert à laisser des clients distants écrire des entrées de journal sur le système de fichiers du serveur. L'appelant contrôle à la fois le contenu du fichier, dans le paramètre m_line, et le chemin absolu sur le disque, dans m_targetFile. Le gestionnaire ne vérifie en rien que le chemin pointe vers un répertoire de journal légitime. Écrire un web shell JSP dans le chemin WAR de PSEMHUB donne une exécution de code immédiate sous le compte de service PeopleSoft.

Faille 3 : désérialisation de données non fiables dans PSEMHUB (ZDI-CAN-31817). Avec n'importe quelle primitive d'écriture de fichier, un attaquant place un fichier XML malveillant dans [docroot]/envmetadata/data/environment/. À la prochaine initialisation de la classe HubServlet de PSEMHUB, après un redémarrage du système ou du service, elle charge chaque fichier de ce répertoire et le passe à XMLDecoder de Java. XMLDecoder instancie et configure les objets décrits dans le XML pendant l'analyse, donc la charge de l'attaquant s'exécute avant que la conversion vers Environment ne lève une exception. Ce chemin n'a pas besoin de web shell et risque moins d'être détecté par les méthodes standard.

Comment la faille est-elle exploitée ?

Toute la chaîne est non authentifiée : rien ne demande de connexion PeopleSoft. Étape par étape, selon l'analyse de la ZDI :

1. L'attaquant fait un POST vers /PSIGW/HttpListeningConnector, nomme le gestionnaire HttpTargetConnector, fixe la cible sur l'adresse de bouclage (par exemple http://127.0.0.1:8000) et place la requête interne dans le champ Data.
2. L'Integration Gateway transfère cette requête interne vers la cible de bouclage. Elle arrive à PSEMHUB en semblant provenir de la machine elle-même.
3. validateClient compare le demandeur à allowedhosts.properties, y trouve l'adresse de bouclage de la liste par défaut, et renvoie vrai.
4. L'attaquant atteint les gestionnaires de commandes de PSEMHUB via le SSRF et appelle ExecuteProcessActivityCommand, fournissant le contenu du web shell dans m_line et un chemin absolu dans le WAR de PSEMHUB dans m_targetFile.
5. Le web shell est écrit dans le répertoire applicatif, et les requêtes vers lui exécutent des commandes sous le compte de service PeopleSoft. Alternativement, la même primitive d'écriture dépose un fichier XML dans envmetadata/data/environment/, et la charge s'exécute via XMLDecoder au prochain redémarrage du service, sans web shell à trouver.

Dans les campagnes observées, les attaquants sont allés plus loin : le triage par Mandiant des serveurs de staging de juin a trouvé des agents MeshCentral déguisés en services Microsoft Azure et un script de mouvement latéral et de défiguration, et des données volées aux victimes sont apparues sur le site de fuite de ShinyHunters. Dans la vague de septembre, Mandiant a observé des web shells JSP comme x.jsp et u.jsp écrits dans le WAR de PSEMHUB, un installateur piégé portant la porte dérobée SIDEEYE, et une exécution de commandes sans fichier qui n'écrit rien sur le disque.

Comment se déroule la chaîne d'attaque ?

Une seule chaîne de requêtes, d'une position internet non authentifiée à l'exécution de code sous le compte de service PeopleSoft :

Que peut faire un attaquant ?

Une exploitation réussie donne une exécution de code à distance non authentifiée avec les privilèges du compte de service PeopleSoft sur la couche web. Mandiant note que ce compte peut lire les fichiers de configuration PeopleSoft, les chaînes de connexion à la base de données et les données applicatives, et UNC6240 s'est servi de ce point d'appui pour la pulvérisation d'identifiants, le mouvement latéral, le vol de données et l'extorsion. Conditions nécessaires :

• Un accès réseau au listening connector de PSIGW et, à travers lui, à PSEMHUB. Aucun identifiant PeopleSoft, aucune interaction utilisateur.
• L'Environment Management Framework déployé avec ses valeurs par défaut : PSEMHUB présent, allowedhosts.properties portant encore l'entrée de bouclage, et le HttpListeningConnector de PSIGW accessible.
• Pour le chemin de désérialisation uniquement, un redémarrage du service ou du système après le dépôt du fichier XML.

Pourquoi le correctif fonctionne-t-il ?

L'alerte de sécurité d'Oracle du 10 juin 2026 a corrigé les trois failles sous le CVE unique ; la ZDI indique coordonner avec Oracle l'attribution d'un CVE distinct à chacune. Ni l'alerte d'Oracle ni l'article de la ZDI ne publient de diff de code source ni n'expliquent comment chacune des trois failles est fermée.

La solution de repli découle de la structure de la chaîne : les deux chemins d'exécution de code décrits par la ZDI vivent dans PSEMHUB, donc supprimer PSEMHUB casse la chaîne publiée même si le SSRF de PSIGW demeure, bien que ce SSRF puisse encore atteindre tout autre service sur l'adresse de bouclage. La vague de septembre montre la limite du seul blocage : les attaquants se sont adaptés aux règles par chemin avec /%50SEMHUB/, et c'est pourquoi Mandiant affirme que le blocage par chemin ne remplace pas le correctif de l'alerte.

Comment vérifier si j'ai été compromis ?

Les rapports de Mandiant de juin et septembre 2026 donnent des chasses précises ; exécutez-les sur la période depuis le 27 mai 2026.

Dans les journaux d'accès WebLogic de la PIA, recherchez les requêtes POST vers /PSEMHUB/hub et /PSIGW/HttpListeningConnector provenant d'adresses IP externes. Les partenaires Integration Broker légitimes envoient aussi des POST au listening connector : comparez donc chaque source à vos partenaires connus ; une occurrence venant d'une adresse externe inconnue avant votre date de correctif désigne la chaîne.

Dans la vague de septembre, la même attaque apparaît sous la forme /%50SEMHUB/, et les web shells sont demandés comme fichiers .jsp sous ce chemin : décodez donc le chemin et comparez-le sans tenir compte de la casse :

# PIA WebLogic access log; decode the path first so /%50SEMHUB/ and other encoded forms match too
python3 -c 'import sys, urllib.parse; sys.stdout.writelines(urllib.parse.unquote(l) for l in open(sys.argv[1], errors="replace"))' <PS_CFG_HOME>/webserv/<domain>/servers/PIA/logs/PIA_access.log | grep -iE "POST /(PSEMHUB|PSIGW/HttpListeningConnector)|/PSEMHUB/[^ ]*\.jspx?"

Sur le système de fichiers de la couche web de chaque nœud WebLogic, pas seulement du premier trouvé, cherchez les fichiers laissés par la chaîne et les web shells :

# JSP, JSPX and EXE files in the PSEMHUB and PORTAL WARs; flag any that are not part of the shipped product
find <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PORTAL.war \( -name "*.jsp" -o -name "*.jspx" -o -name "*.exe" \)
# XML files the deserialization path loads at the next restart; review any recently created or modified
find <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/envmetadata/data/environment -name "*.xml" -ls
# Unauthorized content in the hub's transactions directory
find <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war/envmetadata/transactions
# Unexpected logs, persistantstorage or scratchpad directories under PSEMHUB
find <PS_CFG_HOME>/webserv/<domain>/applications/peoplesoft/PSEMHUB.war -type d \( -name logs -o -name persistantstorage -o -name scratchpad \)

Puis les indicateurs publiés par Mandiant, pour la plupart récupérés en juin sur les serveurs de staging de l'attaquant :

• Des binaires d'agent MeshCentral nommés meshagent32-azure-ops.exe, meshagent64-azure-ops.exe et meshagent64-v2.exe, codés en dur vers l'adresse de commande et contrôle wss://azurenetfiles.net:443/agent.ashx, un domaine imitant Microsoft Azure NetApp Files.
• Les adresses IP de staging 142.11.200.186 à 142.11.200.190, hébergeant des serveurs Python SimpleHTTP sur le port 8888, et 176.120.22.24, le miroir public du site de fuite de ShinyHunters auquel les serveurs de staging se sont connectés en SSH.
• Un script de mouvement latéral et de défiguration nommé d'après la victime, [victim_abbreviation]_fanout.sh.
• Du trafic SMB sortant (port TCP 445) des serveurs PeopleSoft vers des destinations externes non fiables dans les journaux de pare-feu et les données NetFlow.
• D'après le rapport de septembre : l'adresse de commande et contrôle de SIDEEYE 162.219.30.165 sur les ports TCP 3333 et 3334, et l'infrastructure MeshAgent sur azurenetfiles.net, microsoft-entra.net, enroll.azuredevice.cloud et winmanage-me.network (104.219.234.138).

Chronologie

• 2026-05-27 au 2026-06-09 : ShinyHunters (UNC6240) exploite la chaîne comme zéro-day, avant tout correctif ou avis de sécurité, principalement contre des universités. L'environnement de staging de l'attaquant a été installé le 27 mai à 22:14 UTC (Mandiant/GTIG).
• 2026-06-09 : des données volées d'organisations compromises apparaissent sur le site de fuite de ShinyHunters ; des rapports publics exposent des répertoires ouverts sur les serveurs de staging.
• 2026-06-10 : la ZDI signale les trois failles à Oracle ; Oracle publie son alerte de sécurité hors bande corrigeant les trois sous CVE-2026-35273.
• 2026-06-11 : l'enregistrement CVE est publié avec le vecteur CVSS v3.1 9,8 ; Mandiant et le GTIG publient leur attribution et indiquent avoir notifié plus de 100 organisations, 68 pour cent dans l'enseignement supérieur.
• 2026-06-12 : la CISA ajoute CVE-2026-35273 à son catalogue KEV, échéance fédérale le 15 juin 2026.
• 2026-09-25 : Mandiant signale une nouvelle vague d'exploitation massive qui utilise le contournement WAF /%50SEMHUB/ et touche enseignement supérieur, technologie, services informatiques, santé, agriculture, transport et gouvernement, avec des web shells sur des dizaines de systèmes dans le monde.
• 2026-10-27 : la ZDI publie la décomposition en trois failles du CVE unique ; des CVE distincts pour chaque faille sont en coordination avec Oracle.
• 2026-10-29 : cet article.

FAQ

Bloquer le chemin PSEMHUB au pare-feu suffit-il ?

Non. Mandiant est explicite : le blocage par chemin n'est pas un substitut au correctif, et la vague de septembre l'a prouvé : les attaquants ont demandé /%50SEMHUB/ et contourné les règles comparant le chemin en texte brut, car PeopleSoft décode le chemin et sert la page. Le blocage aide en attendant le correctif, et la règle doit reconnaître la forme décodée.

Appliquer le correctif évince-t-il un attaquant déjà à l'intérieur ?

Aucune source ne l'affirme. L'alerte d'Oracle n'aborde pas l'éviction, et les conseils de Mandiant de réinitialiser chaque identifiant accessible depuis la couche PeopleSoft et de chercher des web shells supposent que l'attaquant reste. Corrigez, puis traitez l'hôte comme un incident.

Seul le secteur de l'éducation a-t-il été attaqué ?

La vague de juin y était concentrée : 68 pour cent des plus de 100 organisations notifiées par Mandiant étaient des établissements d'enseignement. Le rapport de septembre de Mandiant décrit une vague plus étendue touchant enseignement supérieur, technologie, services informatiques, santé, agriculture, transport et gouvernement, avec des web shells sur des dizaines de systèmes dans le monde.

Est-ce une seule vulnérabilité ou trois ?

Trois. La ZDI a signalé le SSRF de PSIGW (ZDI-CAN-31816), le contrôle de chemin de fichier de PSEMHUB (ZDI-CAN-31818) et la désérialisation PSEMHUB (ZDI-CAN-31817) comme des vulnérabilités distinctes, et Oracle a corrigé les trois sous le CVE unique de juin. La ZDI coordonne avec Oracle l'attribution d'un CVE distinct à chacune.

J'exécute une version PeopleTools plus ancienne. Suis-je affecté ?

L'enregistrement CVE et l'alerte d'Oracle listent 8.61 et 8.62, les versions prises en charge, comme affectées. L'alerte indique que les versions hors Premier Support ou Extended Support ne sont pas testées et sont probablement aussi affectées : traitez donc la chaîne comme présente et migrez vers une version prise en charge et corrigée.

Inventoriez vos points de terminaison PeopleSoft exposés

Utilisez Ostorlab Attack Surface Discovery pour inventorier les hôtes exposés à internet que vous possédez et repérer les points de terminaison PeopleSoft Integration Gateway et Environment Management Hub exposés, les chemins /PSIGW/HttpListeningConnector et /PSEMHUB/ dont cette chaîne a besoin, afin de vérifier qu'aucun n'est accessible depuis l'extérieur de votre périmètre.

Références

• ZDI, Bobby Gould, « CVE-2026-35273: SSRF to RCE in Oracle PeopleSoft », 27 octobre 2026 : la décomposition en trois failles, l'analyse de validateClient, le comportement de la requête et du gestionnaire PSIGW, et les deux chemins d'exécution de code : https://www.zerodayinitiative.com/blog/2026/10/20/cve-2026-35273-ssrf-to-rce-in-oracle-peoplesoft (consulté le 29 octobre 2026)
• Alerte de sécurité Oracle CVE-2026-35273, 10 juin 2026 : le correctif, les versions affectées 8.61 et 8.62, la matrice de risque CVSS 9,8, les crédits des chercheurs et la note sur les versions non prises en charge : https://www.oracle.com/security-alerts/alert-cve-2026-35273.html (consultée le 29 octobre 2026)
• Enregistrement CVE-2026-35273 : PeopleTools 8.61 et 8.62 affectés, CVSS v3.1 9,8, Oracle CNA : https://cveawg.mitre.org/api/cve/CVE-2026-35273 (consulté le 29 octobre 2026)
• Catalogue KEV de la CISA : CVE-2026-35273 ajouté le 12 juin 2026, échéance fédérale le 15 juin 2026, action requise au titre du BOD 26-04 : https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-35273 (consulté le 29 octobre 2026)
• Mandiant et Google Threat Intelligence Group, « ShinyHunters Targets Education Sector with Oracle PeopleSoft Exploit », 11 juin 2026 : l'attribution du zéro-day du 27 mai au 9 juin, les plus de 100 organisations notifiées dont 68 pour cent dans l'enseignement supérieur, les indicateurs des serveurs de staging, les agents MeshCentral et les conseils de remédiation et de chasse : https://cloud.google.com/blog/topics/threat-intelligence/shinyhunters-targets-education-sector-oracle-exploit (consulté le 29 octobre 2026)
• Mandiant et Google Threat Intelligence Group, « ShinyHunters Renewed Mass Exploitation Campaign Targeting Oracle PeopleSoft », 25 septembre 2026 : la vague élargie à d'autres secteurs, le contournement WAF /%50SEMHUB/, les indicateurs des web shells et de SIDEEYE, et les conseils actualisés de chasse et de réinitialisation des identifiants : https://cloud.google.com/blog/topics/threat-intelligence/shinyhunters-renewed-mass-exploitation-campaign-targeting-oracle-peoplesoft (consulté le 29 octobre 2026)