PHPにSQLインジェクション脆弱性 全ブランチ更新を

【更新 2026-08-01】本記事を見直し、修正しました。主な修正点：CVSS v4.0「8.1」を報道ベースの数値として扱っていた記述を、PHP開発チーム（CNA）がCVEレコードに登録した公式スコアである旨に訂正し、NVDへの登録状況も実態（登録済み・NIST側の分析のみ未完了）に合わせました。

PHPの開発チームは現地時間2026年7月30日、複数の脆弱性を修正したセキュリティリリース PHP 8.5.9 / 8.4.24 / 8.3.33 / 8.2.33 を公開しました。今回の目玉はSQLインジェクション（CVE-2026-17543）で、サポート中の全ブランチが影響を受けます。

ただし「PHPにSQLインジェクション」と聞いて全社的に慌てる必要はありません。この脆弱性が刺さるのはPostgreSQLを使い、かつ pg_insert() などの特定関数を使っているアプリだけです。逆にBCMathの脆弱性は8.4系・8.5系のみが対象と、修正内容がブランチごとに異なります。まず自社の該当有無を切り分けるのが先決です。

この記事でわかること

• 今回修正された4件の脆弱性と、それぞれの対象ブランチ
• SQLインジェクションが「刺さる環境／刺さらない環境」の見分け方
• バージョン番号だけでは判断できない、ディストリ配布PHPの落とし穴
• 2026年末にサポートが切れるPHP 8.2系への向き合い方

何が起きたのか

PHP公式のChangeLogおよびGitHub上のセキュリティアドバイザリで確認できる範囲では、今回のリリースには次の4件が含まれます。すべての修正が全ブランチに入っているわけではないため、対象を併記します。

深刻度は公式アドバイザリの表記（High／中）に基づいています。CVSSスコアについては、GitHub上のセキュリティアドバイザリには数値の記載がありませんが、PHP開発チームがCNAとして登録したCVEレコードにはCVSS v4.0のスコアが入っており、NVDでも確認できます（CVE-2026-17543・CVE-2026-17544がいずれも8.1／High、CVE-2026-7260が5.4／Medium）。ただしNIST自身による評価は2026年8月1日時点で「Undergoing Analysis」の段階で、NVDのPrimaryスコアはまだ付いていません。

SQLインジェクションはなぜ起きたのか

問題があったのは、PHP内部の php_pgsql_convert() という関数です。これは pg_insert() / pg_update() / pg_select() / pg_delete() という「配列を渡すだけでSQLを組み立ててくれる便利関数」が、値を変換・エスケープするために使っています。

ここでPHPは値を E'...'（エスケープ文字列定数）で囲んでいました。ところがエスケープに使っている PQescapeStringConn() は、PostgreSQL側の設定 standard_conforming_strings = on（PostgreSQL 9.1以降の既定値）ではバックスラッシュをエスケープしません。E'...' の中ではバックスラッシュが特別扱いされるため、値の末尾にバックスラッシュを置くことで閉じ引用符を無効化し、文字列の外へ抜け出せてしまうという仕掛けです。

公式アドバイザリでは、zzz\' OR 1=1 -- のような値を渡すと WHERE "name"='zzz\'' OR 1=1 --' という形になり、条件が常に真になる例が示されています。修正では、値を包む書式をエスケープ文字列定数から通常の文字列定数へ変更しています。

自社は影響を受けるのか？

結論から言えば、次の3条件がすべて重なるアプリだけが対象です。逆に言えば、1つでも外れれば今回のSQLインジェクションは該当しません。

• データベースが PostgreSQL である（MySQL / MariaDB / SQL Server のみの環境は対象外）
• PHPの pgsql / pdo_pgsql 拡張を使っている
• コード内で pg_insert() / pg_update() / pg_select() / pg_delete() を使い、そこに利用者由来の値が渡っている

ここが実務上いちばん重要なポイントです。pg_query_params() やPDOのプリペアドステートメントで値をバインドしている、いわば「教科書どおり」の書き方をしているアプリは、今回の脆弱性の経路に乗りません。社内のPHPアプリを調べるなら、まず grep -rn "pg_insert\|pg_update\|pg_select\|pg_delete" 相当の検索でヒットするかを見るのが最短です。

なお、WordPressやその周辺プラグインはMySQL／MariaDBを前提としているため、このSQLインジェクションが直接効くことは通常ありません。ただしPhar・GD・BCMathの修正は共通なので、「PHP本体を上げなくてよい」という話にはなりません。

BCMathの脆弱性は8.4系・8.5系のみ

CVE-2026-17544は bccomp() の境界外書き込みで、細工したオペランドとscaleパラメータを渡されるとスタックまたはヒープのメモリを壊されるおそれがあります。原因は、scaleによる桁の切り詰めと末尾ゼロの削除の処理で、確保したバッファより大きなデータを小さいバッファへコピーしてしまう点にあるとされています。

対象は8.4系・8.5系のみで、8.3系・8.2系は該当しません。BCMathは任意精度計算のための拡張で、金額計算や在庫数の照合など「浮動小数点の誤差を出したくない」場面で使われます。基幹系・会計系のPHPアプリを抱えている場合は、8.4以上へ上げた環境ほど優先度が上がる、という逆転が起きうる点に注意してください。

現場目線の課題：バージョン番号だけでは判断できない

この手のニュースで毎回つまずくのが、「うちのPHPは8.2.28だから未修正だ」と単純には言えないことです。実際には次のような分岐があります。

• ディストリビューション配布のPHP（RHEL / AlmaLinux / Ubuntu など）は、バージョン番号を据え置いたまま修正だけを取り込む「バックポート」が一般的です。判断材料はphp.netのバージョンではなく、各ベンダーのセキュリティ告知（RHSA / USN など）になります。
• レンタルサーバー・共用ホスティングでは、PHPの更新タイミングは事業者次第です。自社でできるのは事業者の告知を確認することと、必要なら問い合わせることだけ、というケースも多いはずです。
• コンテナイメージは自分で追随しない限り古いまま固まります。ベースイメージの再ビルドと再デプロイまでやって、はじめて「更新した」と言えます。

そして最大の課題は、社内に「誰も管理者がいないPHPアプリ」が残っていることだと感じます。数年前に部門が自前で立てた申請フォーム、退職者が作った集計ツール、検証用のまま本番同然に使われているサーバー。脆弱性が出るたびに「これは対象か」を確認したくても、まず一覧が存在しない。CVEを追うことよりも、この棚卸しの方がよほど地味で時間がかかる作業です。

裏を返せば、今回のように「PostgreSQL＋特定関数」という明確な絞り込み条件がある脆弱性は、棚卸しの良い口実になります。全数調査は無理でも、「PostgreSQLを使っているシステムはどれか」を洗い出すところから始めれば、次回以降の判断が速くなります。

PHP 8.2系は2026年12月末でサポート終了

もう一点、カレンダー上の論点があります。php.netのサポート表によれば、PHP 8.2のセキュリティサポートは2026年12月31日で終了します。今回の8.2.33は、8.2系にとって終盤の更新のひとつということになります。

8.1以前はすでにサポート終了（EOL）です。8.2系で動いているアプリがあるなら、残り約5か月のうちに移行計画を立てる必要があります。パッチ適用は「今日の作業」ですが、バージョン移行は動作検証を伴うため「今日決めて数か月かける作業」です。両者を混ぜて後回しにしないことをおすすめします。

情シスはどうすべきか

やることは大きく2つです。①各ブランチの最新版へ更新する（あるいはディストリの更新を適用する）、②SQLインジェクションについては該当コードの有無を確認する。①は定常のパッチ運用の話ですが、②は今回に限った話ではなく、自社アプリの書き方そのものを点検する機会になります。

SQLインジェクション対策の考え方そのものは、IPAの資料が最も整理されています。自前でチェックリストを作る前に、まずこちらを参照してください。

• 安全なウェブサイトの作り方（IPA） … 第1章の冒頭がSQLインジェクション。プレースホルダ（プリペアドステートメント）の利用を根本的解決策として示しています。開発を外部委託している場合も、この資料の章立てをそのまま要件確認の観点に使えます。
• 中小企業の情報セキュリティ対策ガイドライン（IPA） … 「どのシステムを誰が管理しているか」を含む資産管理の考え方。前述の棚卸しに着手するときの土台になります。

加えて、地道ではありますがアプリの管理者を明確にしておくことが効きます。脆弱性そのものより、「誰に連絡すればそのサーバーを更新できるのか」が分からない時間の方が、実際のリスクを長引かせるからです。

まとめ

• PHP 8.5.9 / 8.4.24 / 8.3.33 / 8.2.33 が2026年7月30日に公開。目玉はpgsql拡張のSQLインジェクション（CVE-2026-17543）で、サポート中の全ブランチが対象です。
• ただし刺さるのは「PostgreSQL＋pg_insert() 等の便利関数」を使うアプリに限られます。プリペアドステートメントを使っていれば経路に乗りません。BCMathの脆弱性（CVE-2026-17544）は逆に8.4系・8.5系のみが対象です。
• バージョン番号だけで判断せず、ディストリ配布・共用ホスティング・コンテナの3系統で確認方法が異なる点に注意。あわせて2026年12月31日にサポートが切れるPHP 8.2系の移行計画も今のうちに。

関連記事

• PHPに複数の脆弱性、最新版で修正 情シスの対応点（2026年7月上旬のPHPセキュリティリリース）
• Node.jsに脆弱性11件 HTTP/2の高深刻度に注意
• ModSecurityに脆弱性、WAFの検知をすり抜ける恐れ
• クロスサイトスクリプティング（XSS）とは？仕組みと対策

出典

• PHP: ChangeLog-8（php.net）
• SQL injection in ext-pgsql via E’…’ backslash breakout（GHSA-7qpv-r5mr-78m4 / CVE-2026-17543）
• Out-of-bounds write in bccomp()（GHSA-x692-q9x7-8c3f / CVE-2026-17544）
• PHP: Supported Versions（php.net）
• 「PHP」に複数の脆弱性 – セキュリティリリースを公開（Security NEXT）
• 安全なウェブサイトの作り方（IPA）