Rendered at 21:04:29 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
leafo 1 hours ago [-]
In my opinion, this is a terrible display of "ethical" reporting.
For context, I built and run the luarocks.org website. It's very easy to see I run the website, and find my contact information. I appreciate that they eventually shared the exploit but...
* They sat on this vulnerability for over a month, likely trying to figure out how to fully exploit it, instead of reporting it. (I would imagine their ai agent upon seeing the `loadstring` issue told them "go tell the maintainer immediately", which they ignored)
* They finally reported it through an intermediate, CISA.gov, and never contacted me directly. When CISA eventually reached out to me, it took multiple days for me to get approved to view the report.
* When I got access to the report I stayed up all night doing deep investigation of logs, all packages and doing the server rebuild. I published the security bulletin on the luarocks.org website (https://luarocks.org/security-incident-september-2026) as soon as the server was rebuilt. They saw it and had time to write up this entire dramatized blog post but still haven't contacted me. (I asked for a follow-up through CISA, but I don't know how long those exchanges take.)
* The vulnerability was exploited on production luarocks.org during that time by them, and they failed to mention any production testing in any of their reports, both in the blog post and in the CISA.gov report.
* They position themselves as members of the Lua community, running alternative Lua runtimes and a new Lua package manager, yet they sat on a very critical issue that affected much of the Lua community for an extended period of time.
* Update: they replied to me on CISA, acknowledging that they exercised the exploit on the production server. (This is still not disclosed anywhere) They said they only did a "sleep" test, but our server logs contradict their attempts based on the accounts they revealed to be as part of their testing.
I get it, you found an exploit and you want credit for your hacking skills, but this whole exchange has really rubbed me the wrong way. Since they haven't told me what malicious code they ran on the production server, or verified what accounts they used to exploit the sever on production, it wastes my time when I'm doing forensics to analyze the extent of what happened to make the appropriate decisions incident response.
In the current era of LLM coding, anyone can vibe code a new Luarocks in Rust (or whatever is popular) over a weekend. I think that establishing trust is more important than ever, and this interaction just makes me question the maintainers of Lux. Their own self-interest appears to be above whatever they are trying to do for the Lua community at large.
xx_ns 12 hours ago [-]
Very good write up! Kudos.
I recently wrote about an RCE exploit in the game Project Zomboid (which uses Lua for mods), which also used loadstring as an initial entry point for the exploit chain, but since the Lua interpreter was fully Java, byte-code memory manipulation shenanigans were out of the question for me and I had to pivot in a more traditional way.
The fact that loadstring can also load straight up bytecode was news to me though, that's interesting to know.
Natfan 11 hours ago [-]
any further information on this PZ RCE? as a casual player i'm somewhat interested -- did the vulnerability get patched?
They were very fast to patch it. The patch actually removed loadstring (among the other fixes), which broke a bunch of mods for a while. The vulns themselves could also theoretically be abused by malicious mods, which unfortunately seems to be more commonplace these days.
rurban 15 hours ago [-]
Oh oh, unsafe eval in a sandbox! (loadstring).
In my lua-like sandbox I disabled all escape hatches and unsafe functions physically by #ifndef SANDBOX. No IO, no FFI, no byte code loading, no memory funcs and such.
For context, I built and run the luarocks.org website. It's very easy to see I run the website, and find my contact information. I appreciate that they eventually shared the exploit but...
* They sat on this vulnerability for over a month, likely trying to figure out how to fully exploit it, instead of reporting it. (I would imagine their ai agent upon seeing the `loadstring` issue told them "go tell the maintainer immediately", which they ignored)
* They finally reported it through an intermediate, CISA.gov, and never contacted me directly. When CISA eventually reached out to me, it took multiple days for me to get approved to view the report.
* When I got access to the report I stayed up all night doing deep investigation of logs, all packages and doing the server rebuild. I published the security bulletin on the luarocks.org website (https://luarocks.org/security-incident-september-2026) as soon as the server was rebuilt. They saw it and had time to write up this entire dramatized blog post but still haven't contacted me. (I asked for a follow-up through CISA, but I don't know how long those exchanges take.)
* The vulnerability was exploited on production luarocks.org during that time by them, and they failed to mention any production testing in any of their reports, both in the blog post and in the CISA.gov report.
* They position themselves as members of the Lua community, running alternative Lua runtimes and a new Lua package manager, yet they sat on a very critical issue that affected much of the Lua community for an extended period of time.
* Update: they replied to me on CISA, acknowledging that they exercised the exploit on the production server. (This is still not disclosed anywhere) They said they only did a "sleep" test, but our server logs contradict their attempts based on the accounts they revealed to be as part of their testing.
I get it, you found an exploit and you want credit for your hacking skills, but this whole exchange has really rubbed me the wrong way. Since they haven't told me what malicious code they ran on the production server, or verified what accounts they used to exploit the sever on production, it wastes my time when I'm doing forensics to analyze the extent of what happened to make the appropriate decisions incident response.
In the current era of LLM coding, anyone can vibe code a new Luarocks in Rust (or whatever is popular) over a weekend. I think that establishing trust is more important than ever, and this interaction just makes me question the maintainers of Lux. Their own self-interest appears to be above whatever they are trying to do for the Lua community at large.
I recently wrote about an RCE exploit in the game Project Zomboid (which uses Lua for mods), which also used loadstring as an initial entry point for the exploit chain, but since the Lua interpreter was fully Java, byte-code memory manipulation shenanigans were out of the question for me and I had to pivot in a more traditional way.
The fact that loadstring can also load straight up bytecode was news to me though, that's interesting to know.
e: https://blog.nns.ee/2026/08/26/project-zomboid-vulns/
They were very fast to patch it. The patch actually removed loadstring (among the other fixes), which broke a bunch of mods for a while. The vulns themselves could also theoretically be abused by malicious mods, which unfortunately seems to be more commonplace these days.
In my lua-like sandbox I disabled all escape hatches and unsafe functions physically by #ifndef SANDBOX. No IO, no FFI, no byte code loading, no memory funcs and such.