一個在知名非關聯式資料庫 Redis 中不為人知，但已長達 13 年的嚴重漏洞，近日被雲端資安公司 Wiz 的研究團隊揭露，該漏洞被命名為「RediShell」（CVE-2025-49844），允許攻擊者在特定條件下遠端執行任意程式碼 (RCE)，進而完全控制底層主機系統。此漏洞的通用漏洞評分系統 (CVSS) 分數高達 9.9 至 10.0（滿分），被列為 Critical 風險，幾乎所有支援 Lua 指令碼的 Redis 版本都受到影響。
RediShell 快速摘要
漏洞編號： CVE-2025-49844（RediShell）
漏洞類型： Use-After-Free (UAF) + 沙箱逃逸 → 遠端執行任意程式碼（RCE）
影響版本： Redis 3.2 至 8.2.1（所有支援 Lua 的版本）
CVSS 評分： 9.9～10.0（Critical）
修補版本： 6.2.20、7.2.11、7.4.6、8.0.4、8.2.2
目前是否有野外攻擊（ITW）： 尚未觀測到，但可能爆發
高風險場景： Redis 實例未設身份驗證、開放公網存取、未禁用 EVAL 指令
本例為 Redis 8.2.2 的 instance ，已經避開這次 RediShell 的漏洞，建議 Redis 用戶均個別升級自己對應的最新版本。
從 Use-After-Free 到沙箱逃逸
RediShell 漏洞的核心為一個 Use-After-Free (UAF) 型記憶體管理錯誤，發生在 Redis 執行特製 Lua 腳本時的記憶體回收機制中。
攻擊流程如下：
攻擊者需能向 Redis 發送 EVAL 或 EVALSHA 指令（即可執行 Lua 腳本）。
利用設計精妙的惡意 Lua 腳本，使 Lua Garbage Collector（GC）誤釋放仍在使用中的記憶體。
留下懸空指標（Dangling Pointer），在下一步程式存取時，成功觸發 UAF。
接著使用精心設計的 Payload 覆蓋釋放後的記憶體區塊，實現任意程式碼執行（RCE）。
最終，成功跳脫 Redis 的沙箱限制，在主機層執行命令，例如下載、啟動後門或橫向移動。
攻擊門檻：只需具備 Redis 存取權限，且服務未禁用 Lua 執行指令，即可觸發。無需取得 root 權限或直接的主機存取。
全球 33 萬的暴露在公網的 Redis 實例中，高達 6 萬個未啟用驗證
此漏洞之所以危險，在於 Redis 預設未啟用身份驗證，加上大量 Redis 伺服器或服務直接暴露在公網，使攻擊門檻大幅降低。根據 Wiz 掃描結果，全球約有 33 萬個 Redis instance 暴露在公網，其中：
這些暴露在公開網路中的 Redis 伺服器或服務，當中有18%（約 6 萬個） 完全未啟用密碼驗證。
多數 Redis 實例 未限制來源 IP，或未啟用 Protected Mode。
許多 DevOps 團隊或雲端服務仍使用預設設定或直接將 Redis 暴露給外部程式。
這些形同門戶洞開的 Redis 節點，很可能成為下一波網路攻擊的目標。
RediShell 修補與緩解方法
需要立即升級 Redis 至以下官方任一版本或更新修補：
6.2.20
7.2.11
7.4.6
8.0.4
8.2.2
官方已在 GitHub Security Advisory：GHSA-4789-qfc9-5f9q 公開相關資訊。
若暫時無法升級 Redis 的緊急緩解建議
1、限制 Lua 指令執行，透過 ACL 禁用 EVAL、EVALSHA 指令。
2、強化驗證機制，設定強密碼、啟用 requirepass，開啟 Protected Mode。
3、最小權限執行，以非 root 帳號執行 Redis 進程，限制系統層權限。
4、網路隔離，使用防火牆、VPC 等手段限制來源 IP。避免 Redis 直接曝露在公網。
5、監控異常行為，在日誌監控或 SIEM 平台中加強檢視和監控規則，觀察是否有大量 Lua 指令或異常執行頻率。
RediShell 是否已流出？
目前公開 exploit尚未見於 GitHub、ExploitDB 等資安平台，但 Wiz 已證實漏洞可被武器化，並未排除未來可能會有模仿攻擊或改寫版程式碼流出。
資安社群普遍認為，「RediShell」具備高度可複製性，可能成為下一個被廣泛濫用的 RCE 漏洞。
此漏洞尤其對以下場景構成高度風險：
SaaS / DevOps / CI/CD 平台上未設驗證的 Redis 伺服器或服務
將 Redis 部署於容器中，並開放埠號給外部應用直接存取
在 Kubernetes、雲原生架構中被共用但權限控管鬆散的 Redis 節點
Redis 用作 API rate limit、session storage、快取機制但未設 ACL
建議各家公司、機構與開發者不只修補此漏洞，更應全面檢視 Redis 的使用場景與資安設計，DevOps 團隊與雲端部署都需要針對「預設安全性」做評估和防禦。
延伸閱讀：
Redis 官方安全建議文件
Wiz RediShell 技術分析報告
CVE-2025-49844 細節頁面
