Cada vez que sale un CVE crítico, el mismo patrón se repite. Alguien publica un escáner. La gente se lo descarga. Algunos se arrepienten.
El ciclo es predecible. Se divulga una nueva vulnerabilidad. En cuestión de horas, aparecen repositorios en GitHub que dicen probarla. Las herramientas parecen profesionales. Tienen documentación. Consiguen estrellas. La gente confía en ellas y las ejecuta sin leer el código.
A veces sale bien. A veces no.
Un ejemplo reciente involucró CVE-2025-55182. Un escáner apareció en GitHub poco después de que se publicase el CVE. Hacía exactamente lo que decía: probaba la vulnerabilidad. También incluía malware.
El repositorio ha sido eliminado desde entonces tras ser reportado. El código sigue siendo visible a través de copias archivadas si sabes dónde buscar. Pero el daño ya estaba hecho para quien lo ejecutó antes de que lo eliminaran.
Esto no es nuevo. Ha pasado antes y volverá a pasar. El patrón es siempre el mismo.
Se anuncia una vulnerabilidad crítica. Los investigadores de seguridad y las organizaciones se apresuran a entender su exposición. Necesitan saber si son vulnerables. Necesitan saberlo rápido.
Esa urgencia crea una oportunidad. Alguien publica una herramienta que promete comprobar la vulnerabilidad automáticamente. No hace falta leer los detalles del CVE. No hace falta entender los aspectos técnicos. Solo descargar, ejecutar y obtener tu respuesta.
Suena cómodo. La comodidad tiene un coste.
El problema es la confianza. Cuando descargas y ejecutas código de un repositorio aleatorio de GitHub, estás confiando en que el autor tiene tus mejores intereses en mente. Estás confiando en que el código solo hace lo que dice hacer. Estás confiando en que nadie ha comprometido el repositorio o la cuenta del autor.
Eso es mucho suponer. A menudo son incorrectas.
Los actores maliciosos conocen este patrón. Saben que la gente buscará escáneres inmediatamente después de que salga un CVE. Saben que los equipos de seguridad están bajo presión para evaluar su exposición rápidamente. Saben que la urgencia supera la precaución.
Así que publican herramientas que parecen legítimas. Archivos README limpios. Código de aspecto profesional. Quizás incluso alguna funcionalidad básica que realmente funciona. Y en algún lugar de ese código, escondido entre la lógica de escaneo legítima, hay un payload.
Lo que hace ese payload varía. A veces es una puerta trasera. A veces recopila credenciales. A veces exfiltra claves SSH o tokens de AWS. A veces abre una shell inversa. A veces instala mineros de criptomonedas.
Los detalles no importan tanto como el principio: le has dado a un actor no confiable privilegios de ejecución en tu sistema. Lo que quisieran hacer, ahora pueden hacerlo.
La solución es directa pero requiere disciplina: revisar el código antes de ejecutarlo.
Lee el script. Entiende qué está haciendo. Busca llamadas de red. Comprueba a qué archivos accede. Verifica que no esté descargando payloads adicionales. Asegúrate de que no esté enviando datos a ningún sitio donde no debería.
Esto lleva tiempo. Ese es el punto. El tiempo que pasas revisando código es protección contra ejecutar algo malicioso.
Si no tienes tiempo para revisar el código, no tienes tiempo para ejecutarlo. Usa herramientas oficiales de vendors de confianza. Espera a que proyectos de seguridad establecidos lancen sus escáneres. O escribe el tuyo propio basándote en los detalles del CVE.
La urgencia de saber si eres vulnerable es real. Pero ejecutar código no confiable para averiguarlo es cambiar un riesgo por otro. Y el riesgo que asumes al ejecutar código malicioso suele ser peor que el riesgo que plantea la vulnerabilidad en sí.
Piensa en lo que realmente estás haciendo cuando ejecutas un escáner aleatorio de GitHub:
Estás descargando código escrito por alguien que no conoces. Lo estás ejecutando con tus privilegios de usuario, posiblemente como root. Le estás dando acceso a tu sistema de archivos, tu red, tus credenciales, tus variables de entorno. Estás confiando en que no abusará de ninguno de esos accesos.
Esa es mucha confianza para depositar en un repositorio que apareció hace horas y no tiene reputación establecida.
Algunas pautas prácticas:
Mira quién lo ha publicado. ¿Tiene un historial de trabajo de seguridad legítimo? ¿Es conocido en la comunidad? ¿Sus otros repositorios parecen fiables?
Fíjate en la antigüedad. ¿Se creó el repositorio hoy? Eso ya es mala señal. Los investigadores legítimos suelen tener cuentas establecidas.
Lee el código. Léelo de verdad. Línea por línea si es necesario. Si no entiendes qué hace una sección, no lo ejecutes hasta que lo hagas.
Revisa la actividad de red. ¿La herramienta hace peticiones de red inesperadas? ¿Se conecta a dominios que no reconoces? ¿Sube datos a algún sitio?
Comprueba las dependencias. ¿Qué bibliotecas importa? ¿Son paquetes legítimos o podrían ser maliciosos?
Usa sandboxing. Si debes probar algo cuestionable, ejecútalo en un contenedor o VM que esté aislado de tu entorno principal y no tenga acceso a credenciales sensibles.
El escáner CVE-2025-55182 no era sofisticado. El código malicioso era visible si mirabas. Pero la mayoría de la gente no miró. Vieron una herramienta que resolvía su problema inmediato y la ejecutaron.
Esa es la vulnerabilidad que se está explotando. No un fallo técnico en el software. Una tendencia humana a priorizar la comodidad sobre la seguridad cuando está bajo presión.
Los atacantes apuestan a que no leerás el código. Apuestan a que la urgencia de evaluar tu exposición al CVE anulará tus prácticas de seguridad habituales. A menudo tienen razón.
No formes parte de ese patrón. Cuando sale un nuevo CVE y empiezan a aparecer escáneres, resiste el impulso de descargarlos y ejecutarlos inmediatamente. Tómate el tiempo de verificar qué estás ejecutando. Tu postura de seguridad mejorará.
Los pocos minutos que pasas revisando código podrían ahorrarte un compromiso que lleva semanas o meses remediar completamente.
Revisa el código. Verifica qué hace. Piénsatelo dos veces antes de ejecutar nada de fuentes no confiables.
