対象CVE: CVE-2026-48527

[技術解説] HaxCMSにおける保存型XSS脆弱性 (CVE-2026-48527) とフロントエンドでの対策

HaxCMSのページ編集機能に保存型XSSの脆弱性が見つかりました。HTMLサニタイザーの不備を悪用し、ページ編集権限を持つユーザーが悪意あるスクリプトを埋め込むことで、特権ユーザーの情報を窃取したりアカウントを乗っ取ったりするリスクがあります。フロントエンドエンジニアとして、この脆弱性の詳細と取るべき対策を解説します。

はじめに：HaxCMSのXSS脆弱性概要

日本のフロントエンドエンジニアの皆さん、こんにちは。今回は、コンテンツ管理システム (CMS) の一つであるHaxCMSで発見された、深刻度「高 (High)」の保存型クロスサイトスクリプティング（XSS）脆弱性 (GHSA-g2g8-95qg-v35h / CVE-2026-48527) について解説します。この脆弱性は、特にユーザー生成コンテンツを扱うWebアプリケーション開発において、フロントエンドのセキュリティ対策がいかに重要であるかを再認識させてくれる事例です。

脆弱性の詳細：サニタイザーをすり抜けるメカニズム

この脆弱性は、HaxCMSのページ保存機能 (`/system/api/saveNode` エンドポイント) に存在します。Webアプリケーションでは、ユーザーが入力したHTMLコンテンツをそのまま表示するとXSSのリスクがあるため、「HTMLサニタイザー」を用いて危険なタグや属性を除去するのが一般的です。しかし、HaxCMSのサニタイザーには不備があり、特定の形式で記述された悪意のあるHTMLを検出できずに保存してしまう問題がありました。

具体的には、`onclick` のようなイベントハンドラー属性の直前に空白文字を入れない特殊な書き方、例えば `<a href="#"onclick="alert('XSS')">` のように記述された場合、サニタイザーがこの属性を悪意あるものとして認識せず、すり抜けてしまいます。これは、サニタイザーが正規表現などを用いてHTMLをチェックする際に、空白文字の存在を前提としたパターンを使用していたことが原因と推測されます。

このすり抜けられた悪意のあるHTMLは、HaxCMSによって生成される静的なページファイル（例: `index.html`）にそのまま埋め込まれてしまいます。その結果、ページを閲覧したユーザーのブラウザ上で、攻撃者の意図したJavaScriptコードが実行されてしまうことになります。

影響と潜在的なリスク：フロントエンドが脅かされるシナリオ

この脆弱性の最も深刻な点は、ページ編集権限を持つ認証済みユーザー（管理者や特定の編集者）が悪意のあるHTMLを意図的、または不注意でページに挿入した場合に発生することです。一度ページにスクリプトが埋め込まれてしまえば、そのページを閲覧した他のユーザーに影響が及びます。

特に危険なのは、管理者などの特権ユーザーが悪意のあるリンクや要素をウェブページ上でクリックしてしまうケースです。これにより、攻撃者によって仕込まれたJavaScriptコードがその特権ユーザーのブラウザ上で実行されてしまいます。実行されたJavaScriptは、以下のような機密情報へのアクセスや不正な操作を可能にします。

<ul><li>ブラウザに保存されている認証情報（例: `localStorage.jwt`）の窃取</li><li>HaxCMSの設定情報やAPIトークン（例: `window.appSettings`）へのアクセス</li><li>被害者の権限を悪用した（例: アカウントの乗っ取り）システム内での不正な操作</li><li>他の脆弱性と組み合わされることによる、さらに深刻な攻撃への発展</li></ul>

このように、一見サーバーサイドの問題に見えるXSSも、最終的にはフロントエンドでスクリプトが実行されることで、ユーザー体験を損ない、機密情報漏洩やアカウント乗っ取りといった甚大な被害をもたらす可能性があります。

フロントエンドエンジニアが取るべき対策

今回のHaxCMSの事例は、フロントエンド開発者がセキュリティを意識したコーディングを行うことの重要性を示しています。以下に、私たちが取るべき対策を挙げます。

ユーザーからの入力をHTMLとして表示する際には、必ず信頼できるサニタイズライブラリやフレームワークのセキュリティ機能を活用し、適切なHTMLサニタイズとエスケープ処理を施してください。自作のサニタイザーは脆弱性が混入しやすいため、避けるべきです。著名なライブラリとしては、<a href="https://github.com/cure53/DOMPurify" target="_blank">DOMPurify</a>や<a href="https://github.com/apostrophecms/sanitize-html" target="_blank">sanitize-html</a>などがあります。

特に、HTML属性値にユーザー入力を含める際は、属性値のエスケープが不可欠です。例えば、`&`を`&`に、`"`を`"`に変換するといった処理が必要です。ReactやVue.jsのようなモダンなフレームワークは、デフォルトでテキストコンテンツをエスケープしますが、`dangerouslySetInnerHTML`（React）や`v-html`（Vue.js）を使用する際は、必ずサニタイズ処理を施した上で使用してください。

コードレビューの際に、ユーザー入力がどのように処理され、どこでHTMLとしてレンダリングされるかに特に注意を払いましょう。以下の点を確認してください。

<ul><li>ユーザー入力が直接DOMに挿入されていないか？</li><li>HTML属性値にユーザー入力がエスケープされずに使用されていないか？</li><li>`eval()` や `new Function()` など、文字列をコードとして実行する機能の不適切な利用がないか？</li><li>サニタイザーやエスケープ処理が常に適用されているか？また、それが適切な場所とタイミングで実行されているか？</li></ul>

CMSや利用しているフレームワーク、ライブラリのセキュリティアップデートは、迅速に適用することが重要です。また、GitHub Security AdvisoriesやNVD（National Vulnerability Database）などのセキュリティ情報を定期的にチェックし、利用している依存関係に脆弱性がないか常にアンテナを張っておきましょう。今回のような「古い正規表現パターン」に起因する脆弱性は、往々にして既存のライブラリやコードに潜んでいる可能性があります。

まとめ

HaxCMSのXSS脆弱性は、ユーザー生成コンテンツを扱うすべてのWebアプリケーションにとって他人事ではありません。フロントエンドエンジニアは、単に見た目を実装するだけでなく、セキュリティの最後の砦として、ユーザー入力の適切な処理と堅牢な防御メカニズムの構築に責任を持つ必要があります。この事例を教訓に、より安全なWebアプリケーション開発を心がけましょう。