SUSEがphp-composer2向けのセキュリティアドバイザリを公開した。修正されたのはCVE-2026-84361——悪意あるPerforceソースURLを通じて、依存解決時に任意コード実行を許してしまうという、まさに「普段は意識しない場所」を突く脆弱性だ。SUSE公式の案内どおり、zypperやYaST経由でパッチは配布済み。コンテナ運用やVagrant上の開発環境でも、ベースイメージを更新しないと古いパッケージが残ったままになるので注意が要る。
composerの「URL貼り付け」前提が崩れる
composer.jsonのrepositoriesで、Packagist以外のソースURLを直書きしているケースは意外と多い。GitHubやGitLabのカスタムURL、あるいは社内Gitリポジトリ。問題は、こうした「マイナーなVCS指定」を踏み台にされる今回の脆弱性だ。Perforceという、普段あまり触らないソース管理システムが突破口になっている点は、開発者から見ると「なぜそこから」という感覚がある。ただ、composerのソース解決ロジック的に、外部URLを信頼する構造になっている以上は、どのVCSも等しく攻撃面になる。
現実的な落とし所として、依存パッケージは Packagist公式 経由に寄せて、外部リポジトリは社内VPN越しに限定する——この運用ルールが一段重みを増した格好だ。
phar拡張のスタックオーバーフローも同時公表
同じタイミングで、PHPのphar拡張にもCVE-2026-7260が公開されている。循環シンボリックリンクを含むpharアーカイブを処理する際にスタックオーバーフローが発生し、DoSや任意のコード実行リスクがあるという。PHPのpharはComposer自身やWordPressの一部のプラグインでも使われており、composer installのたびにpharをパースする処理が走っているケースは珍しくない。Dockerfileで公式の php:8.x イメージを使っていれば、リビルド時にパッチ済みパッケージが引かれるはずだが、ベースイメージのタグを固定している場合は明示的にpullし直す必要がある。
WordPressプラグイン側も「自動レビュー」が始まった
話は少し変わるが、Make WordPressの発表も現場にとっては無視できない。WordPress.orgがプラグインリリースに対してAIとJetpack Scanによる自動セキュリティレビューを義務化、リリース直後のクールダウン期間中に高リスクと判定されたものは配布API経由でブロックされる仕組みだ。これまで「公開ボタン一発」で翌日全世界に届いていたのが、少なくともセキュリティチェック分のタイムラグを噛むことになる。
個人開発者としては、リリース前の検証フローに「WordPress.org側の自動判定を意識したメタデータと差分の確認」を組み込む必要が出てきた。「公開して終わり」という週末デプロイの感覚は、ここから少しずつ崩れていく。
今夜やっておくこと
composer self-updateと、ベースイメージ・パッケージマネージャ経由のcomposer2更新を確認- カスタムVCSリポジトリをrepositoriesに書いていないか棚卸し
- WordPressプラグインを公開しているなら、リリース手順とメタ情報のチェック工程を見直し
結局のところ、今回の脆弱性は「普段触らない場所」ほど被害が広がるという、典型的なサプライチェーンのパターンだ。運用でカバーする部分と、コード／イメージで解決する部分の線引きを、今夜のうちに見直しておきたい。
関連記事: WordPressプラグインの脆弱性を突く44万件の攻撃：サイト乗っ取りを防ぐ対策 、 Over 3 Million WordPress Sites Affected.