Trois vulnérabilités notées 9.8 ont été publiées le 23 septembre 2026 sur orval, un générateur de code TypeScript très utilisé qui produit des clients d'API à partir d'une spécification OpenAPI. Correction : 8.29.0.
Ces CVE n'ont rien de spectaculaire individuellement — des échappements oubliés. Ce qui mérite un article, c'est le modèle de menace qu'elles révèlent et que beaucoup d'équipes n'ont jamais envisagé : une spécification OpenAPI est du code.
Les trois CVE
| CVE | Générateur | Point d'injection | Versions affectées |
|---|---|---|---|
| CVE-2026-96754 | @orval/hono | Chemins OpenAPI dans des littéraux de route entre apostrophes | avant 8.29.0 |
| CVE-2026-96755 | @orval/effect | Valeurs par défaut du schéma dans des template literals | 8.14.0 → 8.28.1 |
| CVE-2026-96759 | TanStack Query | operationId dans les métadonnées des mutations | avant 8.29.0 |
Vecteur commun : AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
Le mécanisme, en trois variantes
CVE-2026-96754 — une apostrophe dans un segment de chemin :
fails to escape OpenAPI path values in single-quoted route literals. Attackers can craft an OpenAPI document with an apostrophe in a static path segment to inject arbitrary JavaScript code that executes when the generated TypeScript module is imported.
CVE-2026-96755 — une expression ${...} dans une valeur par défaut :
converts OpenAPI schema defaults into template literals. Attackers can inject arbitrary JavaScript expressions via schema defaults containing
${...}syntax, which are executed at module scope when the generated code is built or imported.
CVE-2026-96759 — un operationId piégé :
fails to escape the operationId parameter [...]. Attackers can inject arbitrary JavaScript code through a crafted operationId in an OpenAPI specification that executes when generated hooks are called.
C'est la même erreur à trois endroits : une valeur venant de la spécification est collée dans du code généré sans être échappée. C'est l'équivalent, pour un générateur de code, d'une injection SQL.
Le vrai sujet : d'où vient ta spécification ?
La gravité dépend entièrement de cette question.
Si tu génères depuis ta propre spec, écrite et relue par ton équipe, le risque est faible : l'attaquant devrait déjà pouvoir modifier ton dépôt.
Si tu génères depuis la spec d'un tiers — un partenaire, un fournisseur SaaS, une API publique, une URL récupérée au build — alors tu exécutes du code choisi par ce tiers. Et beaucoup de projets font exactement ça : un script orval qui télécharge la spec du fournisseur à chaque build pour rester synchronisé.
Dans ce cas, compromettre le serveur qui publie la spec suffit à injecter du code dans toutes les applications qui génèrent leur client depuis elle.
Où ce code s'exécute
C'est ce qui rend ces CVE sérieuses :
- Sur le poste du développeur, lors de la génération ou de l'import — avec accès à ses identifiants git, npm, cloud
- Dans la CI, lors du build — avec accès aux secrets du pipeline
- Dans le navigateur des utilisateurs pour CVE-2026-96759 : les hooks TanStack Query font partie du code front-end livré en production. Le code injecté s'exécute chez chaque visiteur, dans le contexte de ton application.
Vérifier son exposition
# Version installée
npm ls orval
npx orval --version
# D'où vient la spec ? Chercher les sources distantes dans la config orval
grep -rnE "input|target" orval.config.* | grep -iE "https?://"
Si la seconde commande renvoie des URL, tu génères depuis une source externe.
Mitigation
- Mettre à jour orval en 8.29.0 ou ultérieur, puis régénérer le code client : le code déjà généré avec une version vulnérable reste vulnérable tant qu'il n'est pas reproduit.
- Relire le code généré actuellement commité si ta spec vient d'un tiers : chercher des constructions inattendues dans les chemins de route, les valeurs par défaut et les métadonnées d'opérations.
- Ne plus télécharger la spec à chaque build. Versionne une copie de la spec dans ton dépôt, et fais passer ses mises à jour par une revue de code comme n'importe quel changement.
- Traiter les générateurs comme des compilateurs d'entrées non fiables : orval, openapi-generator, les générateurs GraphQL ou protobuf reçoivent tous une entrée qui détermine le code produit.
Pourquoi surveiller en continu vos dépendances de build
Un générateur de code n'apparaît dans aucun inventaire de production — c'est une dépendance de développement. Pourtant, il écrit du code qui part en production. Trois CVE à 9.8 sur un outil de ce type, c'est un rappel que la chaîne d'approvisionnement logicielle commence bien avant npm install en production.
Avec cveo.tech, inventorie tes dépendances critiques — y compris les outils de build — et reçois une alerte dès qu'une CVE critique les concerne.