OpenMage Magento LTSに脆弱性3件、修正版が公開
OpenMage Magento LTSで、APIトークンの奪取、顧客アカウントへの不正ログイン、サーバー上のコード実行につながる脆弱性3件が公表されました。ECサイトの運用者は修正版へ更新し、OAuth連携の設定も確認してください。
同じ発表の脆弱性 3 件
この記事でまとめた分です。発表元の告知には、ほかの脆弱性も載っていることがあります。
- CVE-2026-128049 重大 9.4
- CVE-2026-128047 高 9.2
- CVE-2026-128046 高 9.2
急ぎ度: 早めに
悪用の確認は示されていませんが、最大でCVSS v3が9.0のcriticalを含み、うち2件は認証なしで届く脆弱性で、修正版がすでに出ているためです。
関係があるか
OpenMage Magento LTSでECサイトを運用している組織が対象です。REST APIや外部システムとのOAuth連携を使っているサイトは、とくにCVE-2026-128049の影響を受けやすくなります。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| OpenMage Magento LTS 20.x系（Composerパッケージ openmage/magento-lts） | 20.18.2より前。CVE-2026-128046は20.17.0以降20.18.2より前が対象 | 20.18.2、20.19.0 |
| OpenMage Magento LTS 21.0.0系プレリリース | 21.0.0-beta1以上21.0.0-beta3未満 | 21.0.0-beta3 |
確かめ方
- 1Composerで導入している場合は、
composer show openmage/magento-ltsで版を確認します。Composerを使っていない場合は、デプロイ済みのコードの版を管理担当者に確認してください。 - 2管理画面のSystem › Web Services › REST - OAuth Consumersを開き、登録済みのコンシューマーと、実際にREST APIを使っているかを確認します。
- 3テーマがoauth/authorize/button.phtmlやbutton-simple.phtmlを上書きしていないかを、adminhtmlとfrontendの両方で調べます。
- 4Webサーバーの設定で、.pharをPHPとして実行する設定になっていないか、media/custom_options配下を外部に配信していないかを確認します。
何が起きたか
OpenMage Magento LTSに、REST APIの権限、顧客アカウント、サーバー上のコード実行に関わる3件の脆弱性が同時に公表されました。悪用されると、管理者や顧客に成り代わったAPI操作、顧客アカウントの乗っ取り、サーバーでの任意のコード実行が起こり得ます。いずれも修正版が出ています。
- CVE-2026-128049: OAuth認可の確認処理にCSRF対策がなく、管理者や顧客が細工したURLを開くと、攻撃者に永続的なREST APIトークンを渡してしまいます（CVSS v3は9.0、v4は9.4）
- CVE-2026-128047: 顧客のメール確認キーとパスワードリセットのトークンが推測されやすい作りで、顧客アカウントへのログインや管理者のリセットトークンの予測につながります（CVSS v3は8.1、v4は9.2）
- CVE-2026-128046: アップロードを禁じる拡張子の一覧にphar・php8・phpsが入っておらず、サーバー上でコードが実行される恐れがあります（CVSS v3は8.1、v4は9.2）
原因の分類は、CVE-2026-128049がCWE-352（CSRF）、CVE-2026-128047がCWE-330（乱数の質が不十分）、CVE-2026-128046がCWE-184（禁止リストの不備）です。
認証なしで届く2件が公開側のECサイトにあることを考えると、筆者は管理画面のアクセス制限だけに頼らず、早めに修正版へ更新するのが妥当だと見ています。
攻撃の流れ
-
1
サイトへ到達
CVE-2026-128047と128046は認証なしでサイトに要求を送り、CVE-2026-128049は管理者や顧客に細工したURLを開かせます。
-
2
処理の不備を突く
OAuth承認のCSRF、確認キーの推測、拡張子の禁止リストの漏れのいずれかを利用します。
-
3
権限を得る
永続的なAPIトークン、顧客アカウントへのログイン、サーバー上のコード実行のいずれかに至ります。
-
4
データを操作
顧客・注文・商品・在庫などのデータの読み取りや変更が可能になります。
どう悪用されるか
3件で条件が異なります。CVE-2026-128049は、OAuthコンシューマーの資格情報を持つ攻撃者が、ログイン中の管理者や顧客に細工したURLを開かせる必要があり、利用者の操作が前提です。ネットワーク越しに仕掛けられますが、攻撃者に管理者アカウントまでは要りません。連携事業者に近い権限のコンシューマー資格情報があれば足ります。
CVE-2026-128047とCVE-2026-128046は、認証なしでネットワーク越しに届き、利用者の操作も不要です。CVE-2026-128047では、保留中の顧客アカウントのメール確認キー（約20ビット）を、回数制限のない確認用エンドポイントで総当たりされます。管理者のリセットトークンは、乱数生成器の状態を復元されたうえで予測されます。CVE-2026-128046は、商品のFileカスタムオプションからのアップロードが入口です。.pharをPHPとして扱い、そのディレクトリを配信しているサーバーでコードが実行されます。
CVE-2026-128049で奪われたトークンは、トークンかコンシューマーが取り消されるまで有効です。管理者のトークンが役に立つのは、その管理者にRESTロールが割り当てられている場合に限られ、ロールが許す範囲で顧客・注文・商品・在庫データの読み取りや変更ができます。顧客のトークンも同様に奪われます。CVE-2026-128047では保留中の顧客としてログインされ、CVE-2026-128046ではサーバー上でコードを実行されます。
今すぐやること
-
1
修正版に更新する
20.x系は修正版の20.18.2または20.19.0へ、21.0.0系プレリリースは21.0.0-beta3へ更新します。更新前に現在の版を確認しておくと、対象かどうかを判断できます。
composer show openmage/magento-lts -
2
テーマの上書きテンプレートを直す
修正版では、OAuth承認の確認がGETではなくPOSTとフォームキーの検証を要求し、GETは404を返します。テーマでbutton.phtmlかbutton-simple.phtmlを上書きしている場合は、method="post" で送信し、
<?php echo $this->getBlockHtml('formkey') ?>を含めるように直します。直さないとそのテーマでOAuth承認が動かなくなります。 -
3
OAuth連携とトークンを棚卸しする
System › Web ServicesのREST - OAuth ConsumersとREST - OAuth Authorized Tokensで、発行済みのトークンと登録済みコンシューマーを確認します。信頼できないものは取り消してください。管理者のREST - My Appsや、顧客アカウントのMy Applicationsも見ます。
-
4
侵害の跡を調べる
更新前から運用しているサイトでは、確認用エンドポイントへの大量のアクセス、見覚えのない管理者のリセット操作、media/custom_options配下の想定外のファイルをログとファイルで確認します。修正版に更新しても、すでに置かれたファイルは残ります。
-
5
ベンダーの告知を確認する
OpenMageのGitHubにあるセキュリティ勧告とリリースノートで、更新する版にCVE-2026-128047とCVE-2026-128046の修正が含まれることを確認します。
すぐ更新できないとき
すぐに更新できないときは、CVE-2026-128049について次の対策でリスクを下げられます。
- REST APIを使っていなければ、OAuthコンシューマーをすべて削除するか無効にする（System › Web Services › REST - OAuth Consumers）
- 信頼しきれないコンシューマーを取り消し、発行済みトークンを見直す
- API利用が不要な管理者アカウントにRESTロールを割り当てない
- 管理画面のURLをIPアドレスの許可リストやVPNで制限する
CVE-2026-128047とCVE-2026-128046には、同じ種類の回避策は示されていません。この2件は修正版への更新が確実な対処です。
背景
OpenMage Magento LTSは、Adobeが2020年6月にMagento 1のサポートを終えたあとも、コミュニティが保守を続けているECプラットフォームです。受注・顧客・商品・在庫を一つの基盤で扱い、REST APIで基幹システムや在庫管理、外部の連携サービスとつながります。そのため、APIトークンや管理者・顧客のアカウントが奪われると、店舗のデータ全体に影響が及びます。
今回の3件は、OAuth 1.0aの承認が、フォームキーによるCSRF対策のないGETで完了していたこと、乱数ではなくuniqidやuniqHashを元に確認キーとリセットトークンを作っていたこと、アップロードを禁じる拡張子を列挙する禁止リスト方式で、phar・php8・phpsが漏れていたことが原因です。いずれもこのプロジェクトの仕組みに固有の設計上の抜けで、修正はPOSTとフォームキーの必須化など、個別の処理に入っています。
よくある質問
Q.Magento 2やAdobe Commerceも影響を受けますか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| パッケージ | 影響を受ける版 → 修正版 | |
|---|---|---|
| OpenMagemagento-lts |
21.0.0-beta1 以上 21.0.0-beta3 未満→ 21.0.0-beta3 |
21.0.0-beta3 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
OpenMage Magento LTS before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 contains a cross-site request forgery vulnerability in the admin and storefront OAuth confirm and confirmSimple actions, which accept GET requests without form-key validation. Attackers holding OAuth consumer credentials can lure a logged-in administrator or customer to a crafted confirm URL that authorizes the attacker's request token, then exchange it at /oauth/token for a persistent REST API access token bound to the victim.
出典: CVE.org (CVE Program・cvelistV5) NVD