LuaRocks 遭 bytecode 攻擊，全庫外洩
LuaRocks.org 官方事件說明 · 2026-09-26
LuaRocks 的 rockspec 解析器會用 loadstring 直接載入上傳內容，卻沒限制輸入必須是純 Lua 原始碼，攻擊者只要丟預先編譯好的 bytecode，就能繞過原本限制建置腳本行為的沙盒，直接在伺服器行程裡存取任意記憶體。LuaRocks 官方於 2026-09-25 收到外部回報，隔天 2026-09-26 就完成修補，並在事件說明中證實，漏洞早在 2026-07-09 到 2026-08-20 之間就已在正式站上被實際利用。對任何在 LuaRocks.org 註冊過帳號、上傳過套件或裝過來路不明套件的人來說，這次事故牽動的是整個 Lua、OpenResty 與 Neovim 外掛生態圈。
漏洞機制
rockspec 是 LuaRocks 用來描述套件的中繼資料檔，內容其實就是一段合法的 Lua 程式碼，寫明套件名稱、版本、原始碼位置與建置規則。因為它本質上是「可執行的設定檔」，LuaRocks 解析時必須把它丟進一個沙盒環境執行，只開放讀取欄位用的安全函式，擋掉 io、os.execute 這類碰觸系統資源的呼叫，不論是使用者端執行 luarocks install 或伺服器端接受上傳，都不會被惡意 rockspec 執行任意程式碼。問題出在解析器呼叫 loadstring 時只檢查內容能不能被載入，沒限制它必須是文字型態的原始碼，而 Lua 的載入函式本來就同時接受原始碼與編譯好的 bytecode。LuaJIT 的 bytecode 格式沒有驗證機制，攻擊者手刻位元組序列，就能在載入階段直接存取記憶體、跳過沙盒對「能呼叫哪些函式」的限制，等於整層防護形同虛設。
攻擊時間軸與規模
官方比對 2026-07-08 的鏡像快照與目前套件儲存內容，並回溯上傳紀錄，確認整起事件由三個攻擊帳號主導。最早濫用發生在 2026-07-09，攻擊者靠這個漏洞在伺服器上執行任意 shell 指令；到了 2026-08-07，同一批帳號進一步嘗試遠端 shell，並上傳三個惡意套件 bcrcewon、7e0b94029db0、7e0b9402f9c8，事後已被下架。2026-08-16 與 2026-08-20 兩天出現數百次透過 API 重放相同攻擊指令的自動化嘗試。官方強調除了這三個套件外，未發現既有正常套件遭竄改的跡象，但由於攻擊者已取得整個伺服器資料庫，外洩範圍必須以全庫規模認定。
- 帳號資料：使用者名稱、電子郵件、bcrypt 密碼雜湊
- 金鑰與驗證：所有 API 金鑰、雙因素驗證（2FA）密鑰
- 第三方整合：GitHub 連動用的 OAuth token、其他第三方服務憑證
- 使用紀錄：登入 session 紀錄，含 IP 位址與瀏覽器資訊
修補與緩解
修補的核心是讓 rockspec 解析器只接受原始碼型態的輸入、拒絕任何 bytecode，堵住繞過沙盒的路徑；修正已併入 2026-09-26 發布的版本，官方要求所有人升級到 LuaRocks 3.12 以上，因為 3.11.1 以前的版本都受影響。除了升版，官方也要求全體使用者重新產生所有機密資料，因為外洩的不只是密碼，還包含能直接冒充身分呼叫 API 的金鑰與 token。若曾安裝前述三個惡意套件，官方建議直接把那台機器視為已淪陷，而不是只移除套件了事。
- 重新產生所有 API 金鑰，並更新到用到它們的 CI／自動化流程
- 變更 LuaRocks 帳號密碼，若其他服務用了同一組密碼也一併更換
- 停用並重新啟用 2FA，重新綁定驗證器
- 將 LuaRocks 升級到
3.12以上版本 - 若曾安裝
bcrcewon、7e0b94029db0、7e0b9402f9c8任一套件，將該主機視為已淪陷，重建或深入鑑識