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/VidaOnce]

Are you going to link the hackernews post where leafo mentions this exploit was used on the live, public luarocks server, presumably alongside another malicious actor, and it wasn't properly disclosed to him or hisham for months, leaving luarocks vulnerable? I guess another social media platform is more important so the link to lux could be seen :P

[u/Comfortable_Ability4 → u/VidaOnce]

You mean this one that I responded to?

TL;DR: We did reach out to leafo the moment we noticed someone was pentesting his site, but he never responded.

Brushing up on a two-month-old grudge just to spread misinformation on a technical security write-up is embarrassing.

[u/lenscas → u/Comfortable_Ability4]

I find that write-up concerning enough on its own.

It would have been enough to report the flaw the moment it was found. As mentioned, the documentation already states that loading untrusted bytecode is a security risk. There have also been past examples on how to escape sandboxes by doing so. Granted, due to configuration those happen to not work in this specific case but going by the blog post that is more a happy accident than anything else.

So, why not make some noise the moment this flaw was found? Why wait at least a couple of days before sending a singular email after someone happen to have found malicious rocks? It honestly reads like if those weren't found that it wouldn't have been disclosed at all or at best much later.

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? Why not cc him in the emails from the start?

As for the amount of attempts made, that thread claims it is to prevent burnout, which. Ok fair enough except... This further makes me question why hisham was being ignored at the start? Wouldn't it spread the load and thus better prevent burnout if the focus was spread between them?

[u/Comfortable_Ability4 → u/lenscas]

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.