Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
CVE-2026-32913 — Encontré una vulnerabilidad de día cero en OpenClaw: así fue como ocurrió | Kitploit
Herramientas/GitHubGitHub/rickidevs/cve-2026-32913
Análisis de VulnerabilidadesSeguridad WebAprendizaje y EducaciónRecursos Curados
GitHubrickidevs/cve-2026-32913

CVE-2026-32913

Encontré una vulnerabilidad de día cero en OpenClaw: así fue como ocurrió

Ver Repositorio
hace 5 mesesAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

Al revisar el código fuente, me centré en cómo OpenClaw maneja las solicitudes HTTP, específicamente en la función fetchWithSsrFGuard(), responsable de realizar llamadas fetch del lado del servidor.

Noté algo extraño.

Cuando una solicitud seguía una redirección de origen cruzado (lo que significa que el servidor enviaba una respuesta 3xx apuntando a un dominio diferente), OpenClaw debía eliminar los encabezados sensibles antes de reenviar la solicitud al nuevo destino. Lo hacía, pero solo para una lista de denegación limitada y codificada:

root@kitploit:~
Authorization, Proxy-Authorization, Cookie, Cookie2

¿El problema? Esa lista está incompleta.

Encabezados de autorización personalizados como X-Api-Key, Private-Token o cualquier otro encabezado de tipo bearer que los desarrolladores usan comúnmente — ninguno de esos se eliminaba. Se reenviaban tal cual al destino de la redirección.

Esto significa: si un atacante pudiera controlar o influir hacia dónde apunta una redirección, podría recibir credenciales sensibles que nunca estaban destinadas para él.


Por Qué Esto Es Peligroso

Imagina que tu aplicación usa OpenClaw para llamar a una API interna con un encabezado X-Api-Key personalizado. Un servidor malicioso responde con una redirección a una URL controlada por el atacante. OpenClaw sigue la redirección — y reenvía tu clave API junto con ella.

Fin del juego. Tus credenciales ahora están en manos de otra persona.

Puntuación CVSS 3.1: 9.3 (Crítico)

  • Vector de ataque: Red
  • Complejidad del ataque: Baja
  • Impacto en la confidencialidad: Alto
  • No se requieren privilegios, no se necesita interacción del usuario

La Solución

Los mantenedores reemplazaron el enfoque de lista de denegación con una lista de permitidos de encabezados seguros. En lugar de intentar bloquear encabezados malos conocidos, la nueva lógica solo permite encabezados seguros conocidos en redirecciones de origen cruzado — cosas como negociación de contenido y validadores de caché. Todo lo demás se elimina por defecto.

Este es el enfoque correcto. La seguridad basada en listas de denegación es frágil; la seguridad basada en listas de permitidos es robusta.

Referencias

  • Registro CVE: CVE-2026–32913
  • Aviso de GitHub: GHSA-6mgf-v5j7-45cr
  • Commit de corrección: 46715371b0612a6f9114dffd1466941ac476cef5
  • Versiones afectadas: <= 2026.3.2
  • Versión parcheada: >= 2026.3.7

Si Estás Usando OpenClaw

Actualiza inmediatamente a >= 2026.3.7.

Si usas encabezados de autorización personalizados (como X-Api-Key o Private-Token) y estabas en una versión anterior, trata esas credenciales como potencialmente comprometidas y rótalas.

Descargar herramienta