LuaRocks.org confirma una intrusión y pide renovar claves y contraseñas

Claves de la noticia

• LuaRocks.org reconoce que una vulnerabilidad permitió ejecutar código en su servidor entre julio y agosto de 2026.
• El proyecto ha revocado claves y sesiones, retirado tres paquetes del atacante y trasladado el sitio a un servidor nuevo.
• Los usuarios deben distinguir entre credenciales expuestas, paquetes maliciosos concretos y una posible respuesta manipulada a clientes antiguos.

El repositorio de paquetes de Lua ha publicado un comunicado sobre una intrusión que afecta a quienes mantienen o instalan módulos desde LuaRocks.org. Tras recibir el aviso el 25 de septiembre, el equipo corrigió el fallo el día 26 y reconstruyó el servicio en otra máquina. Su investigación sitúa actividad de explotación entre el 9 de julio y el 20 de agosto. El alcance exacto para cada usuario sigue siendo incierto, pero el propio proyecto enumera medidas inmediatas y verificables.

Un archivo compilado escapó del entorno restringido

Según el comunicado de LuaRocks.org, los rockspecs son archivos Lua que describen los paquetes. El sitio los carga en un entorno restringido para leer el nombre y la versión de cada publicación. La función utilizada admitía también bytecode precompilado de LuaJIT. Como LuaJIT no verifica ese bytecode, un archivo preparado podía leer y escribir memoria fuera de los límites previstos y ejecutar órdenes dentro del servidor web.

La puerta de entrada no exigía controlar previamente a un mantenedor: cualquier usuario registrado podía subir un rockspec por la web o la API. El proyecto dice que el código vulnerable llevaba mucho tiempo en el sitio. La corrección cambia el tratamiento del archivo para cargarlo solo como texto y rechazar el bytecode. Es una diferencia técnica decisiva: limitar funciones disponibles para un script no protege si el intérprete acepta una representación compilada capaz de alterar memoria fuera de ese entorno.

La secuencia conocida va de julio a septiembre

La reconstrucción publicada identifica tres cuentas creadas para la operación. El 9 de julio se ejecutaron órdenes de consola mediante subidas maliciosas. El 7 de agosto hubo nuevas órdenes y un aparente intento de abrir una consola remota; ese día se publicaron tres paquetes maliciosos. Los días 16 y 20 de agosto llegaron varios cientos de intentos automatizados a la API de subida que reutilizaban esas cargas. Esta cronología habla de actividad observada en el servidor, no de una lista completa de personas o equipos afectados.

El aviso coordinado por CISA llegó al proyecto el 25 de septiembre. El 26 se corrigió el fallo, se suspendieron las cuentas implicadas, se retiraron los paquetes y se revocaron credenciales. LuaRocks.org explica que la cuenta del servidor web podía obtener administración completa; por prudencia, trata como accesible para el atacante todo lo que había en esa máquina. Esa es una hipótesis de respuesta al incidente, no una prueba de que cada dato se haya extraído.

Tres riesgos distintos requieren tres respuestas distintas

La primera exposición es la de las cuentas del sitio. LuaRocks.org considera comprometibles nombres de usuario, correos y hashes de contraseñas con bcrypt, además de claves API, secretos de doble factor, sesiones, registros de actividad y credenciales de servicios externos. Ya ha revocado las claves y las sesiones y ha retirado los secretos de doble factor. Un mantenedor que publique paquetes debe crear una clave API nueva; todos los usuarios deben iniciar sesión otra vez, cambiar su contraseña y también modificarla en otros servicios si la reutilizaron. Quien tenía doble factor debe configurarlo de nuevo.

El segundo riesgo es la instalación de los tres paquetes que el proyecto atribuye al atacante: bcrcewon, 7e0b94029db0 y 7e0b9402f9c8. LuaRocks.org indica que se retiraron y pide tratar como comprometida cualquier máquina donde se instalaran. La presencia de uno de esos nombres exige una investigación del equipo y sus credenciales; cambiar solo la contraseña del sitio no resuelve una posible ejecución local. Los mantenedores disponen además de una página de auditoría de seguridad para revisar versiones recientes de sus propios paquetes.

El tercer riesgo depende de la versión del cliente y del intérprete. LuaRocks.org recomienda actualizar LuaRocks a la versión 3.12 o posterior, sobre todo con LuaJIT o Lua 5.1: las versiones 3.11.1 y anteriores en esos entornos podían ejecutar bytecode precompilado si el servidor lo enviaba en lugar de un rockspec o manifiesto. Es una posibilidad técnica distinta de la vulnerabilidad del servidor. El comunicado no demuestra que se hayan servido respuestas maliciosas a clientes; tampoco permite descartarlo por completo.

Qué demuestra la auditoría y qué queda abierto

El equipo comparó todos los archivos de paquetes almacenados con un espejo diario en Git anterior al primer ataque y con su base de datos. Asegura que cada diferencia correspondía a una subida, copia o eliminación normal. También revisó las subidas efectuadas entre el 9 de julio y el 26 de septiembre frente a la actividad habitual de las cuentas y, cuando fue posible, frente al código publicado. No halló subidas atribuibles a terceros fuera de las tres cuentas atacantes; en los rockspecs inspeccionados, solo los paquetes de estas contenían bytecode.

Estas comprobaciones sostienen una conclusión concreta: no hay evidencia de modificación de paquetes ya existentes en el material conservado. No equivalen a una garantía absoluta de integridad histórica. El proyecto advierte que una eliminación hecha por un intruso podría parecerse a la de su propietario y que no puede reconstruir exactamente qué entregó el antiguo servidor a cada cliente. Los rockspecs maliciosos también llegaron a un espejo y a un repositorio público de GitHub antes de ser retirados de ambos.

Para priorizar la respuesta, la división útil es por exposición comprobable. Una cuenta en LuaRocks.org necesita renovar su acceso; un mantenedor necesita además una clave de publicación nueva y revisar sus versiones; un sistema que instaló uno de los tres paquetes nombrados requiere tratamiento de incidente. Los usuarios de clientes antiguos con LuaJIT o Lua 5.1 deben actualizar por el riesgo de bytecode descrito, aunque no haya prueba pública de que ese vector se usara contra ellos. Esta separación evita presentar una sospecha de alcance general como si todos los paquetes hubieran sido alterados y, a la vez, evita minimizar las acciones concretas que el proyecto pide hoy.