Back
LuaRocks.org Discloses RCE Breach: Entire Database Assumed Exposed
SiTech AI Team3 წთ. საკითხავი

LuaRocks.org Discloses RCE Breach: Entire Database Assumed Exposed

LuaRocks.org says a remote code execution vulnerability in its website was exploited several times between July 9 and August 20, 2026. The site was moved to a new server, and all API keys, sessions and 2FA secrets were revoked.

LuaRocks.org, the package repository for the Lua programming language, says a remote code execution vulnerability in its website was exploited several times between July 9 and August 20, 2026. The report arrived on September 25, coordinated through CISA, and the flaw was fixed on September 26.

Because an attacker had code execution on the server, everything that machine could access is treated as exposed. The site has been moved to a newly built server, and every credential the old server held has been revoked and replaced. No evidence was found that existing packages were modified.

What users should do

All API keys and sessions have been revoked, so users need a new API key to publish packages and must log in again. Passwords are stored as bcrypt hashes: slow to crack, but they should be considered exposed, so change the password and change it anywhere else it was reused. 2FA secrets were exposed and removed, so two-factor authentication must be set up again.

The maintainers also recommend upgrading LuaRocks to 3.12 or newer, especially on LuaJIT or Lua 5.1: older releases will run precompiled bytecode if a server sends it in place of a rockspec or manifest. The packages bcrcewon, 7e0b94029db0 and 7e0b9402f9c8, uploaded by the attacker on August 7 and since removed, should be treated as a compromise of any machine that installed them.

How the flaw worked

Rockspecs are Lua files, and LuaRocks.org runs them in a restricted environment to read a package's name and version. The loading function accepted precompiled LuaJIT bytecode as well as Lua source. LuaJIT does not verify bytecode, so a crafted file could read and write memory outside the restricted environment and run arbitrary code inside the web server. Any registered user could trigger this by uploading a rockspec; the fix loads rockspecs as text only and rejects bytecode.

What happened

The project found three accounts created for the purpose. On July 9, shell commands were run on the server through malicious uploads. On August 7 they were run again, and three malicious packages were published. On August 16 and 20 came several hundred automated attempts through the upload API, reusing the published payloads. The server account had full administrative access, so the team assumes the attacker could read anything, including the entire database.

Exposed data includes usernames, email addresses, bcrypt password hashes, API keys, 2FA secrets, session records with IP addresses and browser details, and GitHub tokens that only covered profile and email access. LuaRocks.org keeps a daily git mirror of all packages: comparing it with the July 8 copy and the database showed every difference was a normal upload, copy or deletion, and only the attacker's rockspecs contained bytecode. The team fixed the flaw, removed the attacker's packages from the site and all mirrors and revoked all credentials. One limit remains: a package deleted by the attacker looks the same as one deleted by its owner.

SSiTech

SiTech — AI-powered web development

We build fast, modern websites and bring AI into real business workflows. Have a project or a question? We'd love to help.