【11/13】Apache 2.4.71 で mod_http2 の致命的な脆弱性を修正、WordPress 7.2 の Secrets API ほか4件

Web 制作・WordPress 保守に関わるニュースを、4件まとめました。

今日いちばん急ぐのは Apache の脆弱性です。

自分でサーバーを管理している人はまず版を確かめてください。

各ニュースには急ぎ度を付けています。

• 【すぐ対応】今日中に対応したいもの
• 【すぐ確認】自分が対象かどうか、今日確認したいもの
• 【試しておく】時間のあるときに試しておきたいもの
• 【知っておく】すぐの対応はいらないけれど、知っておくと役立つもの

今日の早見表

【すぐ確認】Apache 2.4.71 公開、mod_http2 に致命的な脆弱性

ひとことで

Web サーバーソフトの Apache HTTP Server 2.4.71 が11月11日に出ました。

3件の脆弱性を直していて、そのうち HTTP/2 を扱う mod_http2 の脆弱性（CVE-2026-119618）は深刻度が「critical」です。

外部から任意のコードを実行される（RCE）おそれがあるとされています。

関係する人

VPS や自社サーバーで、Apache を自分で管理している人です。

レンタルサーバーを使っている人は提供元の対応を確認することになります。

何が起きているか

修正された3件は次のとおりです。

GitHub で配布されている単体の mod_h2 も、2.0.8〜2.0.42 が影響を受けます。

日本の JVN も11月12日に、2.4.71 への更新を案内しています。

Apache の公式ドキュメントによると、HTTP/2 を使うには mod_http2 を読み込み、Protocols の設定に h2 を書く必要があります。

いちばん深刻な CVE-2026-119618 は HTTP/2 を有効にしているかどうかが分かれ目になりそうです。

やること

1. Apache の版を確かめる
2. HTTP/2 を有効にしているかを確かめる
3. 2.4.71（または修正済みのパッケージ）に更新する

【サーバー側】で、たとえば次のように確かめられます。

コマンド名や設定ファイルの場所は OS や入れ方によって違います（httpd の代わりに apache2 を使う環境もあります）。

httpd -v
apachectl -M | grep http2
grep -ri "^\s*Protocols" /etc/httpd/

OS のパッケージ（dnf や apt）で入れている場合、版の番号が 2.4.71 にならないまま、修正だけが取り込まれることがあります。

その場合は版の番号ではなく、ディストリビューションのセキュリティ情報で、この CVE 番号が修正済みかを確かめるのが確実です。

レンタルサーバーの場合は提供元のお知らせを見てください。

私が使っている Xserver のお知らせには11月13日の朝の時点で、この件の告知はまだありませんでした。

出典

• Apache HTTP Server 2.4 の脆弱性一覧: https://httpd.apache.org/security/vulnerabilities_24.html
• JVN「Apache HTTP Server 2.4における複数の脆弱性に対するアップデート（2026年11月11日）」: https://jvn.jp/vu/JVNVU90805396/
• Apache のドキュメント「HTTP/2 guide」: https://httpd.apache.org/docs/2.4/howto/http2.html

【試しておく】WordPress 7.2 に「Secrets API」が入る予定

ひとことで

WordPress 7.2 で、API キーなどの認証情報を暗号化して保存する「Secrets API」が加わる予定です。

11月11日に、開発者向けの解説記事（Dev Note）が公開されました。

7.2 の RC1 は11月17日、正式版は12月10日の予定です。

関係する人

• 外部サービスと連携するプラグインやテーマを作っている人
• WordPress の保守で wp-config.php を扱う人

保守をしている人にも、wp-config.php に足す鍵の扱いで関係があります。

何が変わるか

いまは多くのプラグインが、設定画面で受け取った API キーを、データベース（wp_options）にそのままの文字で保存しています。

そうすると、データベースのダンプやバックアップ、ステージングへの複製にも、キーがそのまま残ります。

Secrets API を使うと、値は暗号化されて保存されます（libsodium の XChaCha20-Poly1305）。

暗号化の鍵のもとになるのは wp-config.php に書く WP_SECRETS_KEY です。

基本の使い方は次のとおりです。

// 保存する
$result = wp_set_secret( 'my-plugin/api-key', $api_key );

// 取り出す
$secret = wp_get_secret( 'my-plugin/api-key' );
if ( $secret instanceof WP_Secret ) {
    $client->authenticate( $secret->reveal() );
}

プラグインを作る人が押さえておきたいのは次の点です。

• 名前は「プラグインのスラッグ/名前」の形: スラッシュのない名前でも動きますが、警告（_doing_it_wrong()）が出ます。前置きはほかのプラグインとの上書きを防ぐためのもので、アクセスの制限ではありません。サイトで動くコードなら、どの値でも読めます
• 値を取り出せるのは reveal() だけ: 表示したり、ログや JSON に出したりしても、[secret:my-plugin/api-key] としか出ません
• null と WP_Error を区別する: 一度も保存していなければ null、保存されているのに読めない（鍵やデータベースが使えない）ときは WP_Error が返ります。エラーのときに「キーを入力し直してください」と求めると、まだ使えるキーを上書きしかねない、と注意されています
• 直前の値が1つ残る: 新しい値を保存すると、前の値が1世代残ります。キーを入れ替えるときに、前のキーに戻れます
• 権限の確認はしてくれない: cron や REST API からも動くように、関数側では権限を確かめません。値を入力・管理する画面で、自分で current_user_can() を確かめる必要があります
• 既存の設定から移せる: wp_import_option_as_secret() で、wp_options の値を移せます。元のオプションは残るので、自分で消します
• 書き込めないホストもある: ホストによっては値をホストの管理画面で管理し、WordPress からは読むだけにしている場合があります。その場合 wp_secrets_provider_is_writable() が false になり、保存は WP_Error になります。そのときに wp_options へ保存し直さないように、と書かれています

保守の人向け: WP_SECRETS_KEY の扱い

新しくインストールしたサイトでは、インストーラーがソルトと一緒に WP_SECRETS_KEY を書き込みます。

既存のサイトは自分で足す必要があります。

サイトヘルスが wp-config.php に貼る1行を作ってくれるので、ソルトの下に貼ります。

空の値や、wp-config-sample.php の仮の文字列、認証キー・ソルトを使い回した値は使えません。

いちばん気をつけたいのはソルトと同じ感覚で扱わないことです。

ソルトは変えてもログインし直すだけで済みますが、WP_SECRETS_KEY は値を保存したあとに変えたり消したりすると、保存した値がすべて読めなくなります（元の鍵に戻せば読めます）。

保守の現場だと、次の場面で引っかかりそうだと思いました。

• サイトを移行するときに、wp-config.php を新しく作り直す
• セキュリティ対策として、ソルトを定期的に入れ替えている
• 本番とステージングで wp-config.php を分けていて、データベースだけをコピーする

3つ目の場合、鍵が違えばコピーした先で値を読めないはずです。

ここは私の推測で、まだ試していません。

鍵を入れ替えたいときは、古い鍵を WP_SECRETS_KEY_PREVIOUS に入れて入れ替える手順が解説記事の最後に載っています。

サイトヘルスの「セキュリティ」にも、鍵がない・読めない値がある、といった状態を知らせる3つの項目が加わります。

反対意見も出ている

解説記事のコメント欄では、ほかの開発者から「7.2 から外すべき」という強い反対意見が出ています。

認証情報はアプリの外で管理して、読むだけにするのが業界の標準だ、という理由です。

これに対して提案した側は、多くの WordPress サイトでは設定画面が唯一の入口で、読むだけの仕組みではそうしたサイトの役に立たない、と答えています。

RC までに形が変わる可能性もありそうです。

やること

• プラグインを作っている人: 7.2 の Beta や RC で試しておく。移す前に wp_is_secrets_api_available() で使えるかを確かめる
• 保守をしている人: 7.2 に上げたら、サイトヘルスの案内に沿って WP_SECRETS_KEY を足す。移行の手順書に「このキーは必ず引き継ぐ」と書き足しておく

ベータ版で試していた人は注意が必要です。

Beta 1 以降に破壊的な変更が入っています。

独自の secrets.php ドロップインを書いている場合、implements を extends に書き換えないと、すべてのリクエストで致命的なエラーになるそうです。

7.2 より前の版向けには同じ機能のプラグインが GitHub で公開されているとのことです（私は試していません）。

出典

• Make WordPress Core「The Secrets API in WordPress 7.2」: https://make.wordpress.org/core/2026/11/11/the-secrets-api-in-wordpress-7-2/
• Dev Chat Agenda（11月11日）: https://make.wordpress.org/core/2026/11/11/dev-chat-agenda-nov-11-2026/
• WordPress のロードマップ: https://wordpress.org/about/roadmap/

【試しておく】Figma に「3D transform」が登場

ひとことで

11月12日、Figma Design に「3D transform」という新しいエフェクトが加わりました。

レイヤーを X・Y・Z の3つの軸で回転させて、奥行きや遠近を付けられます。

関係する人

Figma で受け取ったデザインをコーディングする人と、デザイナーです。

何ができるか

• ベクター、画像、フレーム、コンポーネント、テキストに使える
• エフェクトなので、元のレイヤーは編集できるまま。いつでも非表示・削除できる
• 親フレームに「Perspective」を付けると、中のレイヤーに共通の遠近が付く
• Figma Motion と組み合わせて、カードの裏返しや回転のアニメーションにできる
• Figma のエージェントに「カードを 3D で回転させて」と頼むこともできる

ヘルプによると、すべてのプランで使えます。

ただし、Full シートと、ファイルの編集権限が必要です。

コーディングする人向け: CSS との対応

Dev Mode で、3D transform の値を CSS としてコピーできます。

ヘルプに書かれている対応は次のとおりです。

Figma MCP サーバーにつないだコーディングエージェントに、3D の効果ごと渡すこともできます。

ヘルプには「Keep nested layers 3D」をオンにした親フレームでは不透明度やブレンドモード、クリップなどが使えなくなる、とも書かれています。

CSS でも opacity や overflow: hidden を指定すると 3D が平らになる仕様があるので、それに合わせた制限のようです。

実装するときに「Figma では立体なのに、ブラウザだと平ら」となったら、まずこのあたりを疑うとよさそうです。

それから、カードが裏返るような動きを付けるときは prefers-reduced-motion で動きを減らす設定の人に配慮しておきたいところです。

やること

デザイナーから 3D のデザインが届く前に、一度 Dev Mode で出る CSS を見ておくと安心です。

出典

• Figma のリリースノート: https://www.figma.com/release-notes/?title=design-in-3d-natively-in-figma-and-ship-directly-to-code
• Figma ヘルプ「Create 3D effects in Figma Design」: https://help.figma.com/hc/en-us/articles/44568893374999

【知っておく】Google が AI による概要の出典表示を下に移すテスト

ひとことで

Google 検索の「AI による概要」で、参照したサイトの数の表示を、回答の一番下に置くテストが見つかりました。

Google の公式発表はまだなく、一部の検索で見られたテストです。

関係する人

Google 検索からの流入があるサイトの担当者です。

何が起きているか

見つけたのは Brodie Clark 氏で、X で報告しました。

Search Engine Roundtable が11月11日に紹介しています。

Clark 氏によると、同じ実験の前の版では参照したサイトの数が回答の上部（出典の一覧のすぐ上）に表示されていました。

今回の版では回答の一番下にあり、マウスを重ねると出典の一覧が出るそうです。

Search Engine Roundtable は出典がさらに見つけにくくなって、サイトへのクリックが減るかもしれない、と見ています。

やること

今すぐやることはありません。

AI による概要の見せ方はこうした小さなテストで少しずつ変わっています。

Search Console でクリック数やクリック率が急に動いたとき、「表示の変更かもしれない」と考える材料として覚えておくとよさそうです。

出典

• Search Engine Roundtable: https://www.seroundtable.com/google-ai-overview-source-icons-bottom-42519.html

今日の確認リスト

• Apache を自分で管理しているサーバーは版と HTTP/2 の設定を確かめ、2.4.71 か修正済みのパッケージに更新する
• レンタルサーバーは提供元のお知らせで Apache の対応を確認する
• WordPress 7.2 に上げたら、WP_SECRETS_KEY を足す。移行の手順書に、このキーの引き継ぎを書き足す
• Figma の 3D transform は Dev Mode で出る CSS を一度見ておく
• AI による概要の表示のテストは Search Console の数字を見るときの材料として覚えておく