
CVE-2026-31816 - Contournement de l'authentification Budibase menant à une exécution de code à distance (RCE)
CVE-2026-31816 est une vulnérabilité critique de contournement d'authentification et d'autorisation affectant Budibase.
La vulnérabilité se situe dans le middleware d'autorisation côté serveur chargé de protéger les points de terminaison API. Budibase tente d'identifier les points de terminaison webhook légitimes à l'aide d'une expression régulière non ancrée et évalue cette expression contre ctx.request.url de Koa.
Étant donné que ctx.request.url contient la chaîne de requête, un attaquant peut injecter un chemin ressemblant à un webhook dans le composant de requête d'une demande API par ailleurs sans rapport.
Par exemple :
/api/integrations?/webhooks/trigger
La demande ne cible pas réellement le point de terminaison webhook. Cependant, le contrôle vulnérable peut interpréter /webhooks/trigger comme la preuve que la demande est une demande webhook légitime et autoriser la poursuite de l'exécution sans les contrôles d'authentification et d'autorisation normaux.
La NVD décrit le problème comme permettant à un attaquant distant totalement non authentifié d'accéder aux points de terminaison API côté serveur en ajoutant un motif de chemin webhook à l'URL.
| Champ | Valeur |
|---|---|
| CVE | CVE-2026-31816 |
| Fournisseur | Budibase |
| Produit | Budibase |
| Versions affectées | <= 3.31.4 |
| Sévérité | Critique |
| CVSS v3.1 | 9.1 |
| Vecteur CVSS | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| CWE | CWE-74 |
| Vecteur d'attaque | Réseau |
| Privilèges requis | Aucun |
| Interaction utilisateur | Aucune |
| Authentification requise | Non |
La NVD référence les versions de Budibase jusqu'à 3.31.4 comme affectées et attribue un score CVSS 3.1 de 9.1.
La logique vulnérable est centrée sur la détection de webhook effectuée avant l'autorisation normale.
L'avis de sécurité documente un code conceptuellement équivalent à :
const WEBHOOK_ENDPOINTS = new RegExp(
[
"webhooks/trigger",
"webhooks/schema",
"webhooks/discord",
"webhooks/ms-teams"
].join("|")
)
export function isWebhookEndpoint(ctx) {
return WEBHOOK_ENDPOINTS.test(ctx.request.url)
}
Le problème est la combinaison de deux comportements :
ctx.request.url contient la chaîne de requête.Cela signifie que l'expression n'a pas besoin de correspondre au chemin de requête réel.
Une demande telle que :
/api/some/protected/endpoint?/webhooks/trigger
contient toujours la chaîne :
/webhooks/trigger
à l'intérieur de l'URL testée.
Le middleware d'autorisation traite ensuite la demande comme une demande webhook et atteint le point de terminaison sans effectuer le flux d'autorisation normal.
L'avis de sécurité Budibase identifie explicitement cela comme la faille sous-jacente et note que le contournement ignore l'authentification, l'autorisation, les contrôles de rôle et la protection CSRF.
Une demande normale vers un point de terminaison API protégé devrait passer par la couche d'authentification.
Par exemple :
GET /api/integrations HTTP/1.1
Host: target.example
Connection: close
Une instance vulnérable peut à la place être atteinte avec le motif webhook dans la chaîne de requête :
GET /api/integrations?/webhooks/trigger HTTP/1.1
Host: target.example
Connection: close
La partie importante est :
?/webhooks/trigger
Le point de terminaison lui-même n'a pas changé :
/api/integrations
Seule la chaîne de requête a été modifiée.
L'avis public Budibase démontre cette technique exacte contre /api/integrations et plusieurs autres points de terminaison côté serveur.
Une façon sûre de vérifier le contournement d'authentification dans un laboratoire contrôlé est de comparer une demande ordinaire avec la variante de requête webhook.
GET /api/integrations HTTP/1.1
Host: 127.0.0.1:10000
Connection: close
GET /api/integrations?/webhooks/trigger HTTP/1.1
Host: 127.0.0.1:10000
Connection: close
Le serveur vulnérable peut traiter la seconde demande sans les contrôles d'authentification qui protégeraient normalement le point de terminaison.
Un PoC publié utilise également :
/api/integrations?/webhooks/trigger
comme simple vérification de vulnérabilité.
Ce qui suit démontre la structure d'une demande API authentifiée transformée en demande non authentifiée par l'ajout du motif webhook.
POST /api/ta_users/search?/webhooks/trigger HTTP/1.1
Host: 127.0.0.1:10000
Content-Type: application/json
x-budibase-app-id: <TARGET_WORKSPACE_ID>
Connection: close
Content-Length: 12
{"query":{}}
L'avis officiel Budibase documente ce point de terminaison comme l'une des surfaces API affectées.
Les autres points de terminaison côté serveur documentés comme accessibles via la même faille incluent :
/api/tables
/api/datasources
/api/automations
/api/roles
/api/integrations
/api/views
/api/plugins
L'observation clé est que la vulnérabilité n'est pas liée à une ressource applicative particulière. Le middleware d'autorisation affecté se trouve devant un large ensemble d'API côté serveur.
Le contournement d'authentification peut devenir considérablement plus grave lorsqu'il est combiné à une API sensible capable d'accepter des fonctionnalités contrôlées par l'attaquant.
Le PoC de ce dépôt enchaîne la vulnérabilité comme suit :