PHP開発チームは、コアエクステンションに影響を及ぼす3件のセキュリティ脆弱性を公表しました。修正はPHP 8.2.33、8.3.33、8.4.24、8.5.9で提供されています。
これらの欠陥は、SQLインジェクション、制御不能な再帰処理、そして境界外メモリへの書き込みにまで及び、ext-pgsql、ext-phar、ext-bcmathに依存するアプリケーションに影響します。
セキュリティ研究者のiluuu1994氏が、GitHub Security Advisoriesにて3件すべての勧告を公開しました。3件のうち最も深刻度が高い（High評価）のはCVE-2026-17543で、php_pgsql_convert()におけるSQLインジェクションの脆弱性です。
この関数はpg_insert()、pg_update()、pg_select()、pg_delete()の基盤となっており、php_pgsql_add_quotes()を通じてPostgreSQLのエスケープ文字列定数（E'...'）で囲む前に、PQescapeStringConn()を使って入力をサニタイズしています。
問題は、PostgreSQLのバージョン9.1以降デフォルトで有効になっているstandard_conforming_stringsが有効な状態では、PQescapeStringConn()がバックスラッシュ文字をエスケープしない点にあります。
E'...'構文はバックスラッシュをエスケープ文字として扱うため、攻撃者はzzz\' OR 1=1 --のような値を渡すことができます。これにより、エスケープされた単一引用符がリテラルとして扱われる一方、2つ目の引用符が文字列を早期に終端させ、ペイロードの残りの部分がSQLパーサーにさらされてしまいます。
細工したpg_select()呼び出しにより、クエリの完全なバイパスが実証されており、本来意図したフィルター条件に関係なくすべての行が返される結果となりました。この修正では、php_pgsql_convert()がエスケープを行わない文字列定数を使用するように変更されています。
中程度（Moderate）と評価されたCVE-2026-7260は、ext-pharに影響します。util.c内の関数phar_get_link_source()は、深さ制限や循環検出を行わずに、pharアーカイブ内のシンボリックリンクを再帰的に解決します。
攻撃者は、互いを指し合う2つのシンボリックリンクを含むtarベースのpharアーカイブを細工することで、エントリの内容にアクセスした瞬間（例えばgetContent()経由）に無限再帰を引き起こすことが可能です。
これによりCのコールスタックが枯渇し、PHPプロセスがクラッシュします。これはサービス拒否（DoS）状態（CWE-400、CWE-674）であり、悪用にはローカルアクセスとユーザーの操作が必要ですが、特権は不要です。
CVSSベクター（AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H）は、可用性への影響が大きい一方、機密性・完全性への影響がないことを示しています。同じくHigh評価のCVE-2026-17544は、ext-bcmath内のbc_str2num()における切り捨てバグに起因します。
bccomp()が、小数の位取り（スケール）が切り捨てられ、その後末尾のゼロがトリムされるオペランドを処理する際、コードはstr_scaleを再計算するものの、対応するfractional_endポインタの調整を行いません。
この不整合により、bc_copy_and_toggle_bcd()が、切り捨てられていない文字列を、容量不足のバッファにコピーしてしまいます。
BCMathはスタック上に確保したアリーナを使用し、それを使い切った場合にヒープ割り当てにフォールバックする仕組みのため、割り当ての状況によってスタックまたはヒープのいずれかのメモリが破損する可能性があります（CWE-121、CWE-787）。パッチでは、ゼロのトリム後にfractional_end = fractional_new_end;を再代入するだけの単純な修正が行われています。
これら3件の脆弱性はいずれも、PHP 8.2.33、8.3.33、8.4.24、8.5.9より前のバージョンに影響します（PharおよびBCMathの問題は8.4以降が対象です）。PostgreSQLと連携するPHPアプリケーションや、任意精度演算を行う組織は注意が必要です。
信頼できないPharアーカイブを扱う処理については、速やかなアップグレードを最優先すべきです。特に、SQLインジェクションの欠陥はデータ流出につながる可能性があり、メモリ破損バグにも悪用の余地がある点を踏まえる必要があります。
SOC調査の死角を減らし、ANY.RUNで脅威をより早期に封じ込めることで、対応コストと業務への影響を削減しましょう。
翻訳元: https://cyberpress.org/critical-php-vulnerabilities/
