Redisに存在する重大なuse-after-free 脆弱性 CVE-2026-81934について、公開PoCの存在が確認され、TLSを有効化したRedis環境では早急な更新が必要です。
CVE-2026-81934は、RedisのtlsProcessPendingData()でTLSのpending-dataリストを処理する際に発生するuse-after-freeです。CVEレコードでは、リモートの未認証攻撃者がRedisサーバープロセスの権限で任意コマンドを実行できる可能性があると説明されています。
CVSS v4.0は9.2(Critical)、CVSS v3.1は9.8(Critical)です。Redisは2026年8月17日付のセキュリティリリースで複数のサポート系列に修正を反映しており、8.10.1、8.8.2、8.6.6、8.4.6、8.2.9、7.4.11、7.2.16、6.2.24などでTLS pending-data listのuse-after-free修正が確認できます。
また、CVEレコードとGitHub Advisory Databaseは公開PoCを参照しています。一方、2026年9月2日時点で実際の攻撃で悪用されたことを示す公式確認はなく、CISAのKnown Exploited Vulnerabilities(KEV)カタログへの掲載も確認できません。
CVE-2026-81934のサマリー
- CVE-2026-81934はRedisのTLS処理に存在するuse-after-free脆弱性です。
- 問題は
tlsProcessPendingData()が扱うTLS pending-dataリストで発生します。 - TLSサポートを有効にしてRedisを構成している環境が対象です。
- リモートの未認証攻撃者が任意コマンドを実行できる可能性があります。
- 実行権限はRedisサーバープロセスの権限です。
- CWEはCWE-416「Use After Free」です。
- CVSS v4.0は9.2(Critical)です。
- CVSS v3.1は9.8(Critical)です。
- Redisは2026年8月17日付の複数リリースで修正を公開しています。
- 修正版として8.10.1、8.8.2、8.6.6、8.4.6、8.2.9、7.4.11、7.2.16、6.2.24が確認できます。
- CVEレコードとGitHub Advisory Databaseは公開PoCを参照しています。
- PoCは特定ビルドを対象とした実証コードとして公開されており、利用可能な状態です。
- 2026年9月2日時点で実悪用は公式確認されていません。
- CISA KEVへの掲載も2026年9月2日時点では確認できません。
- Redisはサポート対象系列でも最新バージョンの利用を推奨しています。
| 項目 | 内容 |
|---|---|
| CVE | CVE-2026-81934 |
| 製品 | Redis |
| 脆弱性 | TLS pending-data listのuse-after-free |
| CWE | CWE-416 Use After Free |
| CVSS v4.0 | 9.2(Critical) |
| CVSS v3.1 | 9.8(Critical) |
| 攻撃経路 | ネットワーク |
| 認証 | 不要 |
| ユーザー操作 | 不要 |
| 主な条件 | RedisがTLSサポートを有効にして構成されていること |
| 影響 | Redisサーバープロセス権限で任意コマンド実行のおそれ |
| PoC | 公開済み |
| 実悪用 | 2026年9月2日時点で公式確認なし |
| CISA KEV | 2026年9月2日時点で掲載確認できず |
| 対応 | サポート系列の修正版へ更新 |
TLSのpending-dataリストでuse-after-free
CVE-2026-81934は、RedisがTLSを有効にして動作する場合に利用されるtlsProcessPendingData()の処理に存在します。
CVEレコードによると、この関数はTLS接続で保留中となったデータのリストを処理します。ここでメモリ解放後のオブジェクトを参照するuse-after-freeが発生する可能性があります。
CVEの説明では、リモートの未認証攻撃者がこの問題を悪用し、Redisサーバープロセスの権限で任意コマンドを実行できる可能性があるとされています。
このため、単なるサービス停止につながるメモリ破壊ではなく、リモートコード実行につながり得る脆弱性として扱う必要があります。
CVSS v4.0は9.2、v3.1では9.8
CVE-2026-81934には、CVSS v4.0で9.2、CVSS v3.1で9.8のCritical評価が付与されています。
CVSS v3.1のベクターは次のとおりです。
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
ネットワーク経由で攻撃可能で、攻撃難易度は低く、事前権限とユーザー操作はいずれも不要と評価されています。
一方、CVSS v4.0ではAttack RequirementsがPresentとなっています。CVEの説明上、RedisがTLSサポートを有効にして構成されていることが前提条件です。
したがって、Redisを利用しているだけで全環境が同じ条件で攻撃可能という意味ではなく、TLS構成の有無を確認する必要があります。
Redisは8月17日に複数系列へ修正を反映
Redisの公式リリースノートでは、2026年8月のセキュリティリリースで「コマンドが別のpending connectionを閉じる際にTLS pending-data listで発生するuse-after-free」が修正されています。
主な修正版は以下です。
| 系列 | 修正版 |
|---|---|
| Redis 8.10 | 8.10.1 |
| Redis 8.8 | 8.8.2 |
| Redis 8.6 | 8.6.6 |
| Redis 8.4 | 8.4.6 |
| Redis 8.2 | 8.2.9 |
| Redis 7.4 | 7.4.11 |
| Redis 7.2 | 7.2.16 |
| Redis 6.2 | 6.2.24 |
Redis 8.8.2や8.10.1の公式リリースノートでも、このTLS pending-data listのuse-after-freeがSecurity fixとして明記されています。
Redis 7.4.11についても同じ修正が公式リリースノートに含まれています。
RedisのSecurity Policyでは、8.10.x、8.8.x、8.6.x、8.4.x、8.2.x、7.4.x、7.2.x、6.2.xなどがサポート対象として示されており、最新版を利用することが推奨されています。
CVE公開は8月27日、修正自体はそれ以前に提供
CVE-2026-81934は2026年8月27日に公開されました。
一方、Redisの修正版は8月17日付のセキュリティリリースとして先に提供されています。
このため、8月17日の更新をすでに適用している組織では、CVE番号が後から付与された形になります。
脆弱性管理では、CVE公開日だけでなく、ベンダーが先行して公開したSecurity releaseの適用状況も確認する必要があります。
公開PoCをCVEレコードが参照
CVE-2026-81934のCVEレコードおよびGitHub Advisory Databaseには、公開PoCへの参照が含まれています。
CISA CoordinatorのSSVC情報でも、Exploitationは「poc」と評価されています。
公開PoCについてRedis 8.8.0の特定ビルドを対象とし、TLS経由でuse-after-freeを任意コード実行へつなげる実証コードだと思われますが
ただし、PoCが公開されたことと、実際のインターネット上の攻撃で悪用されていることは別です。
本記事では攻撃コードや具体的な悪用手順は掲載しません。
実悪用は現時点で確認されず
2026年9月2日時点で、Redis、CISA、CVEレコードなどの一次情報から、CVE-2026-81934が実際の攻撃で悪用されたとの公式確認は確認できませんでした。
また、CISAのKnown Exploited Vulnerabilities Catalogへの掲載も確認できません。
一方、公開PoCが存在し、認証不要でRCEにつながる可能性があるCritical脆弱性であるため、KEV掲載や実悪用確認を待ってから更新するのは適切ではありません。
特にインターネットから到達可能なRedisをTLS有効で運用している環境では、優先度を上げて対応する必要があります。
影響確認ではTLS構成と正確なバージョンを確認
運用担当者が最初に確認すべきなのは、RedisのバージョンとTLS構成です。
RedisをTLS非対応でビルド・構成している場合は、この脆弱性の説明にあるTLS pending-data処理は利用されません。
TLSを利用している場合は、利用している系列で8月17日以降の修正版が適用されているか確認する必要があります。
コンテナやLinuxディストリビューションが提供するRedisパッケージを利用している場合は、Redis upstreamのバージョン番号だけでなく、ディストリビューション側でバックポート修正が行われている可能性もあるため、各ベンダーのセキュリティアドバイザリも確認する必要があります。
Redis 8.0系など非サポート系列にも注意
RedisのSecurity Policyでは、8.0.xはサポート対象外とされています。
また、7.2より古い系列についても多くがサポート対象外です。
今回のCVEについて、サポートされていない全系列の影響範囲やバックポート可否が公式に網羅されているわけではありません。
そのため、非サポート系列を利用している組織は、「CVEの影響対象として明記されていないから安全」と判断するのではなく、サポート中の系列へ移行することを優先すべきです。
Redisが侵害された場合の影響
Redisはキャッシュだけでなく、セッション管理、キュー、リアルタイムデータ処理、認証関連データ、アプリケーション状態の保存などに利用されます。
CVE-2026-81934が悪用され、Redisサーバープロセス権限で任意コードを実行された場合、Redis内部のデータだけでなく、ホスト上でRedisユーザーがアクセス可能なファイルや設定、接続先情報などへ影響が広がる可能性があります。
ただし、Redisサーバープロセスの権限とOSのroot権限は同じではありません。
Redisを非特権ユーザーで実行し、コンテナやOSレベルで権限を制限している環境では、侵害後の影響を限定できる可能性があります。
情報システム・インフラ担当への示唆
CVE-2026-81934への対応では、まずRedisのバージョンとTLS有効化状況を棚卸しし、修正版へ更新することが最優先です。
特に、インターネットや信頼境界の外側からRedisへ到達可能な構成は確認が必要です。
Redisは本来、アプリケーション内部のデータストアとして利用されるケースが多く、外部へ直接公開する必要がない環境では、ファイアウォール、セキュリティグループ、Kubernetes NetworkPolicyなどで到達元を限定することが重要です。
また、更新前に外部公開されていたTLS対応Redisでは、次のような観点で侵害有無を確認する必要があります。
- 通常と異なるRedis接続元
- 不審なコマンド実行
- Redisプロセスからの不審な子プロセス生成
- 通常利用しない外部通信
- 設定ファイルや永続化データの不審な変更
- ホスト上の不審なファイル生成
- Redis実行ユーザー権限での不審な操作
なお、Redis公式はCVE-2026-81934固有のIOCを公表していません。
公開PoCが存在する現在は、パッチ適用だけでなく、パッチ適用前にインターネットから到達可能だった環境についてログやEDRを使った侵害確認も検討すべきです。
出典
- Redis Open Source 8.10 release notes – Redis
- Redis Open Source 8.8 release notes – Redis
- Redis Open Source 8.2 release notes – Redis
- Redis Community Edition 7.4 release notes – Redis
- Security Policy – Redis GitHub
- CVE-2026-81934 – GitHub Advisory Database
- CVE-2026-81934 – CVE Program
- Known Exploited Vulnerabilities Catalog – CISA








