- Sources: primary, discussion
- Summary: The disclosure states LuaRocks.org runs an uploaded rockspec to read its metadata, sandboxing it with an empty environment and an instruction limit, but loaded it with loadstring without restricting the input to text, so on LuaJIT the same call also accepted precompiled bytecode that LuaJIT does not verify, and crafted bytecode reads and writes outside its own data, finds the real Lua state and escapes the sandbox, reachable by any registered user. Exploitation ran from 2026-07-09 to 2026-08-20 and was found only while fixing a report received 2026-09-25 through CISA, three attacker packages named bcrcewon, 7e0b94029db0 and 7e0b9402f9c8 were published on 2026-08-07, and anyone who installed one is told to treat that machine as compromised. The maintainers state they found no evidence that existing packages were modified, checked against a daily copy of every published rockspec into a public git mirror held off the server, and also state that they cannot verify what the compromised server sent to clients and that an attacker deletion is indistinguishable from an owner deletion.
- Why it matters: Every LuaRocks.org user has to act, because all API keys and sessions are revoked and bcrypt password hashes and stored two-factor secrets are treated as exposed, and LuaRocks 3.11.1 and older load rockspecs and manifests the same way and will run precompiled bytecode a server sends on LuaJIT or Lua 5.1, so the upgrade to 3.12 is a client-side fix as well as a server-side one.
send feedback on this story