Swati Khandelwal2026年7月24日脆弱性 / データベースセキュリティ

Redis は、研究者らが通常の Redis 6.2.22、7.4.9、8.6.4、8.8.0 向けの認証済み RCE PoC を公開したことを受け、7月23日に7件のセキュリティリリースを公開した。

4 つのチェーンはいずれも RESTORE を必要とする。Streams のチェーンは EVAL と XGROUP も必要で、8.8.0 のチェーンは EVAL と同梱の RedisBloom モジュールが必要となる。Redis は、基盤となるメモリ欠陥がリモートコード実行につながる可能性があると述べている。

Redis 6.2.23、7.2.15、7.4.10 は Streams の共有 NACK use-after-free を修正。Redis 8.2.8、8.4.5、8.6.5 は Streams の問題と RedisBloom および TDigest の境界外書き込みの両方を修正。Redis 8.8.1 は RedisBloom と TDigest のローダーを修正し、Streams のガードは Redis 8.8.0 ですでに存在していた。

PoC の対象のうち、Redis 6.2.22 と 7.4.9 は、Redis がユーザーにインストールを促した 5 月のセキュリティ更新版だったが、これらのリリースには共有 NACK の所有権ガードが含まれていなかった。

展開されているブランチ向けの修正版にアップグレードすること。それまでは、厳密に必要としないアカウントから RESTORE を取り消し、信頼できないネットワークアクセスを遮断する。RESTORE を制限することで、公開された両方の経路を遮断できる。

Cybersecurity

Redis の 7 月 23 日リリースノートおよびレビューした公開 PoC リポジトリのいずれも、2026 年 7 月 24 日時点で実環境での悪用は報告されていない。

RESTORE を介した 2 つの経路

Redis Streams の経路は共有所有権のバグである。破損した RDB オブジェクトにより、2 つのコンシューマーが同じ pending-entry レコードを指すことができ、両方のコンシューマーを削除すると同じオブジェクトが 2 回解放される。

公開されたスクリプトは、結果として生じるメモリ破壊を任意メモリアクセスに変換し、最終的に system() を呼び出すように設計されている。

RedisBloom の経路は、TDigest RDB ローダーにおける境界外書き込みである。このローダーはシリアライズされた値からメモリを割り当てたが、読み込むデータ量を決定する際に、別途攻撃者が制御可能な容量フィールドを信頼していた。

Redis 8.8.0 向けのスクリプトは、その不整合を読み書きプリミティブに変換し、Redis と libc のアドレスをリークして system() を呼び出すように設計されている。

Streams の共有 NACK チェーン

1 つ目の経路は Redis Streams にある。破損した RDB オブジェクトにより、2 つのコンシューマーが同じ pending-entry レコードを指すことができ、これは内部的に streamNACK で表される。最初のコンシューマーを削除するとオブジェクトが解放され、2 番目のコンシューマーがダングリングポインタを保持したままになる。その後、スクリプトは 2 番目のコンシューマーも削除する。1 つのチャンク、2 回の解放。

Redis 8.6.4 のリリースノートは PR #15081 を引用している。しかし The Hacker News によるソースレビューで、タグ付けされた 8.6.4 のソースにはその変更で追加された重複所有権チェックが欠けていることが判明した。このガードは 7 月 23 日にリリースされた Redis 8.6.5 に存在する。

公開された Redis 8.6.4 スクリプト は、ダブルフリーを任意メモリアクセスに変換し、データベースのハッシュ関数を汚染して細工された GET が system() を呼び出すように設計されている。ポインタを復元し、Redis がまだ応答するかどうかを確認する。

RedisBloom の TDigest チェーン

2 つ目の経路は RedisBloom の TDigest RDB ローダーにある。これは、シリアライズされた圧縮値からセントロイド配列を割り当てた後、読み込むノード数を決定する際に、別途攻撃者が制御可能な容量フィールドを信頼していた。小さな実際の割り当てと膨らんだメタデータを組み合わせることで、境界外書き込みが発生する。

Redis 8.8.0 スクリプト は、書き込みを読み書きプリミティブに変換し、Redis と libc のアドレスをリークして、データベースのハッシュ関数を汚染し、細工された GET が system() を呼び出すように設計されている。同様の根本原因と Redis 8.8.0 向けの認証済み RCE チェーンを示す 別の PoC が公開されている。

Cybersecurity

Redis の 7 月の修正 では、読み込まれた TDigest の容量が圧縮値から導出された割り当てと一致する必要がある。また、配列を読み込む前にマージ済みおよび未マージのノードカウンターに上限を設けている。

7 件のリリース、新たな CVE レコードなし

リポジトリは Streams の問題を CVE-2026-25589 の「不完全な修正ファミリー」の一部と呼んでいるが、Redis はこの CVE を Streams の共有 NACK 欠陥ではなく RESTORE 中の RedisBloom メモリ破壊にマッピングしている。Redis の 7 月リリースノートには、いずれの新バグクラスについても CVE や CVSS スコアの記載はない。

7 月 24 日時点で、The Hacker News の調査では、7 月の共有 NACK または TDigest の発見に関する別個の NVD レコードは見つからなかった。NVD には引き続き CVE-2026-25243 と CVE-2026-25589 の 5 月のレコードが掲載されている。CISA の Known Exploited Vulnerabilities カタログの検索でも、いずれの識別子もヒットしなかった。

この開示は、5 月に修正された AI 発見のもう 1 つの Redis RCE 欠陥に続くものである。Bera Buddies は自身を「AI Agent Research」と位置づけている。Chaofan Shou は X で、Kimi K3 エージェントが約 90 分で 19 件の Redis ゼロデイを発見したと述べ、別の実行では 27 分で Redis 8.8.0 のエクスプロイトを生成したと述べている。

これらの件数、所要時間、および主張される自律性の程度は自己申告のままとなっている。Redis の公開記録は欠陥と修正を確認しているが、主張されたゼロデイ数やエージェントがどの程度独立して動作したかは検証していない。

Redis 6.2.22 と 7.4.9 は 5 月の到達点だった。7 月には両方とも再度更新が必要になった。Redis が単に「最近パッチが適用された」かどうかではなく、正確なブランチバージョンを確認すること。

この記事が興味深かったら、Google News、Twitter、LinkedIn をフォローして、独占コンテンツをさらにご覧ください。