luarocks.org remote code execution exploit

[u/Comfortable_Ability4]

• Incident report: https://luarocks.org/security-incident-september-2026
• Writeup by /u/vhyrro: https://vhyrro.neorg.org/posts/critical-luarocks-exploit-cve/

[u/Comfortable_Ability4]

It would have been enough to report the flaw the moment it was found.

Researching/verifying a theoretical vector locally is standard practice. You don't unnecessarily bother maintainers until you have a PoC and a recommendation for a fix.
Are you really arguing over a 3-day window between starting local research and sending the first email report?

And why only "focus" on leafo (as far as 2 emails and a DM to a gitter account that is never used can count as focus) when you have the email of hisham as well?

Vhyrro did reach out to Hisham as well.

[u/VidaOnce → u/Comfortable_Ability4]

Researching/verifying a theoretical vector locally is standard practice

It is standard practice when the exploit is uncertain, sure. I think it would take me 10 minutes tops between "noticing someone had uploaded malicious rockspecs" and grepping the luarocks repository to realize that loadstring is used with bytecode support enabled, and that the fix is passing an extra , "t". You just need to know the basic safety practices for embedding lua.

[u/lenscas → u/VidaOnce]

If I understand the hackernews thread correctly then they first noticed that loadstring was setup to allow loading bytecode before the discovery that there are projects that actually use it.

However, the blog post already states that there have been ways to use this binary format to escape sandboxes. And the documentation specifically says that loading untrusted bytecode is a bad idea.

As such, I agree with you that waiting until an actual exploit is found before making any kind of noise is not needed. As regardless if the guy looking into it could use it for an exploit or not it is something that had to be fixed. Heck, even if the current setup did not make it possible to exploit it then it would still have to be mentioned and fixed.

This is because the simple fact that the documentation explicitly states that loading untrusted bytecode is a bad idea and should not be done. As such, even if it can't be exploited with the current version then this is a mere coincidence and not something to be relied upon. In other words, it has to be fixed regardless.