mews/posで決済結果の偽装リスク｜InterPosは修正範囲を別に確認

PHPの決済連携ライブラリーmews/posに、コールバックの真正性を十分に検証せず、支払い結果を偽装されるおそれがあるCVE-2026-118377が登録されました。GarantiPos、PayForPos、InterPosの3D Pay／3D Host関連処理が対象です。利用者は版数だけでなく、実際に使うゲートウェイと決済モデル、修正の取り込み範囲を照合してください。

特に注意したいのは、公式PRがマージ済みでも、InterPos向けの変更は取り込み時に除外され、別Issueに残っていることです。この記事は2026年10月28日に公式CVE、開発元のPR・差分・Issue・リリースを確認した脆弱性解説です。以下の点検と試験は本サイトの提案であり、実決済で攻撃を再現した結果ではありません。

支払い成功の項目が届くだけでは正当な決済といえない

CVE Programの公式レコードは、mews/pos 2.0.0以前について、未認証の攻撃者が未検証のコールバックを送信し、支払い結果を偽装できると説明しています。問題はcheck3DHash()の呼び出しが欠ける経路で、金額、状態、注文IDなどが改変されたまま扱われるおそれがあることです。

想定される主な影響は決済結果の完全性です。単なる画面表示の誤りにとどまらず、自社システムが受信結果を根拠に注文を支払い済みにすれば、未入金のまま商品出荷や会員権限の付与へ進む可能性があります。後半はそのような業務連携がある場合の本サイトの分析で、すべての導入先で同じ処理が動くという意味ではありません。

公式CVEのCVSS v3.1は7.5、深刻度はHighです。同じレコードにはCVSS v4.0の8.7も記載されています。版の違う評価を比較せず、本記事の構造化メタにはv3.1の値を使います。CNAのdatePublicは10月25日、CVEレコード公開は10月28日です。CVE登録日を修正公開日や被害発生日と読み替えません。

ゲートウェイと決済モデルを組み合わせて確認する

開発元の修正PR #305の説明では、GarantiPosのmake3DPayPayment()、PayForPosとInterPosのmake3DPayPayment()・make3DHostPayment()が挙げられています。同じライブラリー内でも、3D Secureモデルのmake3DPayment()や別ゲートウェイの処理と、今回の経路を一括りにしないことが重要です。

経路	確認した修正状況
GarantiPosの3D Pay	マージされた差分にハッシュ検証を追加
PayForPosの3D Pay／3D Host	マージされた差分にハッシュ検証を追加
InterPosの3D Pay／3D Host	PRから変更を除外しIssue #306で継続

まず、設定ファイルやファクトリーが生成するクラスと、コールバックを受け取った後に呼ぶ決済モデルを記録します。クレジットカード決済を提供しているという情報だけでは対象経路を特定できません。使っていないサンプルコードや、過去に停止した連携設定と、現在の本番経路を分けてください。

マージされたコードは二つのゲートウェイを修正

10月25日にマージされたコミット7c59d42の実際の差分では、GarantiPosとPayForPosの対象メソッドで、応答のマッピングより前にハッシュを検証しています。検証を無効にしておらずcheck3DHash()が失敗した場合、HashMismatchExceptionを投げる流れです。拒否してから業務用の応答へ変換する順序が確認できます。

同じ差分には、検証成功時のケースに加え、ハッシュ不一致なら例外となり、応答のマッピングを呼ばないことを確かめるユニットテストも追加されています。テストが存在することと、自社のコールバックから注文更新までが安全に接続されていることは別です。例外を捕捉した後のアプリケーション側の処理も確認します。

また、検証を無効にする条件分岐が残るため、コードを取り込んだだけで検証が必ず動くとは限りません。自社の設定やラッパーがis3DHashCheckDisabled()にどの値を返させるかを追い、検証失敗を回避する目的で無効化していないことを確認してください。未知の設定キーを推測して追加する方法は避けます。

InterPosは別Issueの解決を確認するまで分けて扱う

PR内の履歴では、保守者が試験用APIの認証情報を持たず動作を確かめられないため、InterPosのハッシュチェックを取り除いたと説明しています。10月28日の確認時点で、InterPosのIssue #306はOpenでした。PR冒頭の対象一覧だけを読み、InterPosも同じ差分で修正済みと判断してはいけません。

差分にはInterPosCryptのテストデータも含まれますが、それだけでInterPosのゲートウェイ処理へ検証が組み込まれた証明にはなりません。暗号処理の関数を試すこと、コールバック経路がその関数を呼ぶこと、注文更新が拒否を尊重することは、別々に確かめる必要があります。

InterPosの対象経路を使っていて安全な代替を確認できない場合、本サイトはその経路の自動的な支払い確定・出荷を止め、決済提供元での取引確認を伴う保留運用を検討することを提案します。単に成功画面のリンクを隠す対処では、受信URLを使う処理は止まりません。停止範囲と業務への影響を運用担当者と決めてください。

Composerの版と実際の参照コミットを照合する

確認した開発元のReleases一覧では、Latestは2.0.0です。これを今回の修正済みタグとして案内することはできません。新しい修正版番号を推測せず、提供された配布物に対象の変更が含まれるかを確認します。開発ブランチを本番へ無条件に切り替えるのではなく、自社の採用手順で固定・レビュー・試験を行ってください。

composer show mews/pos
composer show --locked mews/pos
composer depends mews/pos --tree

Composer公式のコマンド資料に基づく確認例です。showでインストール済みの情報、--locked付きでcomposer.lockの情報、dependsで導入経路を調べます。出力に現れるsourceやdistの参照値と、実際の配布物を対応付けます。この記事の例は依存関係の調査用で、本番で更新を実行するコマンドではありません。

composer.jsonの制約だけ変更しても、lockファイルや配備済みvendorが古いままなら反映されません。アプリ本体、決済用ワーカー、別環境の受信口について、実行する成果物と参照値を記録します。独自パッチがある場合も、ファイルの変更理由と適用先を残し、次回のビルドで消えないことを確認してください。

ハッシュ不一致を支払い成功へ変換しない

アプリ側では、HashMismatchExceptionなどの検証失敗から、支払い済みへの状態変更、出荷ジョブ、特典付与へ進まないことを確認します。広い例外処理がエラーを握りつぶして既定の成功値を返したり、受信パラメーターの成功表示を優先したりすれば、ライブラリー側の拒否を業務へ反映できません。

次の流れは、今回の点検で使う本サイトの設計例です。銀行ごとのハッシュ生成式を再実装する手順ではありません。暗号処理は対応する公式実装を使い、注文との照合と状態変更をその後に置きます。

受信 → 対応ゲートウェイの真正性検証
     → 自社の注文・金額・通貨・取引との照合
     → 未処理の正当な状態遷移だけ確定
検証失敗 → 注文を成功へ更新せず保留・記録

正しいハッシュでも、別注文、別環境、別加盟店の通知を自社の対象として処理してよいとは限りません。自社で保存した注文と決済の対応を使って確認し、コールバックから届いた注文IDや金額だけで更新対象と正解値の双方を決めないようにします。金額の単位や通貨の表記は、利用するゲートウェイの仕様へ合わせます。

検証環境では拒否と業務状態の両方を試す

試験は、自社が管理する検証環境と決済提供元のテスト手段で行います。正規のコールバックで正常な処理が通ることと、必要な検証が失敗した場合に注文が変わらないことを対にします。実運用の注文を架空の成功通知で更新する試験は行わないでください。

ケースとして、正規の値、ハッシュがない値、不一致の値、注文照合が失敗する値、同じ正規通知の再受信を分けます。各ゲートウェイで署名対象が異なるため、任意の一項目を書き換えれば必ずハッシュ不一致になると一般化しません。真正性検証と自社の業務照合のどちらで拒否されるべきかを決めます。

確認結果は、ライブラリーの参照値、ゲートウェイクラス、決済モデル、検証無効化の状態、例外、注文の変更有無、出荷ジョブの有無を一組で残します。単体テストで例外を確認した結果を、外部決済との結合試験の実測と呼ばないことも大切です。

過去の支払い確定と提供元の記録を突き合わせる

対象経路を使っていた期間については、自社の支払い済み記録と決済提供元の取引記録を照合します。通知を受けた時刻だけでなく、注文、金額、通貨、取引状態が対応するかを確認してください。不一致は未払いだけでなく、取消、返金、処理遅延の可能性もあるため、直ちに攻撃と決めつけません。

ログにはコールバックの受付、検証結果、相関ID、業務状態の遷移を残し、カード情報や秘密鍵・共有秘密を丸ごと保存しないようにします。過去のログがなければ、その期間まで安全だったと証明できるわけではありません。確認できた期間と証拠、未照合の注文を明示し、決済運用担当へ引き継ぎます。

今回の対応は、依存版を上げる一作業では終わりません。利用経路を特定し、取り込まれた修正と未解決のInterPosを分け、検証失敗時に注文が確定しないことを確認する必要があります。修正コード、配布物、本番の経路、業務記録の四つを結び付けて完了を判断してください。

関連記事

WebhookからAIを動かす前の署名検証・再送・順序の安全対策では、Stripeを例に受信後の重複や順序を扱っています。署名方式は提供元ごとに異なるため、その実装をmews/posへ流用する手順ではありません。