LuaRocks gehackt: Welche Zugangsdaten müssen Sie erneuern?

Remote-Code-Lücke bei LuaRocks.org: Angreifer hatten seit Juli Zugriff auf den Paketserver

Michael Dobler

Autor Dr. Web

28. September 2026

2 Min. Lesezeit

Auf LuaRocks.org, dem zentralen Paketregister für die Programmiersprache Lua, führten Angreifer ab dem 9. Juli 2026 eigenen Code auf dem Server aus. Ein registriertes Konto und eine präparierte Paketbeschreibung genügten dafür. Die Betreiber widerriefen inzwischen sämtliche API-Schlüssel und löschten die gespeicherten Zwei-Faktor-Geheimnisse.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Die LuaRocks-Lücke steckte in einem einzigen Funktionsaufruf: Der Server las hochgeladene Paketbeschreibungen mit der Lua-Funktion loadstring ein, ohne Bytecode auszuschließen. Den Fehler meldete der Sicherheitsforscher Vhyrro über die US-Cybersicherheitsbehörde CISA, doch Unbekannte waren ihm um Wochen zuvorgekommen.

Das Wichtigste in Kürze

Jedes registrierte Konto konnte mit präpariertem Bytecode Code auf dem LuaRocks-Server ausführen.
Angreifer nutzten die Lücke ab dem 9. Juli mehrfach und veröffentlichten drei Schadpakete.
LuaRocks.org schloss die Lücke am 26. September und widerrief alle Zugangsdaten.
Nutzer brauchen neue API-Schlüssel, neue Passwörter und den Client ab Version 3.12.

Wie gelangten die Angreifer auf den Server?

Weißes Paket mit Schlüssel, Mond-Symbol und Aufkleber „Geprüft“ vor hellem Hintergrund — Rockspec-Dateien als Lua-Programme ohne Sicherheitsprüfung für Bytecode ausführbar, LuaJIT validiert diesen nicht

Eine Paketbeschreibung, bei Lua Rockspec genannt, ist selbst ein kleines Lua-Programm. LuaRocks.org führte jede hochgeladene Datei deshalb in einer leeren Umgebung ohne gefährliche Funktionen aus.^[1] Die Funktion loadstring akzeptiert in Lua 5.1 und LuaJIT jedoch neben Quelltext auch vorkompilierten Bytecode. LuaJIT prüft solchen Bytecode überhaupt nicht.

Präparierter Bytecode kann so außerhalb seines eigenen Speicherbereichs lesen und schreiben. Vhyrro zeigt in seiner Analyse,^[2] wie ein Angreifer im Arbeitsspeicher die versteckten Debug-Funktionen aufspürt und über sie die gesperrten Lua-Funktionen wieder aufruft. Die Plattform räumt ein, dass sich das Konto des Webservers volle Administratorrechte verschaffen konnte.^[1]

Was taten die Angreifer mit dem Zugang?

LuaRocks.org identifizierte drei eigens angelegte Konten.^[1] Am 9. Juli liefen erste Shell-Befehle über manipulierte Uploads. Am 7. August folgten ein offenbar versuchter Fernzugang und drei Schadpakete namens bcrcewon, 7e0b94029db0 und 7e0b9402f9c8. Auf die Upload-Schnittstelle zielten am 16. und 20. August mehrere hundert automatisierte Angriffsversuche.

Die Betreiber fanden keine manipulierten Bestandspakete. Als Gegenprobe diente ein täglicher Spiegel aller Pakete auf GitHub, außerhalb der Reichweite des Servers. LuaRocks.org geht trotzdem davon aus, dass die Angreifer die komplette Datenbank lesen konnten, darunter bcrypt-Passwort-Hashes und Zwei-Faktor-Geheimnisse.

Elf Wochen offen: die LuaRocks-Lücke im Zeitverlauf

Vom ersten Angriff bis zur Reparatur des Lua-Paketregisters im Jahr 2026

79 Tage

lagen zwischen dem ersten Angriff und der Reparatur

Schadpakete stellten die Angreifer am 7. August ein

Hunderte

automatisierte Angriffsversuche liefen am 16. und 20. August

manipulierte Bestandspakete fand der Abgleich mit dem Spiegel vom 8. Juli

Chronologie des Vorfalls

9. JuliErste Shell-Befehle laufen über manipulierte Uploads auf dem Server.

7. AugustDie Angreifer versuchen einen Fernzugang und veröffentlichen drei Schadpakete.

16./20. AugustSkripte greifen die Upload-Schnittstelle mehrere hundert Mal an.

25. SeptemberDie Meldung des Sicherheitsforschers erreicht LuaRocks.org über die CISA.

26. SeptemberLuaRocks.org schließt die Lücke und widerruft alle Zugangsdaten.

Ist der Fehler ein Einzelfall?

Das Lua-Handbuch warnt vor manipuliertem Bytecode und bietet mit dem Modus „t“ eine reine Textprüfung an.^[3] Das Register nutzt diesen Modus jetzt und weist zusätzlich jede Datei mit dem Bytecode-Kennbyte ab.

RubyGems.org fiel im Januar 2013 einem fast identischen Muster zum Opfer. Über die YAML-Metadaten eines hochgeladenen Pakets führten Angreifer damals eigenen Ruby-Code auf dem Server aus.^[4] In beiden Fällen behandelte die Plattform eine Beschreibungsdatei als harmlose Daten, obwohl das Format Code transportieren kann. Angriffe wie die Kaperung des npm-Pakets keyv oder das manipulierte Rust-Paket arrayref zielten auf einzelne Pakete, während der Angriff auf LuaRocks das Register selbst traf.

Elf Wochen lang bemerkte niemand die Fremden auf dem Server. Ohne den unabhängigen Spiegel auf GitHub könnte LuaRocks.org heute nicht belegen, dass die Pakete sauber geblieben sind.
— Markus Seyfferth, Chefredakteur Dr. Web

Was sollten Unternehmen mit Lua-Projekten jetzt tun?

Der Cyber Resilience Act der EU verpflichtet Hersteller seit dem 11. September 2026, aktiv ausgenutzte Schwachstellen in ihren Produkten binnen 24 Stunden an das zuständige CSIRT und die ENISA zu melden.^[5] Steckt eines der drei Schadpakete in einem ausgelieferten Produkt, beginnt diese Frist. Vier Schritte stehen jetzt an:

Legen Sie neue API-Schlüssel an und tauschen Sie die Schlüssel in Ihren CI-Pipelines aus.
Ändern Sie das LuaRocks-Passwort samt gleichlautenden Passwörtern bei anderen Diensten, danach richten Sie die Zwei-Faktor-Anmeldung neu ein.
Aktualisieren Sie den Client auf LuaRocks 3.12 oder neuer, weil ältere Versionen Paketbeschreibungen unter LuaJIT ebenso unsicher laden.
Durchsuchen Sie Lockfiles und Build-Protokolle nach den drei Schadpaketen. LuaRocks.org stuft jeden betroffenen Rechner als kompromittiert ein.

Andere Register verschärfen ihre Upload-Regeln bereits vorbeugend: PyPI nimmt seit Juli keine neuen Dateien mehr in Releases an, die älter als 14 Tage sind.