Exploitation window before disclosure: 42 days (Source: LuaRocks.org security incident report (September 26, 2026))
A file-loading assumption held for years, until it didn't
LuaRocks.org, the main hosting registry for the Lua package manager, disclosed on September 26, 2026 that a remote-code-execution flaw in how it processed uploaded package files had been exploited on its production server between July 9 and August 20, 2026. The report reached the maintainers through CISA's coordinated disclosure process on September 25, and a fix shipped the next day. By the maintainers' own account, the vulnerable code path had existed in the site for a long time before anyone found it.
The root cause was narrow but consequential. When a package's rockspec file is uploaded, LuaRocks.org executes it with Lua's loadstring function inside a stripped-down sandbox, an empty environment with no access to global functions, meant to let the site read metadata like a package's name and version without running arbitrary logic. The parser assumed every upload would be Lua source code. It never told loadstring to reject the alternative input format, precompiled bytecode, which the underlying LuaJIT engine does not verify at all. A hand-built bytecode file can read and write outside its own data and locate the real Lua interpreter state directly in memory, letting it call the very functions the sandbox existed to hide. Any registered user could trigger it by uploading a rockspec through the website or the API.
What the registry says it confirmed, and where the limits are
Because the flaw gave the attacker the same access as the web server process, LuaRocks.org is treating everything that server could reach as exposed: account usernames, emails and bcrypt password hashes, two-factor authentication secrets, GitHub linking tokens, session and activity logs, and credentials for third-party services the old server held. All of it has been revoked, reset or replaced, and the site now runs on a newly provisioned server. Three accounts created specifically for the intrusion uploaded three packages, named bcrcewon, 7e0b94029db0 and 7e0b9402f9c8, on August 7, before removal from the site and its mirrors.
On the question that matters most to anyone pulling packages from the registry, whether existing code was altered, LuaRocks.org says it found no evidence of tampering. The site mirrors its full manifest and every published rockspec into a public git repository daily, which gave investigators an untouched copy from July 8 to diff against. Every file in storage, every upload between July 9 and September 26, and every rockspec from that window was checked against that mirror and against upload logs; only the three attacker-created accounts showed unexplained activity. The maintainers are explicit about what that check cannot rule out: a package an attacker deleted would look identical to one its owner removed, and they cannot verify the exact bytes the compromised server sent to any individual client during the exploitation window.
What to ask your team
This is a package-registry compromise, the same category of risk as an npm or PyPI incident, not a flaw in any single downstream application. Any organization with Lua in its stack, common in embedded systems, game engines and network appliances, has a direct question to answer rather than a hypothetical one. Ask your team to confirm whether any build or deployment pipeline pulled packages from LuaRocks.org between July 9 and August 20, whether the three named malicious packages appear anywhere in a dependency tree, and whether LuaRocks has been upgraded to 3.12 or newer, since 3.11.1 and earlier load rockspecs and manifests from any server the same unsafe way on LuaJIT or Lua 5.1. Separately, ask whether any credentials, API tokens or passwords reused across LuaRocks.org accounts have been rotated, and whether your own package-ingestion tooling validates that uploaded files are the input type it expects rather than assuming it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: luarocks.org.
