LuaRocks.org revela una ejecución remota de código explotada durante seis semanas
Un fallo al cargar rockspecs permitió ejecutar código en el servidor entre el 9 de julio y el 20 de agosto. Todas las claves de API, sesiones y secretos 2FA están revocados.
LuaRocks ha publicado los detalles del incidente de seguridad que sufrió su servidor. Una vulnerabilidad de ejecución remota de código en LuaRocks.org, reportada a través de CISA el 25 de septiembre y corregida al día siguiente, se explotó en varias ocasiones entre el 9 de julio y el 20 de agosto de 2026. Como el atacante llegó a ejecutar código en la máquina, el proyecto asume que todo lo que ese servidor tenía a su alcance quedó expuesto, base de datos incluida. El sitio ya corre en un servidor nuevo y todas las credenciales del anterior se han revocado y sustituido.
Dónde estaba el agujero
Los rockspecs son ficheros Lua y LuaRocks.org los ejecuta en un entorno restringido al subirlos, solo para leer el nombre y la versión del paquete. La función que los cargaba aceptaba también bytecode precompilado de LuaJIT, que no lo verifica. Un fichero manipulado podía así leer y escribir memoria fuera de ese entorno restringido y ejecutar código arbitrario dentro del servidor web. Cualquier usuario registrado podía dispararlo subiendo un rockspec por la web o por la API. El código responsable llevaba mucho tiempo ahí; la corrección carga los rockspecs solo como texto y rechaza el bytecode.
La investigación localizó tres cuentas creadas para explotarlo. El 9 de julio se ejecutaron comandos de shell mediante subidas maliciosas. El 7 de agosto volvieron a ejecutarse, con un intento aparente de abrir una shell remota, y se publicaron tres paquetes maliciosos: bcrcewon, 7e0b94029db0 y 7e0b9402f9c8. Entre el 16 y el 20 de agosto hubo varios cientos de intentos automatizados contra la API de subida reutilizando esas cargas. La cuenta con la que corría el servidor web tenía acceso administrativo completo, de modo que el atacante pudo leer cualquier cosa.
Qué hay que hacer
Entre lo expuesto hay nombres de usuario, correos y hashes bcrypt de contraseñas, claves de API, secretos de doble factor, tokens de vinculación con GitHub (que solo daban acceso al perfil y al correo, y ya se han revocado desde GitHub), registros de sesión y actividad con IPs y datos de navegador, y credenciales de servicios de terceros, también revocadas.
Toca crear una clave de API nueva, porque todas se revocaron; volver a iniciar sesión; cambiar la contraseña allí donde se reutilizara; y reconfigurar el 2FA si estaba activo. Quien tenga instalado alguno de los tres paquetes maliciosos debe tratar esa máquina como comprometida. Y hay que subir a LuaRocks 3.12 o superior, sobre todo con LuaJIT o Lua 5.1: la 3.11.1 y anteriores ejecutan bytecode precompilado si un servidor lo envía en lugar de un rockspec o un manifiesto.
El proyecto compara cada paquete con el espejo diario en git del 8 de julio y con su base de datos: todas las diferencias se explican por una subida, copia o borrado normales. Revisó las subidas del periodo y los rockspecs en busca de bytecode, y solo los del atacante lo contenían. No hay cambios en el código del sitio ni mecanismos de persistencia. Los propios responsables reconocen los límites: un paquete borrado por el atacante se ve igual que uno borrado por su dueño, y no se puede comprobar qué envió exactamente el servidor comprometido a los clientes. Las dudas se atienden en el rastreador de incidencias de LuaRocks.
