CVE-2026-23744 – Laboratorio Docker de MCPJam Inspector

Este repositorio es un pequeño laboratorio Docker para comparar una compilación vulnerable frente a una parcheada de MCPJam Inspector para CVE-2026-23744.

Está pensado para aprender y para construir un portafolio público de seguridad: configuración rápida, evidencia clara y capturas de pantalla.

⚠️ Ética / alcance: Solo pruebe en sistemas que le pertenezcan o para los que tenga permiso explícito. Este repositorio es para reproducción local y documentación.

Qué demuestra este laboratorio

• Versión vulnerable (1.4.2) escucha en 0.0.0.0:6274 dentro del contenedor (accesible desde la red si publica el puerto).
• Versión parcheada (1.4.3) escucha en 127.0.0.1:6274 dentro del contenedor (solo loopback), lo que impide el acceso desde fuera del contenedor incluso si publica un puerto del host.
• La superficie de API (/api/mcp/connect) existe y responde sin un desafío de autenticación en la configuración vulnerable.

Esto coincide con el aviso del proveedor / informes públicos:

• Aviso de GitHub (GHSA): https://github.com/advisories/GHSA-232v-j27c-5pp6
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-23744

Estructura del repositorio

.
├── docker-compose.yml
├── vuln/
│   └── Dockerfile
├── patched/
│   └── Dockerfile
└── docs/
    └── (las capturas de pantalla van aquí)

Requisitos previos

• Docker + Docker Compose
• curl

Inicio rápido

Compile y ejecute ambos contenedores:

docker compose up -d --build

Compruebe que están activos:

docker compose ps

Resultado esperado:

• inspector_vuln_142 publicado en 127.0.0.1:6274
• inspector_patched_143 publicado en 127.0.0.1:6275 (pero no debería ser accesible desde el host)

Pasos de validación

2) La API responde (sin puerta de autenticación visible)

El endpoint está presente y responde con un error de validación cuando faltan campos obligatorios:

curl -i -X POST http://127.0.0.1:6274/api/mcp/connect \
  -H 'Content-Type: application/json' \
  -d '{}'

Espere HTTP/1.1 400 y algo como:

{"success":false,"error":"Failed to parse request body","details":"Unexpected end of JSON input"}

3) Diferencia de enlace (el comportamiento real del parche)

Dentro de los contenedores, compruebe qué dirección está escuchando en el puerto 6274:

# vulnerable
docker exec -it inspector_vuln_142 sh -lc "apk add --no-cache iproute2 >/dev/null 2>&1; ss -lnt | grep 6274"

# patched
docker exec -it inspector_patched_143 sh -lc "apk add --no-cache iproute2 >/dev/null 2>&1; ss -lnt | grep 6274"

Resultado esperado:

• vuln: 0.0.0.0:6274
• patched: 127.0.0.1:6274

4) Por qué el mapeo de puertos parcheado "no funciona" (esperado)

Aunque mapeamos 127.0.0.1:6275 -> contenedor:6274, el contenedor parcheado escucha solo en su propia interfaz loopback. Por lo tanto, desde el host, debería ver un cierre de conexión / respuesta vacía.

curl -v http://127.0.0.1:6275/

Esperado: no accesible (esto es la mitigación funcionando).

Para demostrar que la interfaz parcheada sigue funcionando, ejecute curl desde dentro del contenedor:

docker exec -it inspector_patched_143 sh -lc "apk add --no-cache curl >/dev/null 2>&1; curl -i http://127.0.0.1:6274/"

Esperado: HTTP/1.1 200.

5) Prueba de ejecución de procesos

Durante las pruebas locales en el contenedor vulnerable, adjunté strace al proceso del servidor Inspector y observé que generaba un proceso hijo y llamaba a execve().

Intencionalmente no incluyo un payload de exploit listo para ejecutar aquí.

Qué capturar:

execve("/bin/sh", ["sh","-c", "..."], ...) = 0

execve("/usr/bin/...", [...], ...) = 0

el proceso hijo saliendo normalmente (estado 0)

Créditos / referencias

• Aviso de GitHub (GHSA-232v-j27c-5pp6): https://github.com/advisories/GHSA-232v-j27c-5pp6
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-23744

Aviso legal

Este repositorio es para investigación defensiva, educación y verificación reproducible en un entorno controlado. No lo use contra sistemas que no le pertenezcan o para los que no tenga permiso de prueba.