サイバーセキュリティ企業Wizは、Redisに13年間潜んでいた重大度の高い脆弱性が、最大60,000台のサーバーを悪用の危険に晒している可能性があると警告しています。
Redisは、主にアプリケーションキャッシュや高速応答データベースとして使用される、インメモリ型のオープンソースプラットフォームであり、高速かつ高性能な動作を提供します。
デフォルトでは、公式のRedisコンテナは認証を必要としません。これは、インスタンスが内部にデプロイされ、インターネットからアクセスできないことを前提としているためですが、実際には約330,000台のRedisサーバーがインターネット上に公開されており、そのうち60,000台は認証が設定されていません。
「認証がない状態でインターネットに公開されている組み合わせは非常に危険であり、誰でもRedisインスタンスにクエリを送信でき、特にLuaスクリプト（デフォルトで有効）が送信可能です」とWizは指摘しています。
これにより、最近発見されたCVE-2025-49844（CVSSスコア10/10）、RediShellと名付けられた脆弱性が悪用される危険があります。これはuse-after-freeの問題であり、認証済みの攻撃者がリモートで任意のコードを実行できる可能性があります。
Wizは、全クラウド環境の約75%がRedisに依存していることを強調し、攻撃者が悪意のあるLuaスクリプトを送信してバグを誘発し、Luaサンドボックスを脱出してコード実行を達成することで、システムを完全に侵害できると説明しています。
このスクリプトはリバースシェルも展開し、持続的なアクセスを確立することで、攻撃者が認証情報やその他の機密情報を収集し、データの持ち出し、マルウェアのインストール、盗まれた機密データを利用した横展開、権限昇格などを可能にします。
「より多くのRedisインスタンスが内部ネットワークに公開されており、認証が優先されていない場合、ローカルネットワーク内の任意のホストがデータベースサーバーに接続できてしまいます。クラウド環境で足場を得た攻撃者は、機密データにアクセスし、脆弱性を悪用して任意のコードを実行し、機密ネットワーク内で横展開することが可能です」とWizは述べています。
10月3日、Redisバージョン7.22.2-12、7.8.6-207、7.4.6-272、7.2.4-138、6.4.2-131が、この脆弱性へのパッチを適用してリリースされました。Redisはまた、OSS/CEバージョン8.2.2、8.0.4、7.4.6、7.2.11、およびStackバージョン7.4.0-v7、7.2.0-v19も展開しています。
Redisによると、この脆弱性はガベージコレクタの操作によって悪用可能であり、クラウド環境では自動的に新バージョンへアップデートされていますが、自己管理型のインスタンスについてはできるだけ早く最新リリースへアップグレードする必要があります。
Redisはまた、ネットワークアクセスの制限、強力な認証方式の実施、保護モードの有効化（CEおよびOSS）、サーバーにアクセスできるユーザーアカウントに対する最小限の権限設定を推奨しています。
「ファイアウォールやネットワークポリシーを活用して信頼できるソースからのアクセスのみに制限し、不正な接続を防いでください。[…] 信頼できるIDのみがLuaスクリプトやその他のリスクのあるコマンドを実行できるようにしてください」とRedisは述べています。
CVE-2025-49844が実際に悪用された証拠は現時点ではありません。データベースへの不正アクセス、サーバーへの異常なトラフィック、不明なスクリプトコマンドの使用、Luaエンジンに起因する予期しないクラッシュ、異常なコマンド実行やファイルシステムの変更などは、侵害の可能性を示す兆候となります。
「RediShell（CVE-2025-49844）は、基盤となるLuaインタプリタに起因するため、すべてのRedisバージョンに影響を及ぼす重大なセキュリティ脆弱性です。世界中で数十万のインスタンスが公開されていることから、この脆弱性はあらゆる業界の組織にとって重大な脅威となります」とWizは述べています。
メールでのコメントで、Tuskira共同創業者兼CEOのPiyush Sharma氏は、認証なしでインターネットからアクセス可能な数万台のサーバーが存在するという状況下で、この脆弱性が悪用されるリスクを強調しました。
「このLuaベースのuse-after-freeの脆弱性は、積極的な公開範囲管理の必要性を再認識させるものです。セキュリティチームは、継続的な資産発見を通じて誤設定や古いRedisビルドを特定し、安全なシミュレーションを用いて実際の悪用可能性を検証すべきです」とSharma氏は述べています。
「リスクを軽減するためには、信頼できないユーザー向けのLuaを無効化し、エンドポイントおよびネットワークレベルでRedisプロセスの挙動を監視し、公開ノードを分離してください。Redis自体も、より安全なデフォルト設定やファイアウォール保護を採用し、公開範囲を縮小すべきです」と同氏は付け加えました。
