Copy Fail脆弱性にCloudflareがどう立ち向かったか
2026年4月29日、Linuxカーネルにローカル権限昇格をもたらす脆弱性「Copy Fail（CVE-2026-31431）」が公開された。この脆弱性を悪用すれば攻撃者はroot権限を取得でき、多くのサーバが影響を受け得る深刻なものだ。
Cloudflareは世界中の330都市に展開する大規模なLinuxサーバ基盤を運用している。同社は開示直後からセキュリティチームとエンジニアリングチームが動き、既存の振る舞い検知が数分で攻撃パターンを特定できることを確認し、また再起動不要の緩和策としてeBPF LSMを展開した。結果として顧客データへの影響やサービス停止は一切発生していない。
Copy Fail脆弱性（CVE-2026-31431）の全容
Linuxカーネルのcrypto APIには、AF_ALGソケットファミリ経由で一般ユーザプロセスが暗号化・復号を要求できる仕組みがある。ここで問題となったのは「aead」テンプレートを用いるモジュール `algif_aead` の欠陥だ。2017年に導入されたin-place最適化によって、復号時に割り当てられた出力領域を超えた4バイトの書き込みが発生するようになっていた。
攻撃者はまず `splice()` システムコールを使い、`/usr/bin/su` のようなsetuidバイナリのファイル記述子からページキャッシュの参照を暗号化操作のscatterlistにチェインさせる。その状態で `recvmsg()` を呼ぶと、本来許される範囲外の4バイトがターゲットのページキャッシュに書き込まれる。汚染されたバイナリを `execve()` で実行すれば、root権限で任意のコードが動くという筋書きだ。
socket(AF_ALG, SOCK_SEQPACKET, 0) でAEADテンプレートにバインド
setuidバイナリ（例:/usr/bin/su）のファイル記述子からページキャッシュを暗号scatterlistにチェイン
復号処理中に4バイトのスクラッチデータがターゲットページキャッシュへ書き込まれる
ページキャッシュが汚染された状態でsetuid-rootプログラムを実行し、シェルコードがrootとして動作
このエクスプロイトの流れは、Cloudflareのブログで詳述された技術情報と、Xint Codeによる元の開示記事を基にしている。Linuxコミュニティはコミット a664bf3d603d で2017年の最適化を差し戻しており、それが正式な修正となる。
CloudflareのLinuxカーネル管理プロセス
CloudflareはカスタムLinuxカーネルを自前でビルドし、コミュニティの長期サポート（LTS）バージョンをベースにしている。新型カーネルの選定からグローバル展開まで、およそ4週間のサイクルでシステム的なアップデートと再起動を実施している。公開前に既知のセキュリティパッチがマージされるのが常だが、Copy Failの修正はメインラインにマージされてから1ヶ月経っても主要LTSラインへのバックポートが完了していなかった。このタイムラグが生じたため、Cloudflareの大部分のサーバは6.12 LTSカーネルを稼働させており、脆弱性が残る状態だった。
Cloudflareの多層防御：検知から再起動不要の緩和まで
振る舞いベースの検出が数分で作動
Cloudflareのエンドポイントには、プロセスの振る舞いを常時監視する検知プラットフォームが導入されている。特定の脆弱性シグネチャに頼るのではなく、通常とは異なる実行パターンを検出する仕組みだ。専用ルールの更新や人の介入なしに、社内で実施した検証でエクスプロイトの試行が数分以内に悪性と判定され、アラートが発報された。これは攻撃チェーン全体（スクリプトインタプリタ → AF_ALG経由の暗号サブシステム呼び出し → 権限昇格バイナリの実行）を一つの振る舞いパターンとして捉えた結果だ。
脅威ハンティングと過去48時間のログ調査
セキュリティチームは「公開前から悪用されていた可能性を前提にする」という原則に立ち、エクスプロイトが残すカーネルログの痕跡を独自の集約ログ基盤で検索した。また、関係するシステムへの全アクセスログを収集し、接続元や実行コマンドを再構成、システムバイナリのハッシュ整合性を検証した。その結果、過去48時間においてCloudflareのインフラ上で悪用された証拠は一切確認されなかった。
eBPF LSMによる緊急緩和の展開
根本対策であるパッチ済みカーネルのロールアウトには時間がかかるため、チームは無効化モジュール `algif_aead` の削除をまず試みた。しかし実際にはレガシーな社内サービスがcrypto APIを利用しており、削除すると障害を招くことがステージング環境のテストで判明した。そこで再起動不要の外科的対策として、BPF Linux Security Module（bpf-lsm）を使ったプログラムを導入した。
# 素朴な緩和（モジュール無効化）は依存関係のため断念
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true
bpf-lsmプログラムは `socket_bind` LSMフックにアタッチし、AF_ALGソケットを開こうとするバイナリのパスをホワイトリストと照合する。許可リストにないバイナリからの `bind()` 呼び出しは拒否するため、悪用の入口を完全に封鎖する。このアプローチを採る前に、Prometheus eBPF Exporterを使って艦隊全体のAF_ALG利用実態を可視化し、許可リストに載せるべき正当なサービスが本当に1つだけであることを検証した。
# eBPF LSMプログラムの擬似フロー
- ソケットファミリがAF_ALGでなければ通過
- AF_ALGの場合、呼び出し元バイナリのパスを許可リストと照合
- 許可されていればbindを許可、それ以外は拒否
これにより、大部分のサーバはパッチ済みカーネルが配布されるまでの間、bpf-lsmによって保護された。テスト用ノードで実際にエクスプロイトコードを実行し、PermissionError が返され攻撃が不可能になったことを確認している。
攻撃者のbind()成功 → recvmsg()で範囲外書き込み → root取得
非許可バイナリからのAF_ALG bindを拒否 → PermissionError → 攻撃失敗
一連の対応から得た教訓と今後の改善
Cloudflareは今回の対応を通じていくつかの改善点を特定した。まず、カーネルAPIの依存関係をより深く可視化し、将来の緊急緩和時にサービス停止を避けられるようにすること。次にbpf-lsm自体の展開速度やログの充実を図り、ランタイム防御の即応性を高めること。さらに、カーネルコンフィギュレーションの監査を進め、使われていないモジュールや機能を事前にビルドから除去することで攻撃対象領域を縮小していく方針だ。
今回のインシデントで、Cloudflareは顧客影響ゼロを達成した。パッチ済みカーネルのリリースとbpf-lsmによるレイヤーが艦隊全体に行き渡り、脆弱性が悪用される余地は残らなかった。Linuxコミュニティの責任ある開示、社内の可視化ツール、そしてbpf-lsmというプリミティブが、迅速な防御を可能にしたといえる。
この記事のポイント
- Linuxカーネルの脆弱性「Copy Fail」はローカルからroot権限を奪取できる深刻な問題
- Cloudflareは公開と同時に既存の振る舞い検知で即座に捕捉し、過去ログの脅威ハンティングで未然悪用がないことを確認
- 再起動不要の緩和策としてeBPF LSMを導入し、AF_ALGソケットへの不正アクセスをホワイトリスト方式で遮断
- 根本パッチのロールアウトと並行して運用し、結果的に顧客データやサービスへの影響は皆無
- 可視化ツール（Prometheus eBPF Exporter）の事前整備が緩和策の意思決定を支えた
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AWS MCP Serverが一般提供開始、AIエージェントのAWS操作を安全・効率的に
AWSは2026年5月6日、AIエージェント向けのマネージドサービス「AWS MCP Server」の一般提供を開始した。AIコーディングアシスタントがAWSの各種サービスを安全に呼び出し、最新ドキュメントを参照し、必要ならサンドボックス内でスクリプトを実行できるようになる。
これまではAIエージェントがAWSを操作しようとしても、訓練データが古く、IAMポリシーが過剰になりがちだった。本サーバーはそうした課題を解決し、本番環境でも使えるレベルのインフラコード生成を後押しする。
本記事ではAWS MCP Serverの機能、GAで追加された新要素、具体的な利用手順、対応ツール、料金までを詳しく解説する。
AWS MCP Serverの概要
MCP（Model Context Protocol）は、AIエージェントが外部サービスやツールと安全にやり取りするための標準プロトコルだ。AWS MCP Serverはこのプロトコルに準拠したマネージド型のリモートサーバーであり、数個の固定ツールを通じて1万5000を超えるAWS APIへのアクセスを提供する。
AIコーディングアシスタントは多くの場合、訓練データに依存するため、2025年後半以降に登場した新サービス（Amazon S3 VectorsやAurora DSQLなど）を知らない。また、インフラ構築時にAWS CLIを好み、AWS CDKやCloudFormationといったIaCツールを使わない傾向があった。生成されるIAMポリシーも権限が広すぎるなど、デモ用には動いても本番投入は難しい状態だった。
この仕組みにより、AIエージェントは常に最新の情報と最小権限でAWSリソースを操作できる。ツールの数が少なく固定されているため、モデルのコンテキストウィンドウを圧迫せず、ハルシネーション（誤った回答の生成）も抑えられる。
GAで追加された主な機能
プレビュー期間を経て正式提供となったAWS MCP Serverでは、以下の機能が新たに導入されている。
IAMコンテキストキーのサポート
従来はMCPサーバー自体の利用に専用のIAM権限が必要だったが、今回からIAMコンテキストキーに対応した。これにより、通常のIAMポリシーの中で「特定のユーザーは更新系APIを許可、MCPサーバー経由では読み取り専用」といったきめ細かい制御が可能になる。余分な権限管理の手間が減り、セキュリティ設計がシンプルになる。
ドキュメント検索の認証不要化
search_documentationおよびread_documentationツールが、認証なしでも利用できるようになった。これにより、まだAWSアカウントを持っていない段階でも、AIエージェントは最新のAWSドキュメントを参照して設計や調査を行える。
トークン消費の最適化
インタラクションあたりのトークン消費量が削減された。マルチステップのワークフローを伴う複雑なタスクでは、モデルのコンテキストウィンドウがすぐに埋まりがちだったが、今回の改善でより長い会話を維持しやすくなっている。
run_scriptツールとサンドボックス実行
GAの大きな目玉がrun_scriptツールの追加だ。AIエージェントは短いPythonスクリプトを記述し、MCPサーバー側のサンドボックス環境で実行させることができる。このサンドボックスは呼び出し元のIAM権限を継承するが、ネットワークアクセスは一切持たない。つまり、エージェントはAWSリソースのデータを処理できるものの、ローカルのファイルシステムやシェルには触れない。
…
# 複数APIを組み合わせた処理を1回のラウンドトリップで
従来、エージェントが複数のAPIを呼び出してデータを結合する場合、1つずつリクエストを送っては応答を待つ必要があり、時間もトークンも浪費していた。run_scriptを使えば、1回のラウンドトリップで一連の処理を完結させられる。これにより、処理速度とコンテキスト効率の両方が大幅に向上する。
Skillsによるベストプラクティスの提供
プレビュー版では「Agent SOPs」という形式でガイダンスが提供されていたが、GAではより洗練された「Skills」に移行した。Skillsは、エージェントがよく間違えるタスクに対して、AWSの各サービスチームがメンテナンスする検証済みのベストプラクティスを提供する。
スキルにより生成されるコードの品質が安定し、エラーやトークンの無駄も減る。ツール一覧を短く保ちつつ、必要なガイダンスをピンポイントで渡せるため、エージェントの挙動が予測しやすくなり、無駄な試行錯誤も抑制される。
エンタープライズの現場では、開発者の数だけ書き方がバラバラになりがちだが、Skillsによってサービスチーム公認のパターンがチーム全体に自然と浸透する。結果として、セキュリティレビューの工数も削減できるだろう。
セキュリティと監査の仕組み
AWS MCP Serverは、ユーザーが直接操作する時とAIエージェント経由の操作を明確に区別できる設計になっている。IAMポリシーやSCP（Service Control Policies）を使って、特定のユーザーには全操作を許可しつつ、MCPサーバーには読み取り専用のみ許可する、といった制御が可能だ。
さらに、AWS-MCP名前空間のAmazon CloudWatchメトリクスが提供され、MCPサーバー経由のAPIコールと人間による直接のAPIコールを分離して監視できる。AWS CloudTrailもすべてのAPI呼び出しを記録するため、コンプライアンスチームが求める監査証跡を完全な形で確保できる。
このように、AIエージェントが安全にインフラを操作できる環境が整ったことで、これまで人間の開発者しか触れなかった本番環境へのAI活用も現実味を帯びてきた。
利用方法と対応ツール
AWS MCP Serverは、MCPに対応するあらゆるAIコーディングツールから利用できる。Claude Code、Cursor、Kiro、OpenAI Codexなど、主要なアシスタントはすでにサポートしている。
セットアップは非常にシンプルだ。AWS MCP ServerはIAM SigV4認証を利用するが、多くのMCPクライアントはOAuth 2.1のみに対応している。そのため、オープンソースの「MCP Proxy for AWS」を使ってIAM認証をOAuthにブリッジする。具体的には以下のようなコマンドで設定する。
curl -LsSf https://astral.sh/uv/install.sh | sh
claude mcp add-json aws-mcp --scope user \
'{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"]}'
/mcpコマンドを実行すると、AWS MCP Serverが利用可能なツール一覧が表示される。search_documentationツールを呼び出し、最新のS3 Vectorsの情報をもとに回答を生成する。プロキシはローカルマシン上で動作し、MCPサーバーのエンドポイントとしてhttps://aws-mcp.us-east-1.api.aws/mcp（米国東部）または欧州（フランクフルト）のリージョナルエンドポイントを指定する。APIコール自体は他の全リージョンに対しても実行可能だ。
料金と提供リージョン
AWS MCP Server自体に追加料金は発生しない。支払うのは、AIエージェントが操作した結果として作成されたAWSリソースの利用料と、データ転送料金のみだ。このため、まずは試験的に導入し、効果を検証しやすい。
現在の提供リージョンは米国東部（バージニア北部）と欧州（フランクフルト）の2拠点。今後、他のリージョンにも順次拡大される見込みだ。
AWS MCP Serverはすでに多くのAIコーディングアシスタントで利用可能であり、AWSドキュメントの最新ページからクイックスタートガイドを参照できる。
この記事のポイント
- AWSがAIエージェント向けのマネージドMCPサーバーを一般提供開始
- call_aws、search_documentation、run_scriptの3ツールでAWSを安全に操作
- run_scriptはサーバー側サンドボックスでスクリプトを一括実行し高速化
- SkillsによりAWSチーム公認のベストプラクティスをコード生成に活用可能
- IAMとCloudTrail/CloudWatchで人間の操作とAIの操作を明確に分離監査
- サーバー利用料は無料、リソース使用量のみの課金。米国東部と欧州で提供開始
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
de TLD障害の全容 DNSSEC署名破損でSERVFAIL多発 Cloudflareの一時的緩和策を解説
2026年5月5日、およそ19時30分（UTC）、ドイツの国別コードトップレベルドメインである .de を管理するレジストリ DENIC が、同ゾーンのDNSSEC署名を誤って公開し始めた。この誤った署名は、DNSSEC検証を行うすべてのDNSリゾルバにSERVFAILを返させる結果となり、Cloudflareの公開リゾルバ1.1.1.1も例外ではなかった。
.de はインターネット上で最もクエリ数の多いTLDのひとつで、Cloudflare Radarのデータでも常に上位にランクインする。このレベルのDNS階層で障害が発生すると、数百万のドメインが到達不能になる可能性がある。本記事では、Cloudflareが観測した現象、影響の範囲、さらにDENICが問題を解決するまでの間に1.1.1.1が適用した一時的緩和策について解説する。
.de TLD障害の原因と発覚の経緯
DNSSEC署名が破損したことで、リゾルバは応答を信用せずSERVFAILを返す。この仕組みは正しいが、大規模な影響を引き起こした。19時30分の直後からSERVFAILが急増し、キャッシュの期限切れに伴って3時間にわたって増え続けた。クエリのリトライにより通信量も増大し、SERVFAILの件数は実際のユーザー影響以上に見える。
DENICは後の声明で「定例の鍵ローテーション中に、検証できない署名が生成・配布された」と説明しており、今後のローテーションは原因特定まで停止されている。
DNSSECの仕組みと署名検証の役割
DSレコード
検証失敗
DNSSEC（Domain Name System Security Extensions）は、DNS応答にデジタル署名を付与して改ざんを防ぐ仕組みだ。各ゾーンのレコードセットにはRRSIGレコードが付随し、リゾルバはこれを用いて原本性を確認する。署名は保護対象のレコードと一緒に運ばれるため、キャッシュを経由しても検証可能だ。
信頼の連鎖はルートゾーンから始まり、親ゾーンがDSレコードで子ゾーンの公開鍵を証明する。.deの上位にはルートがあり、.deの下に個々のドメインがぶらさがる。どこか一か所で署名が破綻すると、その先の全ドメインが検証に失敗する。今回のようにTLDで署名ミスが起きれば、配下のすべての .de ドメインがSERVFAILになる。
DNSSECでは、ゾーン署名鍵（ZSK）と鍵署名鍵（KSK）を使い分ける。ZSKはレコードそのものに署名し、KSKはZSKに署名する。KSKの公開鍵が親ゾーンのDSレコードと結びつき、信頼の基点となる。鍵のローテーション時に新しい鍵が正しく配布されなかったり、署名生成に失敗すると、今回のような大規模障害につながる。
キャッシュとserve staleが被害を軽減
クエリ → キャッシュから応答（NOERROR）
DENICへ問い合わせ → SERVFAIL
キャッシュ期限切れでも古いデータを返し続ける
リゾルバはTTL（生存時間）の間、権威サーバーから受け取ったレコードをキャッシュする。TTLが切れると、新しい情報を取りに行く。ところが障害発生中は、新たに取得しようとするとSERVFAILに終わる。そこでCloudflareの1.1.1.1はRFC 8767に従い、キャッシュの期限が切れた後も古いレコードを応答し続ける「serve stale」を実施した。
このおかげで、キャッシュに残っていた .de ドメインの多くは引き続き解決され、ユーザーへの影響は大幅に和らげられた。グラフからも、incident中にNOERRORが一定数維持されたことが分かる。serve staleがなければ、故障が始まった瞬間から全クエリが失敗していた。
Cloudflare 1.1.1.1が講じた一時的緩和策
serve staleだけではカバーできないクエリもあったため、Cloudflareは22時17分（UTC）に .de ゾーンに対して一時的なNTA（Negative Trust Anchor）に相当する措置を適用した。具体的には、内部のオーバーライドルールを使って .de 全体を「DNSSEC未対応ゾーン」のように扱い、署名検証をスキップさせた。
RFC 7646はまさにこうした状況のためにNTAを定義している。TLD運営者が破損した署名を公開した場合、正しいドメインまで巻き添えでSERVFAILになるより、一時的に検証を外す方がユーザーにとって有益だという判断だ。Cloudflareの内部議論でも「1.1.1.1を使っているユーザーで、検証失敗よりも未検証の応答の方を望まない者はいない」と結論づけられている。
同時に、CDNサービスを利用する顧客向けの内部リゾルバにも同様の対応を施し、 .de をオリジンとするサイトの接続性を回復させた。また、対策を即座にDNS-OARCのチャットで共有し、他の事業者との連携も行った。
なお、1.1.1.1が返していたSERVFAILにはEDEコード22（到達可能な権威サーバーなし）が付与されていたが、本来はEDE 6（DNSSEC無効）が適切だ。Cloudflareはこのバグを認識しており、今後DNSSECエラーを正しく表面化させる修正を予定している。
インシデントから学ぶ教訓と今後の改善点
この障害は、DNSの階層構造がもつ脆弱性を改めて浮き彫りにした。TLDレベルで発生した問題は、その下にあるすべてのドメインに等しく波及する。これはDNSSECに限った話ではなく、権威サーバー自体が到達不能になれば同じことが起こる。
根本的な回避策は存在しないが、迅速な連携と運用上の工夫で被害を抑えられる。今回、多くのリゾルバ事業者が1時間以内にNTAを適用し、解決までの間ユーザーの影響を緩和した。DNS-OARCのような業界コミュニティの存在も、こうした危機対応のスピードを支えている。
技術面では、serve staleのような仕組みがTier-1レベルの障害時に有効に機能することが改めて示された。また、EDEエラーコードの適切な実装は、トラブルシューティングを容易にし、運用者間の情報共有を効率化する。Cloudflareもこの点の改善に着手する。
この記事のポイント
- 2026年5月5日、.de TLDのDNSSEC鍵ローテーション中に不正な署名が生じ、全DNSSEC検証リゾルバがSERVFAILを返した
- DNSの階層構造上、TLDの障害は配下のドメインすべてに影響する
- Cloudflareの1.1.1.1はserve staleでキャッシュを延命し、さらに一時的にDNSSEC検証を無効化するNTA相当の対策を22時17分に適用
- RFC 7646に定義されたNTAは、事業者間の迅速な合意形成があれば被害を大幅に軽減できる
- EDEエラーコードの不備など、リゾルバ側の改善点も事例から明らかになった
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Next.js 2026年5月セキュリティリリースの全容、13件の脆弱性を修正
Next.jsの開発元であるVercelは2026年5月7日、調整済みセキュリティリリースを公開した。React Server Componentsの上流脆弱性（CVE-2026-23870）への対応を含む、合計13件の脆弱性が修正されている。フレームワークを利用するすべての開発者にとって、即時のアップデートが強く推奨される内容だ。
今回のリリースで対処された問題は、サービス拒否（DoS）攻撃、ミドルウェアやプロキシのバイパス、サーバーサイドリクエストフォージェリ（SSRF）、キャッシュポイズニング、クロスサイトスクリプティング（XSS）と多岐にわたる。ただちにパッチを適用しなければ、本番環境が深刻な攻撃に晒されるリスクがある。
アップデートの概要と影響範囲
今回のセキュリティリリースはNext.js本体に加え、その根幹をなすReactの特定パッケージにも修正が及ぶ。Vercelの発表によれば、13件の脆弱性アドバイザリが一挙に解決された形だ。アドバイザリの内訳を見ると、攻撃の種類によって影響を受ける機能や設定が明確に分かれている。自社のプロジェクトがどのカテゴリに該当するかを把握することが、迅速な対応への第一歩となる。
● React Server Components の DoS
● キャッシュポイズニング
● SSRF の潜在的リスク
● DoS 攻撃から保護
● キャッシュへの不正注入を防止
● SSRF の脆弱性を遮断
13件の脆弱性が存在する「Before」の状態と、アップデートによってそれらがすべて解決された「After」の状態を比較したイメージだ。リリースによってセキュリティ上のリスクが一掃されることがわかる。
修正対象となったReactとNext.jsのバージョン
影響を受けるバージョンを把握し、修正済みの安全なバージョンへ移行する必要がある。今回のリリースで修正が提供されたバージョンは以下の通りだ。
まず、React本体については、19.0.6、19.1.7、19.2.6の3つのパッチがリリースされた。これらのバージョンでは、サーバーコンポーネントの通信用パッケージである react-server-dom-parcel、react-server-dom-webpack、react-server-dom-turbopack の各パッケージに修正が含まれている。
Next.jsをフレームワークとして利用している場合、これらのReactパッケージはNext.jsのバージョンにバンドルされている。そのため、開発者はNext.js本体を最新のパッチバージョンに更新することで、React側の修正も同時に適用できる。個別にReactパッケージを管理しているプロジェクトは、それらも忘れずにアップデートする必要がある。
各脆弱性の詳細とリスク評価
ここからは、発表されたアドバイザリを深刻度別に整理し、その技術的な背景をひも解いていく。影響を受けるコンポーネントと、攻撃が成立するシナリオを正しく理解することが、開発者としての適切なリスク評価に繋がる。
ミドルウェアとプロキシのバイパス
認証や認可のロジックを middleware.js や proxy.js に依存しているアプリケーションが、致命的な影響を受ける可能性がある。2件の「高」深刻度アドバイザリがこれに該当する。
1件目はApp Routerにおける segment-prefetch のバイパスで、過去の修正が不完全だったための再発フォローアップだ。2件目はPages Routerのi18n機能において、デフォルトロケールのパスがプロキシ認証を迂回してしまう問題である。多言語サイトをPages Routerで運用しており、middlewareでアクセス制御を行っている環境は特に注意が必要だ。
サービス拒否（DoS）攻撃
サーバーのリソースを枯渇させ、正規のユーザーがサイトにアクセスできなくなるDoS攻撃に関する脆弱性が3件報告されている。これらはすべて、Server Functions、Partial Prerendering（PPR）のCache Components、もしくは画像最適化APIの利用が条件となる。
最もクリティカルなものは、React Server Componentsの上流脆弱性（CVE-2026-23870）を突いた攻撃だ。Vercelの発表によると、この脆弱性によりリモートからのDoS攻撃が成立する。また、Cache Componentsを使用するアプリケーションにおける「接続数の枯渇」を引き起こす脆弱性も「高」深刻度と評価されている。画像最適化APIを経由したDoSは「中」深刻度だが、無視できるものではない。
この図は、悪意あるリクエストによってサーバーのリソースが消費され、本来のサービス提供が妨害されるDoS攻撃の基本的な流れを示している。Cache Componentsの脆弱性は、この「リソース枯渇」の段階を特に加速させる危険性がある。
サーバーサイドリクエストフォージェリ（SSRF）
SSRFは、攻撃者がサーバーを踏み台にして内部ネットワークへのリクエストを強制させる攻撃手法だ。今回の脆弱性は、WebSocketへのアップグレードリクエストを処理するアプリケーションが影響を受ける。
この種の攻撃が成功すると、攻撃者は本来アクセスできない内部のメタデータサービスやデータベースと通信できるようになる。クラウド環境（AWSやGCPなど）で稼働しているNext.jsアプリケーションは、特に深刻な被害に繋がる可能性があるため、迅速な対応が求められる。
キャッシュポイズニングとクロスサイトスクリプティング（XSS）
React Server Componentのレスポンスの前にキャッシュ層を配置しているアプリケーションは、キャッシュポイズニングのリスクに晒される。これは、攻撃者が悪意あるレスポンスをキャッシュサーバーに記憶させ、他のユーザーにその不正なコンテンツを配信させる攻撃だ。
XSSに関しては、App RouterでCSP（コンテンツセキュリティポリシー）のnonceを利用しているケース、そして外部からの信頼できない入力を消費する beforeInteractive スクリプトが影響を受ける。これらの設定は比較的高度なカスタマイズで使われるが、該当する場合はすぐに対処しなければ攻撃者によるスクリプト実行を許してしまう。
即時アップデートの必要性と対応手順
Vercelは今回のリリースに際し、新たなWAF（Web Application Firewall）ルールを展開していないと明言している。つまり、これらの脆弱性はWAFレベルで確実にブロックすることができず、パッチ適用が唯一の完全な緩和策となる。
アップデート手順の基本
まず、プロジェクトのNext.jsとReactのバージョンを確認する。package.jsonに記載されているバージョンが、今回の修正対象より古い場合は即座にアップデートを実行する。一般的な手順は以下の通りだ。
# Next.jsのアップデート
npm install next@latest
# 関連するReactパッケージも最新に
npm install react@latest react-dom@latestyarnやpnpmなど、他のパッケージマネージャーを利用している場合も、同等のコマンドで問題ない。パッケージを更新した後は、必ずビルドとテストを実行し、アプリケーションが正常に動作することを確認してほしい。
本番環境でのリスク管理
今回のセキュリティリリースには、破壊的な変更は含まれていない。そのため、動作検証は必要だが、適用を躊躇する技術的理由はほぼない。重要なのは「スピード」だ。
とりわけ、middlewareで認証を実装しているサイト、WebSocketを処理するリアルタイムアプリケーション、そしてPPRやCache Componentsを採用しているパフォーマンス重視のサイトは、緊急度が極めて高い。Vercelの発表でも「all affected users should upgrade immediately（影響を受けるすべてのユーザーは直ちにアップグレードすべき）」と強い表現で呼びかけている。
今回のリリースが示すNext.jsセキュリティの潮流
一見すると大規模な脆弱性の一括修正はネガティブな出来事に思える。しかし、セキュリティの観点からは、むしろフレームワークの成熟度を示すポジティブなシグナルと捉えるべきだ。
まず、対策が「調整済みセキュリティリリース」として計画的に実施されている点が重要だ。これは、VercelとMeta（React）のチームが発見された問題を共有し、エコシステム全体で同時に対処する体制が整っていることを意味する。大規模なOSSプロジェクトでは、このような「調整済み開示」のプロセスがセキュリティ品質の生命線となる。
次に、脆弱性の範囲が「Server Components」「ミドルウェア」「エッジキャッシュ」「画像最適化API」といった、Next.jsの比較的新しい機能や高度な機能に集中している事実に注目したい。これは、攻撃者の標的が、従来のシンプルなWebアプリケーションから、エッジとサーバーを高度に組み合わせたモダンなアーキテクチャへとシフトしている証左だ。
SSRやエッジファンクションの利用が一般化するにつれ、開発者は「新しい機能がもたらす利便性」と「新たな攻撃表面が生まれるリスク」のバランスを常に意識する必要がある。便利なAPIほど、その裏側で何が起きているのかを深く理解することが、これからのフロントエンド開発者には不可欠だ。
この記事のポイント
- Next.js 2026年5月セキュリティリリースは、ReactのCVE-2026-23870を含む13件の脆弱性を修正する
- 影響範囲はDoS、ミドルウェアバイパス、SSRF、キャッシュポイズニング、XSSと多岐にわたる
- WAFでは防げない脆弱性群のため、Next.jsとReact関連パッケージの即時アップデートが唯一の対策
- とくに認証機能やServer Components系の新機能を使うプロジェクトは緊急度が高い
- 調整済みリリースの実施は、Next.jsエコシステムのセキュリティ成熟度を示すポジティブな側面でもある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Azure Integrated HSM がオープンソース化、FIPS 140-3 Level 3 準拠のハードウェアセキュリティを全サーバーに統合
Microsoft は2026年4月30日、全 Azure サーバーに統合されるハードウェアセキュリティモジュール「Azure Integrated HSM」をオープンソース化する計画を発表した。このモジュールは改ざん耐性を備え、FIPS 140-3 Level 3 に準拠する。クラウド上の暗号鍵を、ソフトウェアやネットワーク層ではなくハードウェアチップ内で保護する設計だ。
Azure Integrated HSM は、従来の集中型 HSM サービスとは異なり、各サーバーに直接組み込まれる。鍵の生成から利用までをサーバー内の専用チップに閉じ込め、メモリ上やネットワーク越しの鍵窃取を原理的に不可能にする。本記事では、この仕組みとオープンソース化の意義、そして鍵管理の新しいアプローチを解説する。
Azure Integrated HSM がもたらすサーバーローカルの保護
HSM（Hardware Security Module）は、暗号鍵を安全に生成・保管するための専用ハードウェアだ。耐タンパー性を持ち、物理的な分解や不正アクセスを検知すると鍵を自動消去する仕組みを備える。Azure Integrated HSM はこの HSM を Azure サーバーのマザーボード上に統合し、すべての新規サーバーに標準搭載する。
本モジュールが準拠する FIPS 140-3 Level 3 は、政府や金融など規制産業で要求される最高水準のセキュリティ認証だ。Level 3 では、強固な改ざん抵抗性、ハードウェアによる隔離、物理的・論理的な鍵抽出の防止が求められる。この基準をクラウドインフラのデフォルトとして実装する点が、今回の取り組みの大きな特徴といえる。
従来の集中型 HSM とローカル保護モデルの違い
集中型モデルでは、鍵管理サービスがネットワークの向こう側にあり、すべてのサーバーがそこへ依存する。一方、Integrated HSM は鍵をサーバー内のハードウェア境界に留め、ワークロードが直接利用できる。これにより、ネットワークを介した盗聴や、ホストメモリを狙った攻撃が根本から排除される。
オープンソース化で透明性と信頼を強化
Azure Blog の記事によれば、Microsoft は OCP（Open Compute Project）EMEA Summit で、Azure Integrated HSM のファームウェア、ドライバ、ソフトウェアスタックをオープンソースとして公開する計画を明らかにした。あわせて OCP ワークグループを立ち上げ、アーキテクチャ設計やプロトコル仕様の策定までコミュニティ主導で進める。
すでに GitHub 上に Azure Integrated HSM のファームウェアリポジトリが公開され、OCP SAFE 監査レポートなどの検証成果物も参照可能だ。これにより、クラウド事業者の自己申告だけに頼らず、第三者が実装を直接検証できる土台が整う。特に、独立した監査が必須となる規制産業やソブリンクラウドにとって、この透明性は大きな意味を持つ。
セキュリティ機能を「信じて使う」から「検証して使う」へ移行できることは、AI 推論や国家規模のデジタルインフラを支える暗号基盤として極めて重要だ。プロプライエタリなプロトコルへの依存を減らし、相互運用性と監査可能性を高める実践的な一歩といえる。
階層化された鍵管理のアプローチ
Azure Integrated HSM は、既存の Azure Key Vault や Azure Managed HSM を置き換えるものではない。これらはこれまで通り、一元的な鍵ライフサイクル管理やポリシー制御を提供する。Integrated HSM は新たなレイヤーとして、鍵が「保存中」だけでなく「使用中」もサーバーローカルで保護する仕組みを追加する。
また、TDISP（TEE Device Interface Security Protocol）などの業界標準をサポートし、機密コンピューティング環境との安全なバインドを実現する。今後数週間で、Azure V7 仮想マシンを通じて全世界の顧客が利用可能になる予定だ。
クラウドセキュリティの新標準としての可能性
Azure Integrated HSM では、暗号鍵がハードウェアの外部に一切出ない。鍵はホストメモリ、ゲストメモリ、ソフトウェアプロセスに現れることなく、暗号処理が実行される。これにより、メモリやソフトウェア層を標的とした鍵・認証情報の窃取攻撃のクラスが根本から無効化される。
セキュリティはポリシーや運用規律に頼らず、シリコンによって強制される。信頼は「契約上の約束」ではなく、ハードウェアによる証明へと変わる。さらに、ハードウェアのルートオブトラスト、計測ブート、アテステーションにより、承認済みのハードウェアやファームウェアが稼働していることを暗号学的に検証可能だ。
サーバー単位で保護がスケールするため、共有ボトルネックやネットワークホップが不要になり、パフォーマンスを犠牲にすることなくセキュリティを確保できる。機密コンピューティングや Azure Boost、データセンター制御モジュールと組み合わせることで、シリコンからソフトウェアまでの垂直統合された信頼チェーンが構築される。Microsoft は、この基盤をオープンにすることで、より安全で透明性の高いクラウドインフラの標準化を目指している。
この記事のポイント
- Azure Integrated HSM は全 Azure サーバーに統合され、改ざん耐性と FIPS 140-3 Level 3 準拠の鍵保護をハードウェアで実現する
- ファームウェアやドライバがオープンソース化され、OCP を通じたコミュニティ主導の開発が進む
- 集中型 HSM に依存せず、ローカルで鍵を守ることでネットワーク越しの攻撃やメモリ窃取を排除する
- Azure Key Vault など既存の鍵管理サービスと組み合わせ、鍵のライフサイクル全体を階層的に保護する
- アテステーションによりハードウェアレベルの信頼を検証可能とし、クラウドセキュリティの新たな標準を築く
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Amazon WorkSpacesがAIエージェント専用デスクトップを提供開始
企業がAIエージェントを本格導入しようとすると、大きな壁に突き当たる。基幹業務を支える既存のデスクトップアプリケーションやレガシーシステムは、最新のAPIを備えていないことがほとんどだ。2024年のGartnerレポートによれば、75%の組織がモダンなAPIを持たないレガシーアプリを運用しており、Fortune 500社の71%は十分なプログラムアクセス手段のないメインフレーム上で重要プロセスを動かしている。
AWSはこの課題に対して、新しいアプローチを発表した。2026年5月5日、Amazon WorkSpacesがAIエージェントに対して安全なデスクトップ環境を提供する機能をプレビュー公開した。これにより、アプリケーションの改修やAPIの新規開発なしで、AIエージェントが既存のデスクトップアプリケーションを人間と同じように操作できるようになる。
レガシーアプリケーションの課題とAI導入の壁
従来は、AIエージェントが業務システムと連携するには、アプリケーション側にAPIを実装するか、RPAによる擬似的な操作を行うしかなかった。いずれも大がかりな作業とメンテナンスを伴い、特に規制産業では監査やセキュリティ面でハードルが高かった。WorkSpacesの新機能は、仮想デスクトップという“もう一つの画面”をAIエージェントに渡すことで、この問題を一気に解消する。
WorkSpacesがAIエージェントに提供するもの
この新機能の核は、人間用に管理されてきたWorkSpaces環境を、AIエージェントにも安全に割り当てられるようにした点にある。エージェントはAWS Identity and Access Management（IAM）で認証され、WorkSpacesへ接続する。操作はすべてAWS CloudTrailとAmazon CloudWatchで監査ログが残り、既存のセキュリティ制御やコンプライアンスポリシーがそのまま適用される。
また、業界標準のModel Context Protocol（MCP）に対応しているため、LangChainやCrewAI、Strands Agentsなど、さまざまなAIエージェントフレームワークから利用できる。特定のSDKに縛られない設計は、企業の既存AI基盤に組み込みやすい。
AWSのブログ記事では、Nuvens ConsultingのディレクターChris Noon氏が次のようにコメントしている。「WorkSpacesは、クライアントが従業員に提供しているのと同じ安全でガバナンスの効いたデスクトップ環境を、AIエージェントにも提供できる。カスタムAPI統合は不要で、完全な監査証跡とエンタープライズグレードの隔離が最初から組み込まれている。規制の厳しい業界では、これは単なる追加機能ではなく、前提条件だ」
AIエージェント用WorkSpacesの設定手順
AWS Management Consoleから設定を開始する。WorkSpacesコンソールで「スタックの作成」を選択し、スタック名やフリートの関連付け、VPCエンドポイントなどの基本情報を入力する。作成ウィザードのステップ3では、AIエージェント用の新しいセクションが追加されている点がポイントだ。
ここでは「AIエージェントの追加」オプションを選択する。これにより、人間用のスタックとは別に、エージェント専用のIDと権限でデスクトップにアクセスできるようになる。続いてエージェント機能を有効化する設定へ進む。「コンピューター入力」はマウスクリックやキーボード入力、スクロール操作を許可し、「コンピュータービジョン」はエージェントがデスクトップのスクリーンショットを取得できるようにする。これはエージェントが画面を「見る」仕組みだ。さらにスクリーンショットの保存先を指定し、監査やデバッグに備える。
画面レイアウトの設定では、解像度や画像フォーマットを選ぶ。UI要素が密集した複雑なアプリケーションでは高解像度が有効だが、ターミナル風のシステムであれば720pで十分だ。これらの設定を済ませると、WorkSpacesがマネージドMCPエンドポイントを生成する。あとはAIエージェントのフレームワーク側で、このエンドポイントとIAM認証情報を指定するだけで接続が完了する。
実際の動作とユースケース
実際のデモでは、AWSがStrands Agent SDKとAmazon Bedrockを組み合わせて構築したエージェントが、架空の薬局システム上で処方箋の再発行処理を一通り実行している。患者レコードの検索から薬剤の選択、注文、再発行確認まで、すべてAPIなしで完結する。アプリケーション側はエージェントが操作していることを一切意識しておらず、ソフトウェアの改修も再構築も行われていない。
このようなアプローチは、金融機関の勘定系システムや医療機関の電子カルテ、物流システムの倉庫管理アプリなど、何十年も使い続けられている業務アプリケーションにすぐに適用できる。モダナイズに踏み切れずAI導入を断念していた企業にとって、有力な選択肢になるだろう。
今後の展望と利用可能リージョン
今回の機能はパブリックプレビューとして、米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、カナダ（中部）、欧州（フランクフルト、アイルランド、パリ、ロンドン）、アジアパシフィック（東京、ムンバイ、シドニー、ソウル、シンガポール）の各リージョンで追加料金なしで利用できる。
エージェントが人間と同じデスクトップを共有するという発想は、レガシーシステムとAIの架け橋として大きな可能性を秘めている。AWSのブログでは、GitHubリポジトリにサンプルコードが公開されており、すぐに試せる環境が整っている。今後は、より細かな権限制御やマルチエージェント対応など、エンタープライズ利用を加速させる機能拡張が期待される。
この記事のポイント
- Amazon WorkSpacesがAIエージェントに仮想デスクトップを提供する機能をパブリックプレビュー開始
- レガシーアプリのAPI改修不要で、AIエージェントがクリックや入力、スクリーンショット取得で操作可能
- IAMによる認証とCloudTrailの監査証跡で、既存のセキュリティ・コンプライアンスを維持
- MCP対応でLangChainやCrewAIなど主要フレームワークと接続可能
- 東京リージョンを含む多数のリージョンで追加費用なしで試用可能
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験