Descripción general

Gittensory presenta una vulnerabilidad de control de acceso ausente (CWE-284 / IDOR) en el endpoint REST GET /v1/contributors/:login/profile y en la herramienta MCP gittensory_get_contributor_profile. Ambas rutas omiten la verificación de acceso por colaborador que todos los endpoints hermanos aplican correctamente, permitiendo que cualquier sesión autenticada, token de API o token MCP lea el perfil completo de cualquier colaborador sin autorización.

Para los mineros Gittensor confirmados, esta exposición incluye los campos alphaPerDay, taoPerDay, usdPerDay y, en la ruta REST, también el campo hotkey.

Detalles técnicos

En el archivo src/api/routes.ts, el manejador del perfil devuelve buildContributorProfile(...) sin invocar en ningún momento requireContributorAccess. Todos los endpoints hermanos, como /decision-pack y /repos/:owner/:repo/decision, aplican esta verificación y responden con HTTP 403 ante solicitudes cruzadas entre colaboradores. La ruta de perfil es la única omisión en toda la base de código.

La función buildContributorProfile, definida en src/signals/engine.ts, embebe el campo hotkey y los tres campos *PerDay para cualquier minero confirmado con datos de instantánea disponibles.

La herramienta MCP getContributorProfile, implementada en src/mcp/server.ts, también omite la llamada a requireContributorAccess. Su filtro redactSensitiveForMcp elimina únicamente las claves que coinciden con el patrón hotkey|coldkey|wallet|private_key|privateKey|mnemonic, por lo que el campo hotkey sí queda redactado en la respuesta MCP, pero los campos alphaPerDay, taoPerDay y usdPerDay se transmiten sin ningún tipo de restricción.

El propio código base trata estos campos como secretos en todos los demás contextos: decision-pack.ts extrae el hotkey antes de servir la respuesta, y tres sanitizadores independientes eliminan hotkey y campos de wallet de la salida destinada a IA y comentarios. Esto confirma que la omisión en el endpoint de perfil es un descuido, no un comportamiento intencionado.

Resumen de exposición por vector:

  • REST: hotkey mas los tres campos financieros diarios.
  • MCP: los tres campos financieros diarios (hotkey redactado por el filtro existente).

Prueba de concepto

bash
# Paso 1: Obtener cualquier token valido de sesion, API o MCP.

# Paso 2: Identificar un login objetivo que sea un minero confirmado.

# Paso 3: Consultar el endpoint de perfil sin restriccion
GET /v1/contributors/{target}/profile
# Respuesta: HTTP 200 con gittensor.hotkey, alphaPerDay, taoPerDay, usdPerDay

# Paso 4: Confirmar que el control de acceso existe en endpoints hermanos
GET /v1/contributors/{target}/decision-pack
# Respuesta: HTTP 403, demostrando la ausencia de la verificacion en el perfil

# Paso 5: Via MCP
# Invocar gittensory_get_contributor_profile con {target}
# Resultado: incluye alphaPerDay, taoPerDay, usdPerDay sin autorizacion

Impacto

Cualquier titular de un token valido puede enumerar los ingresos diarios en TAO, alpha y USD de otros mineros sin ninguna autorizacion. Via REST, ademas se expone el hotkey del minero. Todos los mineros con datos de instantanea almacenados en el sistema se ven afectados.

La naturaleza de la vulnerabilidad es una divulgacion cruzada de informacion entre colaboradores autenticados, clasificada como IDOR bajo CWE-284. No se requiere escalada de privilegios ni acceso administrativo: cualquier cuenta autenticada con un token valido puede explotar el fallo de forma inmediata y sistematica contra todos los mineros registrados en la plataforma.