この記事のポイント
- 脆弱性
- CVE-2026-44267
- 深刻度
CRITICAL9.8
- 対象
- npmパッケージ @enspirit/elo 1.0.0以前
- 悪用状況
- 不明
- 推奨対応
- 1.0.1以上へ更新し、配備に反映されたことを確認してください。
- 公表日
目次
Eloを使って利用者の入力をJavaScriptへ変換し、その結果を実行しているWebアプリやでは、の @enspirit/elo を1.0.1以上へ更新してください。-2026-44267は、細工されたElo式がJavaScriptの実行環境に到達できる問題です。サーバーではのプロセス、ブラウザーでは式を評価したページの権限が影響を受けます。更新したを使って、実行中のサービス、CIの実行環境、配信中のブラウザー用ファイルをそれぞれ入れ替えることが重要です。
Enspiritの公式勧告 GHSA-33r5-xmm8-v6x5は2026年10月30日公表で、影響版を1.0.0以前、修正版を1.0.1以上としています。提供元の評価はCritical、 v3.1で9.8です。勧告にはコード実行の実証が掲載されています。実証の成功は第三者が実環境を侵害したという報告とは別です。本稿は開発元の勧告と修正差分を確認したニュースで、以下の棚卸しや運用確認は本サイトからの提案です。
スポンサーリンク
式を受け取るところから実行するところまで調べる
Eloはルールや設定などを記述する式言語です。画面に入力欄がある場合だけでなく、保存済みのルールを読み込んで評価する構成でも、誰がその式を登録・更新できるかが問題になります。たとえば管理者向けのバッチが評価を担当していても、式自体を一般利用者がフォームやインポートで登録できるなら、管理者だけが入力を支配しているとは言えません。の要否、式の編集権限、評価処理を実行する権限を分けて記録してください。
開発元によれば、影響版はJavaScriptの特殊なプロパティ名を通常のメンバー名として受け付け、生成したコードへ引き継ぎます。その結果、式からホストの関数生成機構に到達できます。式の構文として受理されたことや、Eloの型検査を通過したことは、ホストの機能から隔離されたことを意味しません。ライブラリをインストールしただけで直ちにが成立するわけではなく、外部の入力が問題の処理へ到達する構成かどうかを調べます。
棚卸しでは、最初に単位の依存関係を確認します。npmを使う構成なら、サーバーとの各ワークスペースで npm ls @enspirit/elo --all を実行し、直接依存と間接依存を区別します。別のパッケージ管理ツールを使う場合は、その依存関係表示機能とを照合します。開発端末で依存が見つからなくても、独立したCIイメージや配信済みバンドルに同じ判定を広げないでください。
次に、式の作成、保存、読み込み、変換、評価の順にコードを追います。検索の起点はパッケージ名に加え、勧告が挙げる defaultFormats.elo.parse()、bin/elo、JavaScriptの出力を評価する処理です。直接呼び出していない場合は、社内ラッパーやサードパーティーのルールエンジンが中継していないかを確かめます。評価が即時か非同期か、登録時と実行時で権限が異なるかまで把握すると、どのサービスから停止・更新するべきかを決めやすくなります。
サーバーとCIとブラウザーでは影響の見方が違う
サーバーで defaultFormats.elo.parse() を通じて式を処理する場合は、実行するNode.jsプロセスを特定します。公開フォームやAPIから式を渡せる構成なら、到達するリクエスト経路の制限を優先します。ログイン後だけ編集できる構成でも、通常利用者がサーバーの権限で式を実行できるとすれば問題は残ります。登録を受け付けるAPIを止めるだけで、すでに保存済みの式を処理するワーカーや予約ジョブまで停止するとは限りません。
CIでは、開発元は bin/elo へ式ファイルを渡す経路に加え、Eloをデータの形式として指定する経路でも実証しています。ワークフローにの呼び出しがあれば、入力ファイルの出所を確認してください。外部のプルリクエストから来るファイルと、保護されたの設定を同列に扱わないようにします。実行環境の影響を見積もる際は、ジョブへ渡る資格情報、書き込み可能な成果物、ランナーが接続できるサービスを確認します。ジョブに渡していないまで流出したと推定する材料にはなりません。
ブラウザーについて勧告が具体的に示したのは、Eloの公開プレイグラウンドで、リンクに含まれる式が自動評価される例です。影響するのは式が実行されたページのです。自社の実装に同じURLパラメーターがあるとは限りませんが、クエリー文字列から式を復元する機能、共有されたルールのプレビュー、ページ読み込み直後の自動評価があれば確認してください。サーバーでの任意コード実行と、ブラウザー内でのスクリプト実行は、調査対象のデータやログが異なります。
運用台帳には、入力を供給できる人、評価が動く場所、実行主体がアクセスできるものを一行ずつ残すと役立ちます。仮に、同じ式を保存時はブラウザーでプレビューし、毎晩サーバーでも評価する設計なら、ブラウザー用バンドルだけを更新しても夜間ジョブは残ります。逆に、の更新だけを確認して画面側の旧ファイルを見落とすこともあります。パッケージ名が一つでも、更新と検証の対象は実行経路ごとに分けてください。
スポンサーリンク
修正はJavaScriptを生成する前の変換段階に入る
Enspiritの修正コミット 2136da1では、構文を中間表現へ変換する段階で constructor、prototype、__proto__ などの特定のメンバー名を拒否します。実行直前に文字列を置き換える変更ではなく、該当するメンバーアクセスを変換時にエラーとする修正です。公式勧告は、構文木を直接受け取る別の注入問題とは前提が違い、今回の問題は通常の式文字列でも成立すると説明しています。構文木を外部に公開していないことだけで対象から外さないでください。
更新先はプロジェクトの互換性を確認した上で、少なくとも1.0.1を含む版とします。ルートの依存だけを変更したとき、別ワークスペースや間接依存に旧版が残る場合があります。ロックファイルで解決済みの版を確認し、そのロックファイルを使って作られた成果物を配備します。間接依存の場合はまず親パッケージの更新を検討し、依存の上書きが必要なときは親パッケージが要求する互換性を検証してから使います。
更新をすぐに適用できない場合は、利用者が編集できる式の評価や、外部から受け取ったファイルを評価するCIジョブを一時停止することを検討してください。公開のプレビューに自動評価がある場合は、その経路も止めます。入口で特定の文字列を弾く措置は、別経路を見落とす可能性があるため恒久修正として扱いません。復旧時には、機能を止めたままの経路と、修正版で再開する経路を運用記録に分けて残します。
更新完了は稼働中の成果物と正常系の両方で判定する
Node.jsサービスでは、ロックファイルの差分と、実際に動いているイメージやリリースの識別子を照合します。カナリア配備で確認が取れても、旧レプリカやキューのワーカーが残っていれば全体の反映は完了していません。定期ジョブが独立したイメージを参照していないか、最後に起動したジョブが更新後の定義を使っているかも確認対象です。イメージを更新しても、以前の依存を復元するCIが使われるなら、実行ログと依存一覧で結果を確かめます。
ブラウザー向けには、生成済みバンドルを再し、HTMLが新しいファイルを参照することを確かめます。やサービスワーカーで以前のファイルを配信できる設計なら、キャッシュ更新後に通常のアクセス経路から配備を確認します。アプリで長時間開いたままの画面を想定している場合は、再読み込みやの更新を促す必要があるかを判断してください。開発端末の新規ウィンドウだけで動作を見て、利用中の古い画面まで切り替わったとみなさないようにします。
回帰テストには正常なプロパティ参照と、修正で禁止された名前への単純な参照を用意します。後者は実行可能な攻撃コードを必要としません。隔離したで、アプリの入口から対象の式を渡したときに評価されず、期待したエラー処理へ進むことを確認します。直接ライブラリを呼ぶテストだけでなく、保存済みルールの再評価やインポートのプレビューも、運用で使うなら対象に含めます。正常なルールは修正前後で結果を比較し、既存ルールが禁止名をデータ項目として使っていれば、項目の改名やルールの移行を検討します。
検証時に拒否を確認できない場合は、まず実際に読み込んだパッケージが更新されているか、次にエラーをラッパーが握りつぶしていないかを切り分けます。画面にエラーが見えない場合も、監視側で変換失敗を追える設計かを確認します。一方で、ログに式の全文を出すと利用者の入力や業務上のルールが残ることがあります。ルールの識別子、実行した処理、エラーの分類、配備の識別子で追跡できるようにする方法があります。
スポンサーリンク
旧版を公開していた期間は更新と別に調べる
影響版で利用者入力を評価していた期間があれば、修正と並行して、式の登録・変更履歴と実行の記録を突き合わせます。最初に確認するのは、いつから該当版が動いていたか、どの評価経路が公開されていたか、保存した式を誰が変更できたかです。既存ルールは再評価せず、監査用に扱える形で保存してから調べます。現在のファイルだけでは過去に一時登録され削除された式を確認できないため、履歴の保持期間も調査記録に含めます。
サーバーとCIで不審な評価が見つかった場合は、関連時刻のプロセス起動、外部接続、ファイル変更、成果物の発行を確認します。疑いのあるプロセスやジョブが使えた資格情報を洗い出し、露出が疑われるものは利用記録を確認した上で失効や差し替えを検討します。ブラウザー側の疑いでは、どのオリジンで評価されたか、そこで使えるセッションや操作範囲が何だったかを先に整理します。同じ障害対応票でも、サーバー側で調べる証跡と分けて扱うほうが判断しやすくなります。
この修正で確認できるのは、勧告が示した特殊なメンバー参照を阻止することです。利用者が書いた式を任意の権限で評価できる設計全体の安全性を保証するものではありません。修正版の配備後も、評価プロセスへ渡す資格情報やネットワーク権限を用途に合わせ、入力の出所と実行結果を追える状態にしておくと、今後別の問題が見つかったときに影響を絞り込めます。今回の完了条件には、稼働版、対象の全実行経路、正常系と拒否の確認結果を含めてください。
