node-forgeの脆弱性一覧、1.3.3以前は署名偽造の恐れ 1.4.0へ更新を

JavaScriptの暗号ライブラリ「node-forge」の最新版は1.4.0で、2026年3月24日に公開されました。2026年8月20日の時点で、これより新しい版は出ていません。1.3.3以前には、攻撃者が作った偽の署名を本物として受け入れてしまう欠陥を含む4件が直っていないまま残ります。1.3.1以前なら、さらに3件が加わって合計7件です。

node-forgeは、暗号化・電子署名・証明書の取り扱いといった処理を、JavaScriptだけで実行できるようにする部品です。米Digital Bazaar社が開発しています。npmが公開している統計では、直近1週間（2026年8月12日〜18日）のダウンロードは約3,190万回でした。

やっかいなのは、自分で選んで入れた覚えがなくても入っている点です。Googleが運営する依存関係のデータベースdeps.devには、1.4.0に依存しているパッケージが64,275件登録されています。このうち直接の依存は2,923件だけで、残る61,456件は「使っている部品が、さらに内側で使っている」形です。証明書を作るツールや開発用の通信部品をひとつ入れただけで、node-forgeも一緒に入ってきます。この連鎖の危うさはOSSサプライチェーン スキャナーでも扱っています。

使っている版が対象かどうか（1.3.1・1.3.2・1.3.3はいずれも対象）

版ごとに、npmの検査コマンド npm audit が知らせてくる「直っていない欠陥」の件数を並べます。2026年8月20日に、それぞれの版を実際に入れて確認した結果です。「高」「中」「低」は危険度の区分です。

1.3.1が7件と多いのは、この版が長く「最新版」だったためです。1.3.1が出たのは2022年3月29日で、次の1.3.2が出るまで3年8か月かかりました。その間に見つかった欠陥がまとめて残っています。2022年から動き続けているアプリは、まだ1.3.1のままである可能性があります。

1.3.2と1.3.3は2025年11月から12月に出た比較的新しい版ですが、2026年3月に公表された4件はこの2つの版も対象です。「去年入れ替えたばかりだから大丈夫」とは言えません。

いま入っている版を確かめる

プロジェクトのフォルダで npm ls node-forge を実行します。直接使っていない場合でも、どの部品を経由して入ってきたかが枝分かれの形で表示されます。次は、証明書を作る部品「selfsigned」の2.4.1だけを入れたプロジェクトでの実際の出力です。

下段に出ている node-forge@1.4.0 が、実際に読み込まれている版です。ここが1.4.0より前なら対象になります。上段の selfsigned@2.4.1 は、node-forgeを内側で使っている部品の名前です。更新のときは、この親の部品を上げる必要があるかどうかの手がかりになります。なおselfsignedは5系で中身が入れ替わり、node-forgeを使わなくなりました。親の部品を上げるだけで、node-forgeごと外れる場合もあります。

危険度つきで一覧したいときは npm audit です。1.3.1を入れたプロジェクトでは、次のように7件が並びます。

集計の行には「1 high severity vulnerability」と出ます。これは「欠陥のある部品が1つ」という数え方で、その中身は7件です。集計の数字だけを見て軽く見ないでください。

この2つのコマンドで見つからない置き場所がひとつあります。ブラウザ向けに配信サイト（CDN）から直接読み込んでいる分は、npmの管理下にないので表示されません。この確かめ方は後の節で説明します。

1.4.0で直った4件（2026年3月公表）

1.4.0では4件が修正されました。開発元の変更履歴に、4件それぞれの番号と修正内容が書かれています。危険度の数字は開発元がGitHubに出した届け出のもので、npm audit が表示する区分もこれと同じです。CVE-2026-33896だけは、米国立標準技術研究所が運営する脆弱性データベース（NVD）が別の評価を出しているため、そちらも併記しました。

日本の脆弱性情報ポータルJVN（JVNVU#98998987）と米CERT/CCのアドバイザリ（VU#725167）が2026年7月に取り上げたのは、このうち署名偽造の2件です。残るCVE-2026-33896とCVE-2026-33891はこの2つの発表に含まれていないため、日本語の情報だけを追っていると見落とします。署名偽造の2件を報告したのは、カリフォルニア大学バークレー校の研究チーム（Austin Chu氏、Sohee Kim氏、Corban Villa氏）です。

CERT/CCは、node-forgeの検証機能をそのまま使っている他の実装も影響を受ける可能性があると書いています。名前が挙がっているのは、認証用のトークンを扱うnode-jose、AdobeやExpoの証明書まわりの仕組みなどです。ただし、通知を受けた各社からの回答は2026年7月15日の時点でいずれも「不明」のままで、影響の有無は確定していません。node-joseのようなトークン処理の部品を使っているなら、その部品の側にも更新が出ていないかを見ておいてください。

CVE-2026-33894：RSAの署名に余分なデータを詰めて偽造できる

電子署名とは、データが本物で書き換えられていないことを示す印です。受け取った側は署名を検証して「確かに正規のものだ」と判断します。CVE-2026-33894は、RSAという方式でこの検証が甘かったという問題です。署名の中身は決まった形（項目が2つだけの構造）でなければならないのに、node-forgeは項目が増えていても受け入れていました。さらに、規格では8バイト以上と決まっている詰め物の長さも確認していませんでした。この2つのすき間を使うと、鍵の作りによっては（公開鍵に含まれる「公開指数」という値が3のように小さい場合）、正規の秘密鍵を持たない相手でも検証を通る署名を組み立てられます。

1.4.0では、詰め物の最小の長さを強制し、署名の中身の構造を項目2つに限る修正が入りました。同じ種類の欠陥は2022年にも見つかっており（CVE-2022-24771）、今回はその修正が届いていなかった別の場所で成立します。

CVE-2026-33895：Ed25519の「別の見た目」の署名を受け入れる

CVE-2026-33895は、Ed25519という方式の検証で、署名の後半にある数値が決められた範囲に収まっているかを確認していなかったという問題です。範囲外の値でも計算上は通ってしまうため、中身は同じなのに見た目が違う署名が複数存在できてしまいます。署名の文字列そのものを目印にしている仕組み、たとえば同じ要求が二重に来ていないかの判定や、送られてきた記録の重複チェックが混乱します。開発元は、同じ性質の欠陥が過去に認証や権限の判定を回避するのに使われた例（CVE-2022-35961、CVE-2026-25793）を挙げています。1.4.0では、範囲内かどうかを確かめる処理が追加されました。

CVE-2026-33896：中間の証明書が「発行者になれる」チェックを飛ばす

CVE-2026-33896は、証明書のつながりを確かめる処理（pki.verifyCertificateChain()）の問題です。証明書には「この証明書は他の証明書を発行してよい」という印を付ける決まりがありますが、node-forgeは、その印も使い道の指定も両方とも書かれていない証明書に出会うと、確認そのものを飛ばしていました。結果として、本来は末端でしかない証明書が発行者としてふるまい、そこから作られた偽の証明書が正規のものとして通ります。この1件だけは、危険度の評価が出典で割れています。開発元の届け出は7.4で「成立させるには条件が要る」としていますが、NVDは同じ欠陥を9.1とし、区分も「高」ではなく最上位の「緊急」に置いています。成立に条件が要るかどうかの見方が食い違っているためです。証明書の検証にnode-forgeを使っているなら、低いほうの数字を根拠に後回しにしないでください。

CVE-2026-33891：0を渡すと計算が止まらなくなる

CVE-2026-33891は、大きな数の計算部分に0が渡されると終わりのない繰り返しに入り、その処理が固まったままCPUを使い切るという問題です。外から来たデータがこの計算に届く作りになっていると、1回の要求でサービスを止められます。署名の偽造とは別種で、狙われるのはサービスの継続です。

1.3.2で直った3件（1.3.1以前が対象）

1.3.1のまま止まっているなら、上の4件に加えて2025年11月公表の3件も対象です。いずれもASN.1という、証明書や鍵のデータを表す形式の読み取りに関する問題で、報告者はHunter Wodzenski氏です。

• CVE-2025-12816（危険度 高・8.6）：細工したデータで、形式の検査と実際の読み取りの結果をずらせる。PKCS#12（拡張子が.pfxの証明書ファイル）の改ざん検知がすり抜ける経路が確認されている
• CVE-2025-66031（危険度 高）：入れ子が極端に深いデータを読ませると、処理が積み上がって停止する
• CVE-2025-66030（危険度 中）：大きな数値を含む識別子が、桁あふれによって別の小さな識別子として読まれる。識別子を見て可否を決めている処理をだませる

この3件を直した1.3.2には、PKCS#12の扱いに不具合が入り込みました。1週間後の1.3.3で修正されています。1.3.2で止めずに1.4.0まで上げれば、この分も含まれます。

1.3.2以降では、データの入れ子の深さに256という上限が設けられました。開発元は変更履歴で「正しいデータには十分な余裕があるはずだが、この前提が崩れる使い方があるなら報告してほしい」と書いています。極端に深い構造を扱っている場合は、更新後に読み取りが拒否されないかを確認してください。

どれくらい急ぐか

署名の検証がすり抜けられるということは、電子的な本人確認が崩れるということです。偽のログイン用の引換券（トークン）、偽の証明書、書き換えたデータに「それらしい署名」を付けたものが、正規のものとして通ります。ログインの可否、アクセス権の判定、配布するプログラムが本物かの確認は、どれも署名の検証を土台にしています。

一方で、実際に攻撃へ使われた形跡は今のところ報告されていません。米CISAが公開している「実際に攻撃されている脆弱性の一覧（KEV）」の2026年8月19日版にも、今回の4件と2025年11月の3件はいずれも載っていません。

ただし、CERT/CCは署名偽造の2件について「攻撃の実演コードが公開されており、遠隔から、検証を行っている相手に対して実行できる」と書いています。この2件の危険度は10点満点で7.5、9.0以上の「緊急」ではありませんが、後回しにしてよい種類ではありません。また、証明書の親子関係をすり抜けるCVE-2026-33896のほうは、NVDの評価では9.1で「緊急」の区分に入ります。ログイン用のトークン、証明書、プログラムの署名の検証にnode-forgeを使っているなら、優先度は上がります。

1.4.0へ上げる手順

• 直接使っている場合は npm install node-forge@^1.4.0 を実行する
• 別の部品の内側に入っている場合は、その部品（npm ls node-forge で上段に出ていた名前）を新しくする
• 親の部品がまだ対応していないときは、package.jsonの overrides に書いて版を上書きする
• npm ls node-forge をもう一度実行し、表示されるすべてが1.4.0になったか確かめる
• package-lock.jsonの変更を、他の開発者や本番環境へ配る手順まで行う

上書きの書き方は次のとおりです。package.jsonにこの3行を足してから、いったん node_modules を消して入れ直します。

Node.js本体の版を上げる必要はありません。node-forgeが求めるNode.jsの条件は1.3.1の頃から変わらず「6.13.0以上」のままです。node-forge自身が使っている外部の部品もないため、更新で他の部品が引きずられることもありません。

本番へ反映する前に、署名の検証まわりが今までどおり動くかを確かめてください。1.4.0は「規格から外れたものを拒む」方向の修正なので、正しく作られた署名は通り続けます。動作が変わり得るのは、規格から少し外れたデータを扱っていた場合と、前の節で触れた入れ子の深さの上限に当たる場合です。

すぐに上げられないときの当座のしのぎ方

古い部品に縛られて更新できない場合について、CERT/CCが当座の対応を挙げています。

• 署名の検証を呼んでいる場所（forge.pki.publicKey.verify()、ed25519.verify()、トークン処理経由の検証）を洗い出す
• 可能な場所は、Node.js本体に備わっている crypto.verify() での検証に切り替える。プログラムの署名や本人確認のように、間違えられない場所を優先する
• 重要な処理では二重に確かめる。node-forgeで検証したうえで、Node.js本体の機能でもう一度確かめる

CERT/CCは、node-forgeの設定項目 _parseAllDigestBytes: true について、今回の欠陥の対策にはならないと明記しています。構造の厳密さも詰め物の長さも確認しないためで、これを入れて安心しないよう注意を促しています。

node-forgeとNode.js標準のcryptoはどう違うのか

Node.jsには最初から crypto という暗号の機能が入っています。こちらはOpenSSLという、C言語で書かれた広く使われている実装を呼び出しています。対してnode-forgeは、同じ処理をJavaScriptだけで書き直したものです。ブラウザの中でも動かせる代わりに、規格どおりに動くかどうかはnode-forge自身の作り込みに委ねられます。

今回の違いは、そこにはっきり出ました。開発元の変更履歴とCERT/CCの記述によれば、Ed25519の偽署名はnode-forgeでは通り、Node.js本体の crypto.verify() では拒否されました。RSAの偽署名も同じで、node-forgeだけが受け入れています。署名の検証をNode.jsの中で完結できるなら、本体の機能を使うほうが安全側に倒れます。

それでもnode-forgeが選ばれるのは、本体の機能では届かない場所があるからです。ブラウザの中で証明書を扱う場合、Node.jsの crypto は使えません。PKCS#12（.pfxファイル）の読み書きのように、本体に用意がない処理もあります。用途がこれらに当たるなら、node-forgeを1.4.0に保って使い続けるのが現実的な選択です。

別のものへ乗り換える判断をする場合も、自分のコードから呼び出しを外せるのは直接使っている分だけです。他の部品の内側に入っている61,456件分は、その部品を作っている側が対応しない限り消えません。乗り換えと更新は、どちらかではなく両方が要ります。

正規の入手先と、同じ名前の別のソフト

node-forgeの配布元は2か所だけです。npmのnode-forgeのページと、開発元のGitHubリポジトリdigitalbazaar/forgeです。npm install はnpmの倉庫から直接取ってくるので、ダウンロード用のサイトを探して手で落とす必要はありません。検索して出てきた見慣れないサイトからファイルを取る場面は、そもそも発生しません。

いま入っているものが本物かどうかは、次のコマンドで配布元の登録内容を確かめられます。

CDNから読み込んでいる場合

ブラウザ向けの配信サイトでは、cdnjsが「forge」の名前で配信しています。2026年8月20日の時点で最新は1.4.0です。ただし、読み込みタグのURLに版番号を書いて固定していると、古いものがそのまま配られ続けます。1.3.1のファイルは2026年8月20日の時点でも配信が生きています。

この読み込みは npm audit の対象外です。HTMLに書いた読み込みタグのURLを目で確認し、版番号の部分を1.4.0に書き換えてください。

なお「Forge」という名前は、まったく別のソフトにも使われています。ゲームのマインクラフトに機能を追加するための導入ツール「Minecraft Forge」は、この記事のnode-forgeとは無関係です。名前が似ているソフトの配布元を探している場合は、その製品の公式サイトを確認してください。

よくある質問

Q. node-forgeを直接使っていません。それでも関係しますか。

A. 関係する可能性は高いです。1.4.0に依存している64,275件のパッケージのうち、61,456件は「依存先の依存先」としてつながっています。npm ls node-forge で自分のプロジェクトに入っているかを確かめてください。

Q. 1.3.1のまま何年も動いています。急ぐ必要はありますか。

A. 1.3.1には公表済みの欠陥が7件残っており、うち6件は危険度が「高」です。実際に攻撃されている報告はありませんが、署名の検証を認証や証明書の確認に使っているなら、早めに1.4.0へ上げてください。

Q. 更新すると、これまで通っていた署名が通らなくなりますか。

A. 規格どおりに作られた署名は通り続けます。拒否されるようになるのは、規格から外れた形の署名です。合わせて、1.3.2以降はデータの入れ子の深さに256の上限が入っています。極端に深い構造を扱っているなら、本番反映前に読み取りを試してください。

Q. npm audit fix で直りますか。

A. 直接使っている場合は直ります。別の部品の内側に入っていて、その部品がまだ古い版を指定している場合は直りません。その場合はpackage.jsonの overrides で1.4.0以降を指定してください。

Q. ブラウザから読み込んでいます。どう確かめますか。

A. 配信サイトから読み込んでいるものは npm audit に出てきません。読み込みタグのURLに書かれた版番号を目で確認し、1.4.0に書き換えてください。

Q. Node.jsの版も上げる必要がありますか。

A. 必要ありません。node-forgeが求めるNode.jsの条件は「6.13.0以上」で、1.3.1の頃から変わっていません。

Q. TypeScriptで使っています。型定義も入れ替えが要りますか。

A. 型定義の @types/node-forge は本体とは別に配布されていて、版番号も別に振られています。2026年8月20日の時点で最新は1.3.14です。本体を1.4.0にしても、型定義の版が1.3系のままであること自体は問題ありません。今回の欠陥は本体側の処理にあり、型定義には含まれません。

Q. 次の版はいつ出ますか。

A. 予定は公表されていません。1.3.1から1.3.2までは3年8か月空きました。新しい欠陥が公表されたときに気づけるよう、npm audit を定期的に動かす仕組みにしておくのが確実です。

更新履歴

• 2026年8月20日：1.4.0で直った欠陥をCVE-2026-33896・CVE-2026-33891を含む4件に整理し、1.3.1以前が対象の3件（2025年11月公表）を追加。版ごとの早見表、確認コマンドの実際の出力、当座のしのぎ方、Node.js標準の機能との違いを追加。ダウンロード数を約3,190万回（2026年8月12日〜18日）に更新。1.4.0の公開日を2026年3月24日（npmの公開記録と開発元の変更履歴）に訂正。他の実装への影響について、CERT/CCの記載に合わせて「確認された」から「可能性がある」に修正
• 2026年7月16日：JVNとCERT/CCの公表を受けて公開

参照元

• ▸ Forge ChangeLog（開発元の変更履歴。1.4.0・1.3.3・1.3.2の修正内容）
• ▸ JVNVU#98998987 JavaScriptライブラリ「Forge」における複数の署名検証不備の脆弱性（2026年7月16日）
• ▸ CERT/CC VU#725167 node-forge Signature Forgery Vulnerabilities in RSA-PKCS and ED25519 Implementations（2026年7月15日公開）
• ▸ GHSA-ppp5-5v6c-4jwp（CVE-2026-33894 RSA署名の偽造）
• ▸ GHSA-q67f-28xg-22rw（CVE-2026-33895 Ed25519署名の偽造）
• ▸ GHSA-2328-f5f3-gj25（CVE-2026-33896 証明書チェーン検証のすり抜け）
• ▸ GHSA-5m6q-g25r-mvwx（CVE-2026-33891 計算が止まらなくなる）
• ▸ GitHub Advisory Database node-forgeの脆弱性一覧（2025年11月公表の3件を含む）
• ▸ NVD CVE-2026-33896（危険度9.1「緊急」としている評価）
• ▸ deps.dev node-forge（依存しているパッケージ数）
• ▸ npm node-forge（最新版とダウンロード数）
• ▸ CISA Known Exploited Vulnerabilities Catalog（2026年8月19日版で未登録を確認）