WEBサイトPHP 8.6.0のRC5は11月5日に出た試験版で、正式版は11月19日の予定。セッションの既定値3つが安全側に変わる ── ログイン・フォーム・外部との連携が壊れないかを試験環境で確かめる13項目（2026年11月時点）
PHP 8.6.0のRC5は11月5日に出た試験版で、正式版は11月19日の予定。セッションの既定値3つが安全側に変わる ── ログイン・フォーム・外部との連携が壊れないかを試験環境で確かめる13項目（2026年11月時点）
目次
- 01 何が書いてあるか — PHP 8.6.0のRC5は11月5日に出た試験版で、セッションの既定値3つが安全側に変わる
- 02 なぜ・背景 — 変わるのは、何も書いていないサイトの動きだけである
- 03 用語 — 出てくる言葉を、先にそろえる
- 04 型別 — 適用範囲、書かれていないこと、場面ごとの確かめ方
- 05 明日、担当サイトで確認できることチェックリスト
- 06 代替・他の選択肢 — 新しい値に合わせるか、必要な設定だけ戻すか、作りを直すか
- 07 当サイトで確かめたこと — 外から読めるのは、Cookieの印の一部だけだった
- 08 このテーマは、ここまで — PHP 8.6の準備と、セッションの話
- 09 この記事のまとめ
01 何が書いてあるか — PHP 8.6.0のRC5は11月5日に出た試験版で、セッションの既定値3つが安全側に変わる
引用について
この記事は、2026年11月6日に開いて読んだ次のページの内容を書いている。PHP公式サイトのお知らせの一覧、GitHubに置かれたPHP 8.6.0 RC5のUPGRADING（版を上げるときの注意をまとめた文書）、UPGRADINGが挙げているRFC「Secure Session Configuration Defaults」、PHPマニュアルのセッションの設定の一覧、MDNのSet-Cookieヘッダーの説明である。日本語の文は、記事の筆者がまとめた要旨で書く。英語の文は、原文のまま引き、すぐ後に筆者の訳を付ける。筆者の読みと案は、そう書いて分ける。RC3からRC5までの変更点をまとめたNEWSファイルと、実装したコードは、開いていない。
PHP公式サイトは、2026年11月5日付けで「PHP 8.6.0 RC5 available for testing」というお知らせを出した。RC5は、正式版の前に出る試験用の版（リリース候補）の5つ目である。この記事が扱うのは、その版の変更点のうち、セッションの設定3つの既定値が変わるという1点だけである。既定値とは、設定ファイルにも、プログラムの中にも書いていないときに使われる値のことである。
PHP 8.6.0の全体の変更点は、当サイトの別の記事「PHP 8.6.0のRC3は試験用で、本番では使えない。UPGRADINGの非互換と非推奨は、自社のコードと設定で確かめられる ── 試験環境で確認する13項目（2026年10月時点）」で、章ごとに読む方法を書いた。今回は、あの記事の13項目の中でも、担当サイトのログインや、フォームや、外部サービスとの連携に直接かかわる3つの設定を、場面ごとに掘り下げる。
RC5のお知らせが書いていること
お知らせの本文には、試験用であることと、正式版の予定日が、次のように書かれていた。
"Please DO NOT use this version in production, it is an early test version."（訳: この版を本番で使わないでください。早い段階の試験版です。）
"The next release will be the first GA release, PHP 8.6.0, planned for 19 November 2026."（訳: 次のリリースは最初の正式版（GA）のPHP 8.6.0で、2026年11月19日の予定である。）
この記事を書いた2026年11月6日から、正式版の予定日まで、13日ある。「予定」と書かれているので、日付が動く可能性は、お知らせからは否定できない。なお、10月21日に出たRC4のお知らせには、"Everyone running earlier builds of PHP 8.6.0 is strongly encouraged to update immediately."（訳: PHP 8.6.0の、これより前の版を動かしている人は全員、直ちに更新することを強く勧める。）とあった。試験環境をRC3などの古い版で作っていたなら、RC5で作り直してから試す。
UPGRADINGのSessionの節が書いている、3つの既定値
UPGRADINGのSessionの節には、次の1文がある。
"The defaults of three session INI settings have changed to provide secure behavior out of the box:"（訳: セッションの設定（INI）3つの既定値は、最初から安全な動きになるように、変更された。）
3つの設定と、公式の説明の要旨を、表に並べる。影響を受ける場合に、どの値を明示するかも、UPGRADINGは設定ごとに書いている。
| 設定の名前 | いままで | 8.6の既定値 | UPGRADINGが書いた注意（要旨） |
|---|---|---|---|
| session.use_strict_mode | 0 | 1 | サーバーが知らないセッションIDを受け付けない。外から渡されたIDを、保存先に対応する記録が無いまま受け入れていた独自の処理は、IDの確認の処理を実装するか、0を明示する |
| session.cookie_httponly | 0 | 1 | セッションのCookieを、JavaScriptのdocument.cookieで読めなくなる。読んでいるアプリは、0を明示する |
| session.cookie_samesite | 未設定 | "Lax" | セッションのCookieは、別のサイトからの要求のうち、安全な方法による最上位の移動以外には付かなくなる。別のサイトからのPOSTにCookieが付くことに頼るアプリは、"None"を明示し、session.cookie_secureも1にする |
同じ節に書かれた、ほかの変更
Sessionの節には、既定値のほかにも、空のセッションの扱いの変更と、IDの確認と生成の関数を持たない保存処理を非推奨にする変更がある。この記事は既定値の3つに絞る。独自の保存処理があるかは、05章の11番目の項目で見つける。
マニュアルは、まだ古い既定値のまま
2026年11月6日に開いたPHPマニュアルの設定の一覧では、session.use_strict_modeは"0"、session.cookie_httponlyは"0"、session.cookie_samesiteは""（空）と書かれていた。8.6の正式版が出る前なので、マニュアルが古い値のままなのは、筆者の読みでは自然である。ただし、正式版が出た後も、マニュアルの更新が追いつくまでは、既定値の欄を読んで判断すると、古い値を読むおそれがある。確かめるときは、UPGRADINGの文面と、動かした結果の両方を見る。
02 なぜ・背景 — 変わるのは、何も書いていないサイトの動きだけである
公式が挙げた理由
UPGRADINGが挙げる理由は、先に引いた1文のとおり、最初から安全な動きにすることである。RFCには、もう少し具体的に、3つの設定は安全に関わるのに、アプリが不要に危険にさらされる既定値で出荷されている、と書かれている。RFCの状態は「Accepted（承認）」で、設定ごとに投票が行われ、use_strict_modeは賛成27・反対0・棄権0、cookie_httponlyは賛成26・反対0・棄権1、cookie_samesiteは賛成26・反対0・棄権0だった。反対は、3つとも0である。
use_strict_mode — セッションの固定を防ぐ
RFCは、use_strict_modeが0のとき、サーバーはURLの引数、フォーム、Cookieのどれかで渡された、形の正しいIDを受け入れて、そのIDでセッションを始めると書いている。攻撃者が決めたIDを、利用者にログインさせれば、攻撃者はそのIDで、利用者のログイン状態を使える。これが、セッションの固定という攻撃である。1にすると、サーバーは、提案されたIDが保存先に存在するかを確かめ、無ければ新しいIDを作る。マニュアルは、"Enabling session.use_strict_mode is mandatory for general session security. All sites are advised to enable this."（訳: use_strict_modeを有効にすることは、一般的なセッションの安全のために必須である。すべてのサイトに、有効にすることを勧める。）と書いている。
cookie_httponly — ページの中のスクリプトから、Cookieを読ませない
HttpOnlyの印が付いたCookieは、ブラウザがdocument.cookieに出さない。ページに紛れ込んだ悪意のあるスクリプトが、セッションのCookieを盗むことを、難しくする。RFCは、この設定がPHP 5.2.0からあり、既定で切っておく正当な理由は無いと書いている。
cookie_samesite — 別のサイトからの送信に、Cookieを付けない
SameSiteの印は、別のサイトから来た要求に、ブラウザがCookieを付けるかを決める。Laxにすると、リンクを押して移動するような、安全な方法の最上位の移動には付くが、別のサイトのページに置かれたフォームからのPOSTなどには付かない。別のサイトに仕込まれた偽のフォームで、利用者のログイン状態を使われる攻撃（CSRF）を、ある程度防げる。
変わるのは「何も書いていない」サイトだけ
UPGRADINGの3つの注意は、どれも「明示的に設定せよ」という書き方をしている。そこから読むと、php.iniやプログラムの中で、すでに3つの値を書いているサイトは、8.6に上げても、書いた値が使われる。変わるのは、何も書かずに、PHPの既定値に任せているサイトである。これは筆者の読みである。CMSやフレームワークが、自分で値を決めているかは、サイトごとに違い、この記事では確かめていない。
3つは、いまのPHPでも指定できる
マニュアルの設定の一覧では、3つとも、変更できる範囲が「INI_ALL」と書かれている。session_set_cookie_params()の説明には、配列で渡す書き方が7.3.0で加わり、SameSiteを指定できるのは7.3.0からと書かれている。つまり、8.6を入れなくても、今のPHP（7.3以降）の試験環境で、3つを新しい既定値と同じにして、動きを先に確かめられる。この記事の手順は、この考え方でできている。
ブラウザの側の事情は、ブラウザによって違う
RFCは、Chromeは80（2020年2月）から、SameSiteの指定が無いCookieを、Laxとして扱い、Firefoxは103（2022年8月）、Edgeは85（2020年8月）から同じだと書いている。一方で、Safariは、指定が無いCookieをLaxとして扱わないと、RFCは書く。MDNは、ブラウザが既定でLaxにするときは、少し緩い版が使われると説明している。"In this more permissive version, cookies are also included in POST requests, as long as they were set no more than two minutes before the request was made."（訳: この緩い版では、Cookieが設定されてから2分以内のPOSTの要求にも、Cookieが付く。）
ここから、筆者は次のように読む。ふだんChromeだけで確認しているサイトは、緩いLaxの動きを見ている。PHPが"Lax"を明示すると、2分以内のPOSTにCookieが付くという緩みが無くなり、Safariでも初めてLaxの動きになる可能性がある。この読みは、RFCとMDNの文面を並べたもので、各ブラウザの文書は開いていない。確かめるときは、ブラウザを変えて、同じ操作を試す。
03 用語 — 出てくる言葉を、先にそろえる
用語
セッションIDは、サーバーが、ログイン中の利用者を見分けるために出す番号である。ブラウザは、この番号をCookieに入れて、要求のたびにサーバーへ送る。セッションの固定は、攻撃者が用意した番号を、利用者に使わせる攻撃で、厳格モード（use_strict_mode）は、サーバーが知らない番号を受け付けなくする設定である。
用語
HttpOnlyは、Cookieに付ける印で、ブラウザは、この印が付いたCookieを、ページのスクリプト（JavaScript）に見せない。サーバーへ送る要求には、これまでどおりCookieが付く。印があっても、セッションIDがサーバーとのやり取りで使われなくなるわけではない。
用語
SameSiteは、別のサイトから来た要求にCookieを付けるかを決める印である。値は3つある。Strictは、同じサイトから来た要求にだけ付ける。Laxは、同じサイトの要求に加えて、リンクを押すなどの安全な方法の最上位の移動に付ける。Noneは、別のサイトからの要求にも付ける。Noneにするときは、Secure（https接続のときだけ送る印）も必要である（MDNによる）。
「明示」と、RC・GA
この記事の「明示」は、php.ini、.user.ini（サイトごとに置ける設定ファイル）、プログラムの中のini_set()やsession_set_cookie_params()などで、値を書いていることを指す。RCは正式版の前の試験版、GAは最初の正式版である。
04 型別 — 適用範囲、書かれていないこと、場面ごとの確かめ方
🅰 どのサイトが当てはまるか
当てはまるのは、PHP 8.6に上げるサイトで、3つの値を明示していないサイトである。保存処理が独自のものでも、IDの確認の関数を持たず常にtrueを返すものは、RFCによれば、厳格モードの影響を受けない。RFCは、RedisやMemcachedの既定の保存処理を、その例に挙げている。一方、マニュアルは、IDの確認の関数が無い保存処理では、厳格モードが実質的に無効になると書いている。8.5以前のまま使うサイトは、版を上げるまでは、この変更を受けない。8.6に上げた後の動きは、3つの設定を、サイトの設定やプログラムが明示しているかで決まる。どのサイトが明示しているかは、見てみないと分からない。担当サイトが多い場合は、05章の最初の項目で、3サイトだけを先に調べる。
🅱 公式が書いていないこと
UPGRADING、RFC、お知らせは、次のことを書いていない。なお、RC3からRC5までの間に、3つの既定値が変わったかは、NEWSを開いていないので、確かめていない。
- どの種類のアプリや、どのCMSが、実際に動かなくなるか。UPGRADINGは、条件を挙げるだけである。
- 国内のレンタルサーバーや、ホスティング会社が、8.6に対応する時期。
したがって、この記事の場面ごとの整理は、公式の説明を、筆者が分けたものである。自分のサイトで起きるかどうかは、試験環境で動かすまで分からない。
🅲 手順 — 場面ごとに、何を試すか
次の表は、3つの場面と、関係する設定と、試験環境で行う操作と、うまくいかないときに見える症状を並べたものである。症状は、筆者の読みで、実際の見え方はサイトによって違う。
| 場面 | 関係する設定 | 試験環境で行う操作 | うまくいかないときの症状（筆者の読み） |
|---|---|---|---|
| ログインの前後 | httponly strict_mode | ログインして3画面を移動する。JavaScriptの検索で、Cookieを読む箇所を探す | ログインしたのに、次の画面でログイン画面に戻る。画面の一部が、ログイン前の表示になる |
| フォームの送信 | samesite | ログイン後に、フォームを送信する。別のドメインから埋め込んでいる画面があれば、そこからも送信する | 送信すると、ログインを求められる。送信した内容が捨てられる |
| 外部との連携 | samesite strict_mode | 決済や外部認証の試験の機能で、戻りまでを1回行う。外から渡されたIDを使う連携が無いかを、担当者に聞く | 外部の画面から戻ると、ログインが外れている。引き継いだはずのセッションが、新しいセッションになる |
ログインの前後 — httponlyとstrict_modeを見る
ログインの前後で見るのは、2つである。1つ目は、JavaScriptがセッションのCookieを読んでいないかである。RFCは、このCookieを読んで、独自のリクエストヘッダーにIDを入れるような作りを例に挙げ、セッションIDはサーバー側の資格情報なので、クライアント側のコードが使うべきではない、と書いている。2つ目は、外から渡されたIDを受け入れる作りが無いかである。RFCは、例として、ファイルによる保存処理を使い、サブドメインの間で秘密の合言葉のようにIDを渡す作りを挙げ、IDが拒否されると書いている。
フォームの送信 — samesiteを見る
フォームの送信で見るのは、自社のログイン後の画面に向けて、ほかのサイトからPOSTが来る作りが無いかである。筆者の例では、広告のランディングページに置いた申込みフォームの送信先が、会員用の画面である場合や、別のドメインで運営しているお知らせの画面が、会員のデータを更新する場合である。RFCは、"legacy cross-origin form submissions"（訳: 古い、別の配信元からのフォーム送信）を、影響を受ける例に挙げている。
外部との連携 — samesiteとstrict_modeの両方を見る
外部との連携で見るのは、決済や外部認証から、POSTで自サイトに戻ってくる流れである。RFCは、次のように書いている。"Applications that rely on cross-site POST carrying the session cookie — for example, SP-initiated SAML SSO flows or legacy cross-origin form submissions — must either set SameSite=None; Secure explicitly for those endpoints or migrate to a token-based flow."（訳: 別のサイトからのPOSTがセッションのCookieを運ぶことに頼るアプリは、たとえばサービス側から始めるSAMLのシングルサインオンや、古い別の配信元からのフォーム送信では、それらの窓口にSameSite=None; Secureを明示するか、トークンを使う流れへ移さなければならない。）
注意
決済や外部認証の連携を、本番の画面で試さない。決済の試験の機能や、提供元が用意した試験用の環境を使う。提供元の試験の機能を使えるかは、提供元の説明で確かめる。この記事では、特定の決済事業者や認証の仕組みを、確かめていない。
先に、いまのPHPで3つの値を試す
8.6のRC5を入れた試験環境を用意するのが難しいときは、今のPHPの試験環境で、3つを新しい既定値と同じに書いて試す。書く場所は、php.ini、.user.ini、プログラムの先頭のsession_set_cookie_params()などである。session_set_cookie_params()は、マニュアルによると、session_start()の前に、要求のたびに呼ぶ必要がある。書いたあとは、ブラウザの開発者ツールで、ログイン後の応答のSet-Cookieに、HttpOnlyとSameSite=Laxが付いたかを見る。
05 明日、担当サイトで確認できることチェックリスト
以下は、PHP 8.6のセッションの既定値3つの変更が、担当サイトに当たるかを、試験環境で確かめる13項目である。1〜2番目は公式の文面を控える確認、3〜9番目と11番目は担当サイトの現状を見る確認、10番目と12番目は試験環境で操作する確認、13番目は結果を残す確認である。チェックの状態は、使っているブラウザに保存され、サーバーには送られない。なお、台帳は、担当サイトの版や設定を、1サイト1行で書いて残す表のことである（表計算の1枚でよい）。
- php.netのお知らせを開き、RC5の記事の「本番で使わない」の文と、正式版の予定日（11月19日）を、台帳に書き写す
- UPGRADINGのSessionの節を開き、3つの既定値の段落を、設定の名前と新しい値だけで、台帳に3行で書く
- 担当サイトを3つ選び、php.ini、.user.ini、プログラムのini_set()の3か所で、session.use_strict_modeが書かれているかを、有る・無いで台帳に書く
- 同じ3サイトで、session.cookie_httponlyが書かれているかを、有る・無いで台帳に書く
- 同じ3サイトで、session.cookie_samesiteが書かれているかを、有る・無いで台帳に書く
- 担当サイトを1つ選び、ログイン後の画面の応答のSet-Cookieを、ブラウザの開発者ツールで開き、HttpOnly・SameSite・Secureのうち付いているものを書く
- プログラムのファイルを「document.cookie」で検索し、見つかったファイルの数を数えて、セッションのCookieを読む箇所が有るかを書く
- 決済や外部認証の連携を最大3つ書き出し、戻りがリンク（GET）かフォーム送信（POST）かを、提供元の説明で確かめて書く
- 別のドメインに、自社のログイン後の画面を埋め込んでいる箇所が有るかを、担当者に聞き、有る・無いで台帳に書く
- 試験環境で、3つの値を新しい既定値と同じにして、ログイン、フォームの送信、ログアウトを、1回ずつ行い、結果を書く
- 独自のセッション保存処理（session_set_save_handler()）を、プログラムの検索で探し、有る・無いを台帳に書く
- ブラウザを2種類（Chromeと、Safariまたは別のブラウザ）に変えて、10番目の項目のログインとフォームの送信を、もう1回ずつ行う
- 台帳に「8.6の既定値の影響」の列を足し、サイトごとに、無し・要確認・要変更のどれかを書き、結果を試験した日付と一緒に残す
06 代替・他の選択肢 — 新しい値に合わせるか、必要な設定だけ戻すか、作りを直すか
3つの選び方を、状況ごとに表で並べる
試験で、動かなくなる場面が見つかったときの選び方を、表に並べる。表の内容は、UPGRADINGとRFCが挙げた選択肢を、筆者が状況ごとに整理したものである。
| 状況 | 選べる対応 | 利点 | 注意すること |
|---|---|---|---|
| 何も当てはまらない | 新しい既定値のまま使う | 設定を書く手間が無い | 試験の結果と日付を、台帳に残す |
| JavaScriptがセッションのCookieを読んでいる | httponlyを0に明示する。または、JavaScript用の別の値（トークン）を用意する | 前者は、すぐ元の動きに戻せる | 前者は、攻撃者のスクリプトにもCookieが読める状態に戻る。RFCは、クライアントが使う値は、セッションのCookieと別にする案を書く |
| 別のサイトからのPOSTで戻ってくる連携がある | その窓口だけ、SameSiteをNoneにし、Secureも付ける。または、トークンを使う流れへ移す | 連携が続けられる | Noneは、別のサイトからの要求にもCookieが付く設定である。窓口を限る |
| 外から渡されたIDを受け入れている | 渡す側で、先にセッションを書き込んで閉じてから、IDを渡す。または、use_strict_modeを0に明示する | 前者は、厳格モードのまま連携できる | 後者は、セッションの固定への備えが無い状態に戻る。RFCは、前者を正しい方法と書く |
| 独自の保存処理で、IDの確認が無い | IDの確認と生成の処理を足す | 非推奨の対象に当たらなくなる（UPGRADINGの文面からの、筆者の読み） | 保存先に合わせて作る。作りを直す人が必要 |
Noneは、いまのマニュアルの書き方に注意する
session_set_cookie_params()のマニュアルは、samesiteの値を「LaxまたはStrict」と書いていて、Noneの名前は書いていない。UPGRADINGは、Noneを明示するよう書いている。php.iniやini_set()でNoneを指定できるのか、session_set_cookie_params()の配列で指定できるのかは、この記事では確かめていない。試験環境で、指定した後の応答のSet-Cookieに、SameSite=Noneが付くかを見て、確かめる。
PHPを上げない選択にも、期限がある
8.6に、今すぐ上げない選択はある。ただし、PHP公式の対応版の一覧によると、2026年11月6日に開いた時点で、8.2のセキュリティ保守は2026年12月31日まで、8.3は2027年12月31日まで、8.4は2028年12月31日まで、8.5は2029年12月31日までである。8.2を使うサイトは、約8週間後に公式の修正が出なくなる。8.2から先の計画は、当サイトの別の記事「PHP 8.2のセキュリティサポートは2026年12月31日で終わる ── 自社と担当サイトのPHPの版を確かめ、年内の移行先と試験日を決める13項目（2026年10月時点）」に書いた。8.6へ上げるかどうかは、この日付とあわせて決める。
試験を助ける道具
当サイトの🔧 【メンテナンス】WEBサイトの状況チェック・比較ツール ★チガウン — 試験用のサイトと本番の違いを、ページごとに比べる（🔒会員限定）というツールは、ページの説明によれば、試験用のサイトと本番の違いを、ページごとに比べられる。設定を変えた試験環境と今の環境を比べるときに使える。ログイン後の画面を比べられるかは、説明に書かれていないので、確かめていない。🔧 【SEO/UX】WEBサイト総合分析・レポートツール — HTTPS対応とセキュリティヘッダーを見るというツールは、説明によれば、HTTPS対応とセキュリティヘッダー（HSTS・CSP・X-Frame-Options）を見る。Cookieの印を見るとは、説明に書かれていない。画面の見え方を、前後で並べて見るときは、🔧 【運営】WEBページのスクリーンショット、表示デバイスの比較をまとめて撮っちゃおツール — 設定を変えた前後の見え方を並べるというツールが使える。
実務のヒント
3つの設定を一度に変えると、どれが原因かが分からなくなる。1つずつ新しい値にして、ログイン、フォーム送信、外部の連携を試す。うまくいかなかった設定が分かれば、戻す設定も1つで済む。3つとも新しい値で通ったサイトは、台帳に「無し」と書く。
07 当サイトで確かめたこと — 外から読めるのは、Cookieの印の一部だけだった
何を確かめたか
当サイトは、この記事の読者と同じ立場なので、外から読める範囲を確かめた。2026年11月6日の12時31分に、ログインしていない状態で、トップページ、無料ツールの画面、解説記事の画面の3つを、1回ずつ開き、応答のヘッダーにあるSet-Cookieの行を読んだ。3ページとも、SecureとHttpOnlyの印が付いていて、SameSiteの指定は無かった（3ページ中3ページ）。Cookieの値と名前は、ここには書かない。
この結果の読み方
3つのうち2つ（httponlyとsamesite）は、外から読める。use_strict_modeは、応答のヘッダーに出ないので、外からは読めない。外から読めない設定は、サーバーの中の設定ファイルを見るしかない。
SameSiteの指定が無い応答は、8.6の既定値が"Lax"になると、アプリ側が明示していなければ、印が付く側に変わる。当サイトが8.6に上げる予定は、この記事に書いていない。ここで書いたのは、担当サイトでも、外からの確認だけで、3つのうち2つは、今日の時点の状態が分かることである。05章の6番目の項目は、この見方に合わせた。
確かめていないこと
- ログイン後の画面の応答。ログインしないで開ける画面だけを読んだ。
- ブラウザごとのCookieの扱いの差。ブラウザを変えて試してはいない。
- サーバーの中の、3つの設定の値。外からは読めない。
08 このテーマは、ここまで — PHP 8.6の準備と、セッションの話
これまでの記事
- PHP 8.6のRC3の変更点を、章ごとに読む方法は、「PHP 8.6.0のRC3は試験用で、本番では使えない。UPGRADINGの非互換と非推奨は、自社のコードと設定で確かめられる ── 試験環境で確認する13項目（2026年10月時点）」で書いた。
- セッションの、別の設定（アップロード進捗）については、「PHP公式は、次の通常のリリースまで、セッションのアップロード進捗を0にするよう勧めた ── 設定の値・切り替えるコード・修正版に上げたあとの戻りを確かめる13項目（2026年10月時点）」で書いた。
- 担当サイトのPHPの版を、一覧にして管理する方法は、「PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）」で書いた。
- PHPの脆弱性の全体像は、「PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で ── 自分のサイトは関係あるか、更新の順番、更新の後に確かめること、攻撃を受けたかの調べ方、当サイトとチームの記録」で書いた。
- 修正が入ったかを値で確かめる方法は、「PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった ── 修正が入ったかを値で確かめる4つの方法と、3本目の知らせ（CVE-2026-115560）を当サイトで確かめた記録」で書いた。
今回の記事の位置
RC3の記事は、変更点の全体を読む手順だった。13項目のうち、複数の項目が、セッションの3つの設定に触れていた。今回は、RC5が出て、正式版の予定日が11月19日と書かれたこと、そしてRFCの内容（承認と、投票の結果と、影響を受けるアプリの例）を読んだうえで、3つの設定を、ログイン・フォーム・外部との連携の場面ごとに掘り下げた。
2026年11月6日 — この記事の確認日
PHP公式のお知らせで、RC5は11月5日に出ていて、正式版は11月19日の予定だった。この日以降にお知らせが増えていれば、05章の最初の項目で、正式版が出たかと、予定日が動いたかを、確かめ直す。期限を自分のサイトの期限に読み替える方法は、「PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だった ── 期限の日に当サイトで確かめた4つと、自分の記事の言い過ぎ、期限を自分のサイトの期限に読み替える方法」にある。
現在の貴方のIPアドレス
このサイトで書いている人
