node-forgeの脆弱性CVE-2025-12816とは｜ASN.1検証バイパスの仕組みと1.4.0でも残る署名偽造への対応【2026年10月】

CVE-2025-12816は、JavaScriptの暗号ライブラリnode-forge（Forge）が証明書や署名データの構造を照合する処理で、細工したデータによって照合の位置がずれ、署名やMACの検証をすり抜けられる脆弱性です。node-forgeはnpmで直近1週間に約4,674万回ダウンロードされており、多くは別のパッケージ経由の間接依存として入っています。この脆弱性は1.3.2で直りました。ところがその後も署名偽造の脆弱性が続き、2026年10月2日時点では最新の1.4.0でも未修正の1件が残っています。この記事では、仕組みと影響、続いたCVEの時系列、間接依存の確認と暫定対処までを、公式アドバイザリに基づいて整理します。

まとめ：1.4.0へ更新し未修正の署名偽造には低指数鍵の拒否で備える

CVE-2025-12816（CVSS 3.1基本値8.6）は1.3.1以下が対象で、1.3.2で修正されました。ただし1.3.2と1.3.3には、2026年3月に公表された署名偽造など4件のHighが残っており、これらは1.4.0で直っています。まず1.4.0へ上げることが前提です。

2026年9月3日に公表されたCVE-2026-85393（RSA PKCS#1 v1.5の署名偽造）は、1.4.0以下のすべてが対象で、修正版がまだありません。攻撃には公開指数の小さいRSA鍵（e=3など）が必要なため、修正版が出るまでは低指数の鍵を拒否するか、Node.js標準の crypto で検証する構成へ移すのが現実的な備えです。

CVE-2025-12816の基本情報とASN.1検証がずれる仕組み

node-forgeは、証明書の解析や暗号処理をブラウザとNode.jsの両方で行うためのライブラリです。CVE-2025-12816は、その中核にある asn1.validate の欠陥でした。

NVD・CERT/CCに登録されたCVSS 8.6とCWE-436の位置づけ

CVSSのベクトルは、NVDの登録情報にあるとおり AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N です。認証なしにネットワーク越しで成立し、完全性（I）への影響が高いという評価で、機密性と可用性への影響は付いていません。番号の採番と公表はCERT/CCの脆弱性ノートを通じて行われました。CVEとCVSSの関係はCVEの仕組みとCVSS・CWEの違いで解説しています。

任意項目の境界で照合がずれ署名とMACの検証が飛ばされる流れ

ASN.1は、証明書（X.509）や署名メッセージ（PKCS#7）、鍵の格納形式（PKCS#12）のデータ構造を定める記法で、必須の項目と任意（OPTIONAL）の項目が混在します。node-forgeは、受け取ったデータを固定のテンプレートと照合しながら、署名対象のバイト列や公開鍵の位置を特定していました。

開発元のアドバイザリ（GHSA-5gfm-wpxj-wjgq）によると、任意項目の境界に細工を入れると照合の位置がずれ、壊れた任意項目が「次に来る必須の構造」として読み替えられます。その結果、PKCS#12のように安全機能が任意の形式ではMACが「存在しない」扱いになり、X.509のように厳密な形式では項目が別の型として読まれる仕組みです。影響を受けるファイルとして、asn1.jsのほかx509.js、pkcs12.js、pkcs7.js、rsa.js、pbe.js、ed25519.jsが挙げられています。

X.509・PKCS#7・PKCS#12の処理で起きうる実害と影響範囲

アプリ側は「node-forgeが不正なデータを弾く」と信頼して呼び出しているため、検証の抜けはアプリのコードを変えなくても成立します。

改ざんされた鍵ファイルや署名付きメッセージを正当と誤認する例

PKCS#12では、改ざんされた鍵・証明書のファイルを、完全性の確認を飛ばしたまま読み込む恐れがあります。PKCS#7では、改ざんされたメッセージを正規の署名付きと誤認する可能性があるという問題です。X.509では、項目の取り違えによって証明書の内容を偽装される余地が生まれます。証明書の検証はTLSの仕組みと証明書検証の流れの土台なので、自前でnode-forgeを使って証明書を検証しているサーバーは、なりすましの起点になりえます。

直近週4,674万ダウンロードの大半を占める間接依存の見えにくさ

npmの集計では、2026年9月24日〜30日の1週間のダウンロード数は46,740,469回でした。自分の package.json に書いていなくても、開発用HTTPSサーバーの自己署名証明書を作るパッケージなどが内部でnode-forgeを読み込んでいることがあります。依存の連鎖で被害が広がる構図はサプライチェーン攻撃の3類型、npmでの実例はShai-Huludによるnpmサプライチェーン攻撃で扱っています。

1.3.2の後も続いたnode-forgeの署名偽造CVEと2026年10月時点の状況

CVE-2025-12816の修正で終わりではありませんでした。GitHub Advisory Databaseに登録されたnode-forgeのアドバイザリを、2025年11月以降で並べます。

2025年11月から2026年9月までの公表日と修正版の時系列表

日付はGitHub Advisory Databaseの公開日です。2026年3月の4件はいずれもHighで、CVE-2026-33894のアドバイザリは、公開指数e=3の鍵に対して、ASN.1構造の中に余分なバイトを詰めた偽の署名が検証を通ると説明しています。CVE-2026-33896は、証明書チェーンの検証でbasicConstraintsの確認が抜け、CA権限の無い証明書で下位の証明書を発行できる問題でした。

1.4.0でも修正版が無いCVE-2026-85393と攻撃の前提条件

CVE-2026-85393のアドバイザリ（2026年9月3日公開、10月1日更新）は、1.4.0以下のRSA PKCS#1 v1.5署名検証が、入れ子になったDigestAlgorithmの要素数を確かめていないと説明しています。CVE-2026-33894の修正が不完全だったもので、CVSS 3.1は7.5です。2026年10月2日時点で修正版の記載はなく、npmのlatestも1.4.0のままです。

実際に、[email protected]経由でnode-forge 1.4.0が入った構成で npm audit を実行すると、node-forgeは全版（*）がHighとして表示されました。攻撃の前提は「公開指数の小さいRSA鍵で検証していること」です。e=65537の鍵だけを使う構成では成立しにくい一方、外部から受け取った任意の公開鍵で検証する処理は対象になりえます。

実装者が今すぐ実行するnode-forgeの確認・更新と暫定対処の手順

上から順に進めます。

npm lsとnpm explainで間接依存を洗い出しoverridesで固定する

# どのパッケージが node-forge を引き込んでいるか（間接依存を含む）
npm ls node-forge
npm explain node-forge

# 例：[email protected] だけを入れた構成での出力
# `-- [email protected]
#   `-- [email protected]

間接依存のnode-forgeが1.4.0未満なら、親パッケージを更新するのが第一です。親が古い版を指定したまま更新されない場合は、package.json の overrides で版を固定します。

{
  "overrides": {
    "node-forge": "1.4.0"
  }
}

この指定の後に npm install を実行すると、npm ls node-forge に「overridden」と表示されます。親パッケージがnode-forgeの古いAPIに依存している場合は動かなくなる可能性があるため、テストを通してから本番へ反映してください。依存の版を継続的に照合する仕組みはSCA（ソフトウェア構成分析）の導入判断、部品表の管理はSBOMの目的と運用で整理しています。

修正版が出るまで低指数のRSA鍵を拒否する暫定検証ガードの実装

CVE-2026-85393の修正版が出るまでの暫定策として、node-forgeでRSA署名を検証する前に公開指数を確かめ、65537未満の鍵を拒否します。これは公式の回避策ではなく、アドバイザリが攻撃の条件に低指数の鍵を挙げていることに基づく防御です。

// node-forge で RSA 署名を検証する前に、公開指数 e が 65537 以上かを確かめる（低指数鍵を拒否）
const forge = require("node-forge");

function verifyWithGuard(publicKeyPem, message, signatureBinary) {
  const key = forge.pki.publicKeyFromPem(publicKeyPem);
  if (key.e.compareTo(new forge.jsbn.BigInteger("65537")) < 0) {
    throw new Error(`公開指数が小さすぎる鍵は受け付けない（e=${key.e.toString()}）`);
  }
  const md = forge.md.sha256.create();
  md.update(message, "utf8");
  return key.verify(md.digest().bytes(), signatureBinary);
}

node-forge 1.4.0で、e=65537の鍵では検証が成功し、e=3の鍵では例外になることを確認しています。ただしこのガードは、自分で key.verify を呼ぶ処理にしか効きません。pki.verifyCertificateChain などライブラリ内部の検証は対象外です。署名検証が業務の中心にあるなら、Node.js標準の crypto.verify へ置き換える方が根本的です。

自社のアプリや公開サーバーに、node-forge以外の依存も含めて見落としがないかを第三者の目で確かめたい場合は、一創の脆弱性診断・セキュリティ診断で、依存関係と公開経路を横断して点検できます。

OSSの暗号ライブラリに署名や証明書の検証を委ねるときの設計判断

node-forgeでは、半年足らずで署名偽造が3件続きました。判断を言い切ります。新規の開発で、サーバー側の署名検証や証明書検証をnode-forgeに任せる設計は採りません。Node.jsには標準の crypto モジュールがあり、OpenSSLの検証をそのまま使えるからです。

一方、ブラウザでPKCS#12を読むなど、標準APIで代替できない用途でnode-forgeを使い続けるのは妥当です。その場合も、node-forgeの検証結果だけで認可を決めず、サーバー側でもう一度検証する多層の構成にします。開発用の自己署名証明書の生成だけに使っているなら、影響は限られるため、定例の依存更新で1.4.0へ上げれば足ります。

よくある質問

node-forgeの脆弱性について寄せられやすい質問に答えます。

node-forgeを直接使っていなければ影響はないですか？

断定はできません。依存する別のパッケージが内部でnode-forgeを読み込んでいる場合があります。npm ls node-forge と npm explain node-forge で、どのパッケージ経由で入っているかを確認してください。間接依存でも、そのパッケージが証明書や署名を検証していれば影響を受けます。

どのバージョンに更新すれば安全ですか？

2026年10月2日時点で更新先は1.4.0です。CVE-2025-12816は1.3.2で直りましたが、2026年3月に公表された署名偽造など4件は1.4.0で修正されました。ただし2026年9月3日公表のCVE-2026-85393は1.4.0でも未修正なので、低指数のRSA鍵を拒否するなどの暫定対処を併用してください。

署名検証バイパスとは具体的に何が危険なのですか？

本来は不正なデータを弾くはずの検証が素通りするため、偽の証明書や改ざんされた署名を正当と誤認します。署名付きのトークンや設定ファイルで権限を決めている処理なら、なりすましや権限の取得につながる恐れがあるため危険です。PKCS#12のMACが飛ばされると、改ざんされた鍵ファイルを読み込む恐れもあります。

すでに攻撃を受けたか確認する方法はありますか？

この種の欠陥は明確な痕跡が残りにくく、ログだけで判定するのは困難です。外部から受け取った証明書や署名をnode-forgeで検証している処理を特定し、その処理で受け付けた鍵の公開指数や、検証を通った証明書の発行者を見直すのが手がかりになります。2026年10月1日時点でCISAの悪用確認リストには載っていません。

自社のOSS依存を継続的に点検するにはどうすればよいですか？

SBOMで依存構成を可視化し、npm audit やDependabotなどのスキャンをCIに組み込むのが基本です。ロックファイルで版を固定し、修正版への追随を月次の定例作業にしておくと、node-forgeのように続報が続くライブラリにも追いつけます。

関連記事

• CVE（共通脆弱性識別子）とは：CVSS・CWEとの違い
• サプライチェーン攻撃とは：起点別3類型と対策の優先順位
• Shai-Hulud（シャイ・フルード）とは：npmサプライチェーン攻撃の全体像
• TLSとは：証明書検証の流れ
• SCAとは：依存関係の脆弱性を継続的に洗い出す仕組み