2025年10月に公表されたCVE-2025-49844(通称RediShell)は、Redisに13年間潜んでいたLua機能のUAF(解放済みメモリの誤使用)バグで、深刻度はCVSSで最悪値の10.0がついています。自分のサーバーでRedisを動かしている人は、6379番ポートがどこに公開されているか、認証なし(requirepass未設定)でアクセスできてしまわないかを、ssコマンドとredis-cliコマンドだけで自分の目で確認できます。この記事では、コピーして実行するだけの手順と、出力のどこを見れば「危険」と判断できるかを具体的に示します。

CVE-2025-49844(RediShell)で何が起こるのか

RedisにはLuaというスクリプト言語を実行する機能が組み込まれています。CVE-2025-49844は、このLua機能の内部処理に、解放したメモリ領域を後から誤って使ってしまう「解放済みメモリの誤使用(Use-After-Free)」というバグがあり、悪意のあるLuaスクリプトを送り込むことでLuaの実行制限(サンドボックス)を突破し、サーバー上で任意のコードを実行されてしまうというものです。2025年10月に公表され、影響範囲の広さと深刻度から大きく報道されました。

怖いのは「侵入されて初めて気づく」パターンではなく、外部から誰でも操作できる状態のRedisがそのまま公開されているケースが実際に多いことです。Redisは元々「信頼できる内部ネットワークだけからアクセスされる」前提で作られており、初期設定では通信の暗号化もパスワードも入っていません。踏み台にされているかどうかは、この記事の手順で今すぐ確認できます。

ss -tulpn で6379番ポートの公開範囲を確認する

ssは「今このマシンで、どのポートがどこに向けて開いているか」を見るコマンドです。sudoなしで実行できる読み取り専用の確認なので、まずはこれだけ試してください。

ss -tulpn | grep 6379

安全な例

tcp   LISTEN  0       511          127.0.0.1:6379        0.0.0.0:*     users:(("redis-server",pid=1234,fd=6))

Local Address(左から4列目)が127.0.0.1になっていれば、「このマシン自身からしかアクセスできない」状態です。外部のネットワークからは届きません。

危険な例

tcp   LISTEN  0       511          0.0.0.0:6379          0.0.0.0:*     users:(("redis-server",pid=1234,fd=6))

ここが0.0.0.0になっていたら、「マシンが持っている全てのネットワークインターフェースで待ち受けている」状態です。サーバーがグローバルIP(例:203.0.113.5のような、インターネット上のどこからでも到達できるアドレス)を持っている場合、世界中からアクセスできてしまいます。UFW(Ubuntu/Debian標準のファイアウォール)を有効にしていても、Dockerでコンテナ経由でポートを公開していると素通りするケースもあるので、UFWが有効=安全とは限りません。この点は以前書いたUFW有効でもDocker穴あり iptables点検2026年9月でも詳しく確認しています。

何も出力されなければRedisがそもそも起動していないか、Unixソケット経由(ネットワーク越しにはアクセスできない安全な方式)でしか動いていないということなので、この時点では問題ありません。

redis-cli で認証なしアクセスとバージョンを点検する

ポートが外に開いていても、パスワード(requirepass)が設定されていれば最悪の事態は防げます。実際に認証なしで操作できてしまわないかを、次のコマンドで確かめます。redis-cliが入っていない場合は事前にsudo apt install redis-tools(Ubuntu/Debian。CentOS/RHEL系はyum install redis)が必要です。

redis-cli -h 127.0.0.1 -p 6379 ping

安全な例(認証あり)

(error) NOAUTH Authentication required.

「認証が必要」と拒否されればrequirepassが機能しています。これが正常な状態です。

危険な例(認証なし)

PONG

パスワードを一切入力していないのにPONGが返ってきたら、誰でもコマンドを実行できる状態です。この状態だと、悪意のある人がデータを盗み見るだけでなく、Redisの設定変更機能を使ってサーバーに不正なファイルを書き込むなど、乗っ取りにつながる操作が可能になります。あわせてバージョンも確認してください。

redis-cli -h 127.0.0.1 -p 6379 INFO server | grep redis_version
redis_version:6.0.9

ここで表示された番号を、Redis公式サイトのセキュリティアドバイザリ(トップページから"Security"で検索できます)に掲載されている対象バージョン一覧と照らし合わせてください。バージョン番号だけでは自分で「安全/危険」を判断せず、公式の一覧で確認するのが確実です。古いバージョンほど対応が入っていない可能性が高い点は覚えておいてください。

危険と分かったときにやること(sudo必須・元に戻せる変更)

「0.0.0.0で公開」「認証なしでPONGが返る」のどちらか一方でも当たった場合は、次の順で対処します。いずれも設定ファイルを直接書き換えるためsudoが必要で、変更前にファイルをコピーしておけば元に戻せます。

sudo cp /etc/redis/redis.conf /etc/redis/redis.conf.bak_before_fix
  1. 外部からのアクセスを止める(bind制限): /etc/redis/redis.conf内のbind行をbind 127.0.0.1 -::1に変更。これで内部からしかアクセスできなくなります。
  2. パスワードを設定する(requirepass): 同ファイルのrequirepass行を有効にし、推測されにくい文字列を設定します。
  3. 設定を反映して再起動: sudo systemctl restart redis-server(Ubuntu/Debian。CentOS/RHEL系はサービス名がredisの場合があります)。
  4. 再度この記事のss/redis-cliの手順で確認: 127.0.0.1になっているか、NOAUTHが返るかを見直します。

元に戻したい場合はsudo cp /etc/redis/redis.conf.bak_before_fix /etc/redis/redis.conf && sudo systemctl restart redis-serverでバックアップから復元できます。本当にインターネット経由でRedisにアクセスする必要がある構成(複数サーバー間の連携など)の場合は、bindを外部に開けたままにせず、ファイアウォールで許可するIPを絞るか、VPN経由に限定する方法を検討してください。

点検を定期化する・関連する脆弱性対応も忘れずに

Debianは2026年9月12日に安定版13(trixie)のアップデート版13.7をリリースし、セキュリティ修正を取り込んでいます。CanonicalもAIによる脆弱性発見の増加を理由に、Ubuntuのカーネルセキュリティ更新サイクルを2026年9月24日から2週間ごとの統一サイクル(実質週次)に短縮すると発表しました。Redis単体の設定を直しても、OS側の更新を止めていれば別の穴が残ります。sudo apt update && sudo apt list --upgradableで更新の有無を定期的に確認する習慣もあわせて持っておいてください。

また、もし今回の点検で「認証なしでPONGが返った」状態が見つかった場合、既に外部から操作された形跡がないかも確認しておくと安心です。不正な自動実行が仕込まれていないかはcrontab点検で不正な自動実行ジョブを見つける2026年9月の手順で確認できます。

関連する選択肢

毎日決まった時刻にスクリプトを動かすだけなら、共有のレンタルサーバーでも足ります。cronが使えるプランを選べば、自分でOSを管理する必要はありません。

レンタルサーバー エックスサーバー

※ 広告を含みます（A8.net）。リンク経由でお申し込みがあった場合、手数料を受け取ることがあります。

まとめ

CVE-2025-49844(RediShell)はCVSS10.0という最高レベルの深刻度が付いた脆弱性ですが、自分のサーバーが危険な状態かどうかはss -tulpnで6379番ポートの公開範囲を、redis-cliで認証なしアクセスとバージョンを見るだけで、今すぐ自分で判断できます。0.0.0.0で公開されている、あるいはpingにPONGが返ってくる場合は、bind制限とrequirepass設定を行い、再起動後に必ず同じ手順で再確認してください。設定変更前にファイルをバックアップしておけば、必要なときはいつでも元の状態に戻せます。