LuaRocks Patches a Bytecode Flaw Attackers Used for Six Weeks

An attacker who could upload a package listing to LuaRocks.org needed no other access to run code on the site's own server, LuaRocks said, describing a bytecode flaw fixed on Sept. 26 that had already been exploited for six weeks before anyone reported it.

The Lua package registry said it received the report on Sept. 25, coordinated through the U.S. Cybersecurity and Infrastructure Security Agency, and shipped a fix the next day. It thanked the researcher who reported the issue without naming them, and its incident page does not mention a CVE identifier.

How a package listing became a remote shell

LuaRocks parses an uploaded rockspec, the file that declares a package's name and version, by running it through Lua's loadstring function inside a sandbox built with setfenv and an empty environment. The parser never told loadstring to accept text only, so a file could contain precompiled Lua bytecode instead of source. On LuaJIT and Lua 5.1, bytecode is not verified, which means a hand-built file can contain instructions that read and write memory outside what the sandbox intended to expose.

A researcher's writeup names the instruction, a day after the fix

Vhyrro, a developer who maintains the Lua sandboxing project Lux and an alternative rocks host called Luanox, published a technical writeup on Sept. 27 crediting the bug to LuaJIT's KNUM instruction, which copies eight bytes into a register with no type check. Patched bytecode using KNUM let Vhyrro read tagged values forward from a script's constants table, locate the package.loaded table that references every loaded function, and pivot through debug.getfenv() to reach the global environment and call loadstring() outside the sandbox. Vhyrro said the approach took about a month of failed attempts, writing that "I had to fail 99 times over the span of a month before the 100th attempt worked." LuaRocks has not said whether Vhyrro is the same person credited in its own incident report.

Six weeks of activity before the report

Date (2026)	Event
July 9	First shell commands run on the server
Aug. 7	Remote shell attempt; three malicious packages published
Aug. 16 and Aug. 20	Hundreds of automated exploit attempts via the upload API
Sept. 25	Report received, coordinated through CISA
Sept. 26	Fix shipped; credentials revoked

The three packages the attackers published, named bcrcewon, 7e0b94029db0 and 7e0b9402f9c8, gave them a foothold to repeat the exploit without re-uploading a crafted rockspec each time.

What the intrusion exposed, and what it didn't touch

Because the flaw ran code inside the web server itself, LuaRocks treated everything that server could reach as exposed: usernames and email addresses, bcrypt password hashes, every API key, two-factor secrets, GitHub OAuth tokens tied to accounts, and session records including IP addresses. The registry moved to a newly built server and revoked every credential the old one held. It said a comparison against a public git mirror predating the first attack, plus a review of every upload between July 9 and Sept. 26, found no evidence that any existing package's contents were altered.

The second time LuaRocks has had to reset everything

This is not the registry's first full credential reset. In March 2019, LuaRocks disclosed that its API keys and password-reset tokens had been generated with Lua's math.random, seeded from a Unix timestamp, making them guessable rather than cryptographically random; it found no evidence that flaw was exploited. The September incident is the first LuaRocks has confirmed was actively used against it.

What LuaRocks is telling its users to do

LuaRocks revoked every API key and ended every session, so users need to log in again and generate new keys. It is urging users to change passwords used elsewhere, re-enable two-factor authentication, and, on LuaJIT or Lua 5.1, upgrade to LuaRocks 3.12 or later, the version that passes loadstring a text-only flag and rejects any file beginning with byte 27. Anyone who installed bcrcewon, 7e0b94029db0 or 7e0b9402f9c8 should treat that machine as compromised, LuaRocks said. Coverage of open-source registry security failures, including WSO2's mislabeled CISA catalog entry and the governance fights documented by OpenClaw's maintainers, suggests registries built by volunteers keep discovering the same lesson only after an intrusion forces it.