WebフレームワークのSvelteと、その周辺ライブラリdevalueに脆弱性が4件公表されました。内訳はXSS（クロスサイトスクリプティング）が2件、DoS（サービス妨害）が2件です。修正版はSvelteが5.55.7、devalueが5.8.1で、いずれも既に公開されています。
ここで押さえておきたいのは、devalueがSvelte専用のライブラリではないという点です。Vue系のフレームワークであるNuxtも依存関係にdevalueを含んでいます。「うちはSvelteを使っていないから関係ない」と即断できる話ではありません。
この記事でわかること
- Svelteとdevalueが何をするもので、どこに組み込まれているか
- 公表された4件のCVEの内容と、影響を受けるバージョン
- 同じCVEでも情報源によって深刻度の評価が割れている理由
- 自社が該当するかを、その場で確かめる方法
Svelteとdevalueとは何者か
Svelteとは、Webアプリケーションの画面（UI）を作るためのJavaScriptフレームワークです。ReactやVueと同じ役割を担いますが、ブラウザ上で動く処理の多くをビルド時に済ませてしまう設計が特徴で、動作が軽いことを売りにしています。サーバ側の処理まで含めたフルスタック版は「SvelteKit」と呼ばれます。
使われる場面は、自社サービスのWeb画面、社内の管理ツール、キャンペーンサイトなどです。情シス自身が書くことは少なくても、開発部門や外注先が採用しているケースが想定されます。
devalueとは、JavaScriptのデータを文字列に変換（シリアライズ）するためのライブラリです。標準のJSON.stringifyでは扱えない循環参照・undefined・Date・Map/Set・BigIntといった値も変換できる点が特徴で、サーバで用意したデータをブラウザへ引き渡す用途で使われます。
そしてここが最も重要です。devalueは単体で導入した記憶がなくても、次のパッケージに同梱されて入ってきます（いずれもnpmレジストリ上の依存関係で確認）。
| 同梱している親パッケージ | 系統 | devalueの依存指定（執筆時点の最新版） |
|---|---|---|
@sveltejs/kit（SvelteKit 2.70.2） |
Svelte系 | ^5.8.1 |
svelte（5.56.9） |
Svelte系 | ^5.8.1 |
nuxt（4.5.2） |
Vue系 | ^5.9.0 |
つまりNuxtを使っているVue系の現場でも、ロックファイルの中にはdevalueが存在します。直接インストールした覚えがないため資産管理台帳にも載らず、存在に気づきにくいのが厄介なところです。
何が起きたのか（CVE4件の内訳）
2026年6月12日にJVN iPediaへ登録された4件は次のとおりです。
| CVE | 対象 | 種別 | 影響を受けるバージョン | 修正版 |
|---|---|---|---|---|
| CVE-2026-42567 | svelte | ReDoS（正規表現によるDoS） | 5.51.5 〜 5.55.6 | 5.55.7 |
| CVE-2026-42573 | svelte | XSS（DOM Clobbering経由） | 5.55.6 以下 | 5.55.7 |
| CVE-2026-42599 | svelte | XSS（スプレッド属性経由） | 5.55.6 以下 | 5.55.7 |
| CVE-2026-42570 | devalue | DoS（メモリ枯渇） | 5.6.3 〜 5.8.0 | 5.8.1 |
Svelte側の3件は「自動エスケープを過信するな」という話
モダンなフレームワークを使う理由のひとつは、「テンプレートに値を埋めれば勝手にエスケープしてくれる」という安心感です。今回のXSS2件は、その前提がすり抜けられる条件を突いています。
- CVE-2026-42599（スプレッド属性経由）：ユーザー入力やAPIレスポンスを、スプレッド構文でまとめて要素の属性に展開している場合が対象です。攻撃者が
onclickなどのイベントハンドラに相当するプロパティを混ぜ込むと、それがレンダリングされたHTMLに残り、被害者のブラウザで実行され得ます。発火するのは、ハイドレーション（サーバで描いたHTMLにブラウザ側の処理を結びつける工程）が該当要素に到達する前にイベントが起きた場合に限られます。 - CVE-2026-42573（DOM Clobbering経由）：Svelteが内部管理用のデータをDOM要素のプロパティとして持っていたところ、攻撃者が仕込んだ
idやname属性を持つ要素がそのプロパティ名を上書きしてしまう、という仕組みです。フレームワークが内部参照を読みに行った先に攻撃者のデータが返るため、XSSにつながる恐れがあります。GitHubのアドバイザリでは、form要素での属性スプレッドと、input/button要素のname属性の両方が同時にユーザー制御可能な場合、という条件が示されています。
どちらも「信頼できないデータをまとめて属性に流し込んでいるか」が分岐点です。開発チームに確認するなら、CVE番号を伝えるよりこの一点を聞くほうが早いはずです。
DoS2件は「入力の長さを制限していないか」
CVE-2026-42567は、<svelte:element this={tag}>というタグ名を動的に決める機能で、内部の正規表現の処理時間が入力長に対して指数的に伸びるというものです。GitHubのアドバイザリには、あらかじめ決めたタグ名のリストから選ばせるか、長さを制限していれば影響を受けないと明記されています。ユーザー入力をそのままタグ名にしている実装が対象、と読み替えられます。
CVE-2026-42570は、devalueが値を復元するdevalue.parseに、まばらな配列（sparse array）を含む細工されたデータを渡すと、必要以上のメモリを確保してしまうというものです。攻撃が成立するかは「信頼できない入力がdevalue.parseに到達するか」で決まります。ロックファイルに該当バージョンが載っていることと、実際に攻撃可能であることはイコールではない点に注意してください。
なぜ深刻度の数字が情報源によって違うのか
今回、脆弱性管理の実務で戸惑いやすい点があります。同じCVEでも、JVN iPediaとGitHubのアドバイザリでスコアが食い違っています。
| CVE | JVN iPedia（CVSS v3） | GitHubアドバイザリ |
|---|---|---|
| CVE-2026-42567 | 7.5（重要） | CVSS v4で5.9（中程度） |
| CVE-2026-42573 | 6.1（警告） | 5.3（中程度） |
| CVE-2026-42599 | 6.1（警告） | CVSS v4で5.1（中程度） |
理由は主に評価に使ったCVSSのバージョンが違うことです。v3とv4では算出方法が異なるため、同じ脆弱性でも数字がずれます。
これは実務に直結します。「CVSS 7.0以上は即時対応」といった社内基準を機械的に運用していると、参照するデータソースを変えただけでトリアージの結論が変わってしまいます。CVE-2026-42567はまさにその境界（7.5と5.9）にあります。数字を鵜呑みにせず、「自社の実装が発動条件に当てはまるか」で判断する必要があります。今回でいえば、ユーザー入力をタグ名にしていなければ、7.5でも実質的な優先度は下がります。
なお、脆弱性の深刻度の見立てが後から変わること自体は珍しくありません。当初DoSと見られていた問題がより重い評価に変わった例として、NetScaler脆弱性、DoS想定が認証不要RCEにも参考になります。
自社が該当するかを確かめる方法
Node.jsのプロジェクトであれば、その場で判定できます。開発部門や外注先に依頼する際は、次のコマンドの結果をそのまま送ってもらうのが確実です。
- 導入バージョンの確認：プロジェクトのディレクトリで
npm ls svelte devalueを実行します。直接依存だけでなく、どのパッケージ経由で入っているかも表示されます。 - 依存元の特定：pnpmを使っている場合は
pnpm why devalue、yarnならyarn why devalueが使えます。 - ロックファイルの確認：
package-lock.jsonやpnpm-lock.yamlの中をdevalueで検索します。ここに載っていれば、直接インストールしていなくても同梱されています。 - 一括チェック：
npm auditで既知の脆弱性がまとめて報告されます。
該当した場合の対処はシンプルで、Svelteを5.55.7以降、devalueを5.8.1以降へ更新し、アプリケーションを再ビルドすることです。ビルド時に取り込まれるライブラリなので、更新しただけでは反映されず、再ビルドと再デプロイまで済ませて初めて対策完了となります。ここは運用でよく漏れるポイントです。
現場目線の課題
正直なところ、この種の脆弱性は情シスにとって最も動きにくい類のものです。
まず対象がどこにあるのか把握しづらい。サーバやPCであれば資産管理台帳やエージェントで棚卸しできますが、「あるWebアプリのnpm依存関係の中にdevalueが入っている」という事実は、ソースコードかロックファイルを見に行かないと分かりません。外注で作ってもらったまま保守契約が切れているサイトなどは、確認する相手を探すところから始まります。
次に手を動かすのが自分ではない。更新の判断はできても、再ビルドとデプロイは開発部門やベンダーの作業です。そこに動いてもらうには、「CVE-2026-42599が出ました」ではなく「スプレッド属性で外部データを展開している箇所はありますか」と具体的に聞ける材料が要ります。
加えて、SvelteチームがCVEに関する公式ブログ（2026年1月15日公開）で述べているとおり、この手の報告はWeb開発エコシステム全体で相次いでいます。同ブログでは今回とは別に、devalueの過去のDoS（CVE-2026-22774、CVE-2026-22775）やSvelteKit側の問題も整理されています。1件ずつ緊急対応していては回りません。四半期に一度は依存関係を棚卸しして、まとめて上げる運用に寄せるほうが現実的だと考えます。同様の構図は、Javaの暗号ライブラリで起きたBouncy Castleに脆弱性22件 証明書検証に欠陥や、他のJavaScriptフレームワークで起きたNext.jsに9件の脆弱性、認証回避やSSRFとも共通します。
情シスはどうすべきか
個別のチェックリストを作り込むより、「どこに何のライブラリが入っているか」を継続的に把握する仕組みに投資したほうが効きます。SBOM（ソフトウェア部品表）の整備や、CI/CDへの依存関係スキャンの組み込みが該当します。
体制づくりの土台としては、IPAの中小企業の情報セキュリティ対策ガイドラインが使えます。「委託先の管理」や「情報資産の把握」の考え方が整理されており、外注先へ確認を求める根拠としても示しやすい内容です。実際にインシデントが起きたときの動き方を組織で確認しておくなら、IPAのセキュリティインシデント対応 机上演習教材も無償で利用できます。
あわせて、開発部門への地道な啓発も効果があります。今回のXSS2件は、いずれも「外部由来のデータをまとめて属性に展開しない」「必要な属性だけを明示的に指定する」という基本を守っていれば、フレームワークの修正を待たずに影響を避けられた性質のものです。内製ツールでXSSが問題になった例としては、Appsmithに保存型XSS、内製ツール基盤の盲点も参考になります。
まとめ
- Svelteに3件（XSS2件・ReDoS1件）、devalueに1件（DoS）の脆弱性が公表されました。修正版はSvelte 5.55.7、devalue 5.8.1です。更新後は再ビルドと再デプロイまで行って初めて対策完了になります。
- devalueはSvelteKitだけでなくNuxtにも同梱されています。Vue系の現場でもロックファイルに存在するため、
npm ls devalueなどで該当有無を確認してください。 - 深刻度の数字はCVSSのバージョン差で情報源ごとに割れています。スコアで機械的に切らず、「自社の実装が発動条件に当てはまるか」で優先度を判断するのが実務的です。
出典
- JVN iPedia: JVNDB-2026-019596（CVE-2026-42573 / Svelte XSS）
- JVN iPedia: JVNDB-2026-019595（CVE-2026-42599 / Svelte XSS）
- JVN iPedia: JVNDB-2026-019598（CVE-2026-42567 / Svelte ReDoS）
- JVN iPedia: JVNDB-2026-019597（CVE-2026-42570 / devalue DoS）
- GitHub Security Advisory: GHSA-9rmh-mm8f-r9h6（ReDoS in <svelte:element> Tag Validation）
- GitHub Security Advisory: GHSA-rcqx-6q8c-2c42（DOM Clobbering）
- GitHub Security Advisory: GHSA-pr6f-5x2q-rwfp（スプレッド属性経由のXSS）
- Svelte公式ブログ: CVEs affecting the Svelte ecosystem（2026年1月15日）
- 依存関係の確認: npmレジストリ（
@sveltejs/kit2.70.2 /svelte5.56.9 /nuxt4.5.2 の各package.json、2026年8月17日時点） - IPA: 中小企業の情報セキュリティ対策ガイドライン
