Hay una regla no escrita en ciberseguridad que dice que entre el momento en que sale un parche y el momento en que alguien lo explota, tienes un margen. A veces dÃas, a veces semanas. A veces ocho horas. Eso fue lo que pasó con CVE-2026-66066, bautizado por los investigadores como KindaRails2Shell, y la historia es tan brutal que la tengo que contar.
Qué era el agujero
ActiveStorage, el componente de Rails 8+ que maneja subida de archivos, tenÃa una vulnerabilidad de lectura arbitraria de archivos y ejecución remota de código. O sea, podÃas leer el archivo de secrets de la app y desde ahà saltar a una shell. CVSS 9.5/10. No es un numerito menor: es prácticamente «si tu app usa Rails 8 y tiene ActiveStorage expuesto, te pueden tomar el servidor completo».
El equipo de Rails publicó el parche el 29 de julio de 2026 a las 3 de la tarde. Rietta, una agencia que maneja sitios de gobierno estatal y entidades HIPAA en Estados Unidos, lo vio, pero inicialmente no tenÃa severity asignado. ParecÃa un update más. Horas después el CVSS subió a 9.5 y se declaró emergencia. Patchearon todo esa misma noche, terminando a las 11:30 PM.
El PoC apareció antes que el parche llegara a producción
Esto es lo que me pone los pelos de punta. Un proof-of-concept explotando la vulnerabilidad se subió a GitHub a las 9:47 PM UTC del 29 de julio. Eso es más de 5 horas antes de que Rietta terminara de desplegar el parche en todos sus servidores. Y 13 horas antes del primer ataque real contra uno de sus clientes.
El ataque llegó a las 7:10 AM del 30 de julio. Usaba un BMP malicioso. ¿Adivina qué usaba el PoC de GitHub? Exacto: un BMP malicioso. La correlación es obvia. No fue un hacker genial que patch-diffeó el código en una noche. Fue alguien que bajó un PoC de GitHub y lo ejecutó.
El embargo coordinado que no sirvió para nada
El advisory de Rails prometÃa disclosure completo «no después del 28 de agosto». Un mes de margen para que los equipos patchearan tranquilos. La realidad: al dÃa siguiente ya habÃa herramientas forenses publicadas. Los investigadores de Ethiack, que descubrieron el bug, publicaron su writeup técnico el 31 de julio. El embargo se rompió solo porque múltiples investigadores ya habÃan reverse-engineered el attack y publicado PoCs. Como dijo André Baptista de Ethiack: «Hemos estado conteniendo detalles técnicos para dar más tiempo a los defensores, pero las cosas están pasando demasiado rápido».
Mi lectura de esto
Trabajo en Komatsu AHS administrando VPS y viendo incidentes de seguridad, y esto me hace replantear varias cosas. El modelo de embargo coordinado funciona cuando el exploit es difÃcil de construir. Pero cuando el parche es un diff público y el código está en GitHub, el diff ES el exploit. Cualquiera con tiempo libre y un poco de habilidad puede mirar qué cambió, entender qué se rompió, y construir un PoC en horas.
Si tu app está expuesta a internet y usas Rails 8, esto debiera ser tu pesadilla. No tienes un mes. No tienes una semana. Tienes horas. Y si tu pipeline de deploy no puede moverse en horas, estás jugando a la loterÃa con tu infraestructura.
La segunda lección es para los que mantienen open source: el embargo es cortesÃa, no seguridad. Si el parche es público, el ataque es público. Punto. El modelo de coordinated disclosure necesita una actualización urgente, porque la velocidad a la que se construyen exploits hoy es brutal.
Qué hacer ahora
Si usas Rails 8 o superior, verifica que ActiveStorage esté parcheado. Corre bundle update activestorage rails ya. Revisa tus logs del 29 y 30 de julio por requests sospechosos, especialmente POST a rutas que no existen. Y si tienes un WAF, mira los bloqueos de esos dÃas. Si no tienes nada de esto, al menos configura rack-attack para throttlear probes repetidos.
La ciberseguridad ya no es parchear cuando tengas tiempo. Es parchear antes de que alguien más tenga el tuyo.
Fuente de inspiración: Government Rails Site Hit Hours After CVE Patch
