計算用JS部品expr-evalにコード実行の欠陥 CVE-2026-12866、入力に注意

数式を計算するためのJavaScript部品として広く使われているexpr-evalに、細工した文字列を渡すと攻撃者のプログラムがそのまま実行されてしまう重大な欠陥が報告されました。脆弱性の管理番号はCVE-2026-12866、深刻度を示すCVSSスコアは10点満点中9.8（最高ランクの「緊急」）です。セキュリティ企業Snykが2026年6月23日に公開しました。

expr-evalは週80万回以上ダウンロードされる定番の部品で、オンライン計算機や教育系ツール、金融アプリ、そしてプロンプトから数式を読み取るAI・自然言語処理アプリにまで組み込まれています。今回の問題は特定のバージョンだけでなくすべてのバージョンが対象とされており、自分のサービスが知らないうちにこの部品を抱えているケースが少なくありません。

expr-evalとは何か、なぜ危ないのか

expr-evalは「1 + 2 * (3 - x)」のような数式を文字列のまま受け取り、答えを計算してくれるライブラリ（プログラムの部品）です。JavaScriptには文字列をそのまま命令として実行するeval()という機能がありますが、これは何でも実行できてしまい危険なため、「数式の計算だけを安全にやりたい」用途でexpr-evalのような専用部品が選ばれてきました。

問題になったのは、expr-evalが持つtoJSFunction()という関数です。これは受け取った数式を、計算を高速化するためにJavaScriptの本物の関数へ変換する機能で、内部では先ほど危険だと述べたnew Function()（eval()と同種の仕組み）を使っています。つまり、利用者から受け取った文字列がそのまま「実行されるプログラム」に化けてしまう構造です。脆弱性データベースの記述によれば、攻撃者は数式に見せかけた命令を送り込むことで、計算用の枠（サンドボックス）を抜け出し、アプリの権限で任意のコードを動かせます。

この部品は実は同じ時期に脆弱性が相次いでいます。2025年末には、別の入口（evaluate()に渡す設定）から遠隔コード実行ができるCVE-2025-12735が報じられ、米CERT/CCも注意喚起（VU#263614）を出していました。今回のCVE-2026-12866は、その兄弟にあたる「もう一つの入口」と捉えると分かりやすいです。

誰が狙い、何をしてくるのか

この穴を悪用するのは、利用者が入力した数式や計算式を文字列のまま処理するWebサービス・AIアプリを狙う攻撃者です。最近は「文章から数式を取り出して計算する」AIアシスタントや、ユーザーが計算ルールを自由に書ける業務ツールが増えており、そうした入力経路がそのまま狙い目になります。

攻撃者がやることは単純です。数式の入力欄に、計算式のふりをした命令文を打ち込み、サーバー側で自分のプログラムを実行させようとします。CVSSの評価でも、攻撃にはログインも特別な操作も不要（ネットワーク越しに誰でも試せる）とされており、入力が攻撃者の手に渡っている時点で成立し得ます。

成功した場合の被害は、サービスを使う一般の人にとっては個人情報や入力データの盗み取り、アカウントの乗っ取りにつながり、システムを運営する企業にとってはサーバーの乗っ取り、社内ネットワークへの侵入の足がかり、サービス停止といった形で表れます。計算用の小さな部品ひとつが、サービス全体の入口になり得るということです。なお、過去に週間1億ダウンロードのnpmパッケージにマルウェアが混入したaxiosの事例のように、定番部品ほど影響範囲が広くなりがちです。

今回の脆弱性の概要

expr-evalをめぐる脆弱性は1件ではないため、混同しないよう整理します。今回新たに公開されたのは表のいちばん上、CVE-2026-12866です。

CVE-2026-12866: toJSFunction()経由のコード実行

数式をネイティブのJavaScript関数に変換するtoJSFunction()に攻撃者の文字列を渡すと、その内容がコードとして実行されます。CVSSは9.8、攻撃区分はネットワーク経由・認証不要・利用者操作不要。Snykが採番し、発見者はDinh Tuan Doan氏とされています。

3件に共通するのは、「利用者が書いた式を、そのまま実行できる形に変換してしまう」というexpr-evalの根っこの設計です。CVE-2025-12735の詳細でも同じ構造が指摘されています。

時系列で見るexpr-evalの脆弱性

← スワイプで移動

確認できたことと、まだはっきりしないこと

この脆弱性は「単純なバグ」とは少し性質が異なり、報道や断定に注意が必要な部分があります。現時点で一次情報から確認できる事実と、まだ確定していない点を分けて整理します。

要点は、「修正版を入れれば終わり」という単純な話ではない、という点です。eval()に外部入力を渡してはいけないのと同じく、toJSFunction()に信頼できない入力を渡さないという使い方そのものの見直しが本質的な対策になります。

自分のサービスが影響を受けるか確認する

expr-evalは直接使っていなくても、別のライブラリが内部で引き込んでいる（間接依存）ことがよくあります。とくにAIや自然言語処理まわりのツールに紛れ込みやすいので、まず手元のプロジェクトで使われているかを確認します。

• npm ls expr-eval expr-eval-fork で依存ツリーに含まれていないか確認する
• 含まれていた場合、コード中でtoJSFunction()やevaluate()に外部から来た文字列を渡していないかを確認する
• 数式の入力を受け付けるフォームやAPI、AIアシスタントの計算機能が該当しやすい

依存関係を貼り付けるだけでこうした既知の脆弱性を一括チェックできる、当サイトのOSSサプライチェーン スキャナーも活用してください。npmやPythonの依存を貼るだけで該当の有無を確認できます。同じくライブラリ由来の脆弱性としては、多言語化部品のi18nextの事例も参考になります。

いま取るべき対策

対策の軸は3つです。いちばん重要なのは、入力の出どころを断つことです。

1. 信頼できない入力をtoJSFunction()やevaluate()に渡さない。 利用者やネット越しに送られてくる文字列を、そのまま数式として実行する設計を避けます。どうしても外部の数式を計算する必要がある場合は、入力を厳しく検証し、許可した記号と数字だけに限定します。toJSFunction()はeval()と同じ危険度として扱うのが安全です。

2. 保守の止まった本体から、後継のexpr-eval-forkへ移行する。 オリジナルのexpr-evalは更新が止まっており、過去のCVE-2025-12735も本体側では十分に直っていません。活発に保守されているexpr-eval-forkの3.0.0以降は、安全な関数の許可リストなどの防御を備えています。SC Mediaの報道でも移行が推奨されています。

3. 依存関係の棚卸しを定期化する。 今回のように「定番だが保守が止まった部品」は、放置すると同種の脆弱性が次々と出てきます。Techzineの記事も、使っているバージョンの確認と移行を呼びかけています。間接依存まで含めて何が入っているかを把握し、保守状況も含めて選び直す習慣が、結局いちばんの防御になります。

まとめ

CVE-2026-12866は、数式計算の定番部品expr-evalのtoJSFunction()に外部入力を渡すと任意のコードが走るという、CVSS9.8の重大な問題です。ただしこれは単独のバグというより、「利用者の式をそのまま実行できる形に変える」というこの部品の設計に根ざしたもので、過去のCVE-2025-12735とも地続きです。修正版を待つ前に、まず信頼できない入力をこの部品に渡していないかを確認し、保守の止まった本体から後継版へ移ること。小さな計算用部品が、サービス全体の入口になり得るという前提で点検しておきたいところです。

参照元

• ▸NVD - CVE-2026-12866
• ▸CIRCL Vulnerability-Lookup - CVE-2026-12866
• ▸Snyk - expr-eval パッケージの脆弱性一覧
• ▸BleepingComputer - Popular JavaScript library expr-eval vulnerable to RCE flaw
• ▸CERT/CC - VU#263614 expr-eval can lead to arbitrary code execution
• ▸SC Media - RCE possible with expr-eval JavaScript library vulnerability
• ▸Techzine - Critical vulnerability exposed in JavaScript library expr-eval
• ▸CVE Details - CVE-2025-12735
• ▸GitHub - silentmatt/expr-eval
• ▸npm - expr-eval-fork