暗号ライブラリ『node-forge』に署名偽造の欠陥、偽の署名が本物と認められる恐れ CVE-2026-33894ほか v1.4.0へ更新を

世界中のアプリで使われているJavaScriptの暗号ライブラリ「node-forge」に、署名の検証をすり抜けられる欠陥が2件見つかりました。攻撃者が用意した「偽の署名」を、node-forgeが本物として受け入れてしまう恐れがあるという問題です。日本の脆弱性情報ポータルJVN（JVNVU#98998987）と、米CERT/CCのアドバイザリ（VU#725167）が2026年7月16日に公表しました。

node-forgeは週に約3,440万回ダウンロードされる、JavaScript界でもっとも広く使われる暗号ライブラリの一つです。自分で直接使っていなくても、別のライブラリの一部として知らないうちに読み込まれていることが珍しくありません。修正版のnode-forge 1.4.0はすでに公開されており、対策は更新するだけです。この記事では、何が起きるのか、自分のアプリが影響を受けるかの調べ方、更新の手順を順に説明します。

node-forgeとは何か、なぜ多くの人に関係するのか

node-forgeは、暗号化や電子署名、証明書の扱いといった「安全のための計算」をJavaScriptだけで行えるようにするライブラリ（部品）です。米Digital Bazaar社が開発しており、パスワードの暗号化、通信の保護、証明書の検証、電子署名の確認など、幅広い場面で使われています。

重要なのは、その普及の広さです。node-forgeは数多くのパッケージから依存されており、あなたが作ったアプリが直接node-forgeを呼んでいなくても、利用している別のライブラリが内部で使っている、というケースが非常に多いのです。今回のCERT/CCのアドバイザリでも、同じ種類の欠陥がnode-jose（トークン処理ライブラリ）やExpo、Adobeの証明書ツールなど複数の実装にまたがって確認されたと報告されています。

つまり、「自分は暗号のことなんて触っていない」と思っている開発者や企業でも、Node.jsのアプリを動かしているなら関係し得ます。だからこそ、今回の欠陥は影響範囲が広いと受け止めるべきものです。今回の問題は、OSS（無料で公開されているソフト部品）が別のソフトに次々と組み込まれて広がる「サプライチェーン」の典型例で、当サイトのOSSサプライチェーン スキャナーでも、こうした間接的な依存の危うさを扱っています。

何が起きたのか、署名偽造の2件

今回の2件は、いずれも「電子署名が正しいかどうかの確認」が甘いという問題です。電子署名とは、データが本物で改ざんされていないことを証明する仕組みです。受け取った側は署名を検証して「確かに正規のものだ」と判断します。その検証にすき間があると、偽の署名でも本物と誤認してしまうことになります。まず概要を表にまとめます。

CVE-2026-33894：RSA署名に「ゴミ」を混ぜて偽造できる

1件目のCVE-2026-33894は、RSAという方式の署名検証にある欠陥です。node-forgeは署名データの中身を厳密にチェックしておらず、決められた形式のすき間に無関係な「ゴミのようなデータ」を詰め込んだ偽署名を、正しい署名として受け入れてしまいます。特に、鍵の設定によっては（公開指数が小さい場合など）、攻撃者が本物の秘密鍵を持っていなくても偽の署名を組み立てられます。深刻度はCVSS 7.5（高）で、データの完全性（改ざんされていないこと）が損なわれる点が問題とされています。この手口は、過去にも複数の暗号ソフトで繰り返し見つかってきた古典的な弱点です。

CVE-2026-33895：Ed25519署名の「別の見た目」を許してしまう

2件目のCVE-2026-33895は、Ed25519という新しい方式の署名検証の問題です。本来、正しい署名には決められた範囲の数値しか使えないのに、node-forgeはその範囲を確認せず、範囲外の数値を使った「非正規の署名」も受け入れてしまいます。これによって、中身は同じでも見た目の異なる複数の署名が有効になってしまう（署名の可鍛性）という問題が起きます。認証の判定をすり抜けたり、署名そのものを識別の目印に使っている仕組み（重複排除やリプレイ対策）を混乱させたりするのに悪用され得ます。深刻度はやはりCVSS 7.5（高）です。

署名偽造が怖い理由

「署名の検証が甘い」と聞いてもピンとこないかもしれませんが、これは電子的な世界の「本人確認」がすり抜けられるということです。誰がどう悪用し得るのかを整理します。

狙えるのは、偽の署名を作ってアプリに送り込める攻撃者です。不正なログイン用のトークン、偽の証明書、改ざんしたデータなどに「それらしい偽署名」を付けて、正規のものだと信じ込ませようとします。

この欠陥を突くと、攻撃者はnode-forgeの検証を通り抜ける偽署名を組み立て、本来はじかれるべき偽のログインや偽の証明書、改ざんしたデータを「正規」と認めさせることができます。認証やアクセス権のチェック、配布されるプログラムが本物かの確認（コード署名）といった、安全の土台になっている判定が崩れる恐れがあります。

被害は、サービスを使うエンドユーザーにとっては「なりすましによる不正ログインやデータ改ざん」につながり、システムを運用する企業にとっては「不正なアクセスを正規と誤認したまま通してしまう」ことを意味します。今回はまだ実際の悪用は確認されていませんが、署名検証は多くのシステムの根幹にあるため、更新で穴をふさいでおくことが大切です。

自分のアプリは影響を受けるのか

影響を受けるのは、node-forge 1.3.3以前を使っていて、かつRSAやEd25519の署名検証を行っている場合です。ただし前述のとおり、直接使っていなくても間接的に読み込まれていることがあります。下の早見表と確認方法を参考にしてください。

自分のプロジェクトがnode-forgeを（間接的にでも）使っているかは、プロジェクトのフォルダで npm ls node-forge を実行すると分かります。表示されたバージョンが1.4.0より前なら対象です。どのライブラリが読み込んでいるかもこのコマンドの表示でたどれます。npm audit でも、既知の脆弱性として検出されます。

深刻度と実際のリスク

2件はどちらもCVSSという10点満点の深刻度で7.5、「高（High）」に分類されます。9.0以上の「緊急」ではないものの、署名検証という安全の根幹に関わるため、中程度の脆弱性より優先して対応すべきものです。一方で、現時点では実際に攻撃へ使われた形跡は確認されておらず、米政府CISAの「実際に攻撃されている脆弱性の一覧（KEV）」にも登録されていません。過剰にあわてる必要はありませんが、放置してよい類のものでもありません。

注意したいのは、実際のリスクが「node-forgeをどう使っているか」で大きく変わる点です。RSAの偽造（CVE-2026-33894）は、検証に使う鍵の設定（公開指数が小さいなど）によって成立しやすさが変わります。Ed25519の可鍛性（CVE-2026-33895）は、署名の見た目そのものを識別に使っている場合に影響が出ます。自分のシステムがどの署名方式を、どんな目的で検証しているかを合わせて確認すると、優先度を判断しやすくなります。

対策：node-forgeを1.4.0以降へ更新する

対策は、node-forgeを1.4.0以降に上げることです。この版で2件の署名検証の欠陥が修正されています（同じ版では証明書の制約チェックに関する別の不具合も直されています）。更新の進め方は次のとおりです。

• 直接依存している場合は npm install node-forge@^1.4.0 で更新する
• 間接依存の場合は、node-forgeを使っている親ライブラリ側を最新に上げるか、overrides（package.jsonの上書き設定）で1.4.0以降を強制する
• 更新後は npm ls node-forge で、すべての依存が1.4.0以降になったかを確認する
• 本番へ反映する前に、署名検証まわりの動作テストを行い、正規の署名が問題なく通ることを確かめる

なお、node-forgeを間接的に使っている他のライブラリ（node-joseなど）が、まだ古いnode-forgeを内部に抱えたままになっている可能性もあります。自分のプロジェクトのnode-forgeだけでなく、依存ツリー全体を1.4.0以降にそろえることが大切です。

技術的に見ると、なぜ偽造できたのか

CVE-2026-33894（RSA）は、署名の中身を表す「ASN.1」という構造の検証が緩かったことが原因です。RSAのPKCS#1 v1.5という方式では、署名データの前に一定以上の詰め物（パディング、8バイト以上）と、決められた形の情報（DigestInfo）が入っている必要があります。node-forgeはこの詰め物の長さを強制せず、余分なデータが紛れ込んでいても許していました。公開指数が3のような小さい鍵では、攻撃者はこのすき間に数字を調整して詰め込むことで、秘密鍵なしでも検証を通る署名を作れてしまいます。修正版では、パディングの最小長を強制し、DigestInfoの正しい形だけを受け入れて余分なデータを拒否するようになりました。

CVE-2026-33895（Ed25519）は、署名の後半にあたる数値「S」が、決められた範囲（0以上、群位数L未満）に収まっているかを確認していなかったことが原因です。範囲を超えた値（S＋k×Lのような形）でも計算上は検証を通ってしまうため、同じ意味の署名が複数存在できてしまいました。修正版では、Sが範囲内にあるかを確かめる関数を追加し、範囲外の署名をはじくようにしています。どちらも、開発元のセキュリティアドバイザリで修正内容が公開されています。

発見したのは誰か、波及範囲は

この2件は、カリフォルニア大学バークレー校のセキュリティ研究チーム（Austin Chu氏、Sohee Kim氏、Corban Villa氏）によって発見・報告されました。研究チームは同種の署名検証の甘さを、node-forge単体ではなく複数の暗号実装にまたがって調べており、CERT/CCがそれらをまとめて調整・公表しています。

CERT/CCのアドバイザリでは、同じ弱点がトークン処理ライブラリのnode-jose、アプリ開発基盤のExpo、Adobeの証明書ツールなどでも確認されたと報告されています。node-forge本体は2026年4月に修正版1.4.0を公開済みですが、今回のJVNとCERT/CCによる公表で、関連する実装も含めた注意が広く呼びかけられた形です。自分の使っているライブラリが影響リストに含まれていないか、あわせて確認しておくとよいでしょう。

よくある質問

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

A. 関係する可能性があります。node-forgeは他の多くのライブラリの内部で使われているため、間接的に読み込まれていることがよくあります。npm ls node-forge で自分のプロジェクトに含まれているか確認してください。

Q. すぐに更新すべきですか。

A. 実際の悪用はまだ確認されていませんが、深刻度は「高」で署名検証という安全の根幹に関わります。中程度の脆弱性より優先し、早めに1.4.0以降へ更新することをおすすめします。特に、認証トークンや証明書、コード署名の検証にnode-forgeを使っている場合は優先度が高くなります。

Q. 更新すると既存の署名が使えなくなりますか。

A. 正しく作られた正規の署名は引き続き検証を通ります。修正ではじかれるのは、規格に沿わない不正な形の署名です。念のため、本番反映前に署名まわりの動作テストを行ってください。

Q. 検査ツールで警告が出ました。

A. npm audit などで既知の脆弱性として検出されます。node-forgeを1.4.0以降にそろえれば解消します。間接依存の場合は親ライブラリの更新や上書き設定で対応してください。

まとめ

週に約3,440万回ダウンロードされる暗号ライブラリnode-forgeに、署名検証をすり抜けられる欠陥が2件（CVE-2026-33894・CVE-2026-33895）見つかりました。攻撃者が用意した偽の署名を本物と誤認する恐れがあり、認証やコード署名など安全の根幹に関わります。深刻度はどちらも「高（CVSS 7.5）」で、実際の悪用は確認されていないものの、放置してよいものではありません。

対策はnode-forgeを1.4.0以降へ更新することです。直接使っていなくても、他のライブラリ経由で読み込まれていることが多いため、npm ls node-forge で依存ツリー全体を確認し、古いバージョンが残っていないかをそろえてください。OSSが次々と組み込まれて広がる時代だからこそ、「自分が何に依存しているか」を把握しておくことが、いちばんの守りになります。

参照元

• ▸ JVNVU#98998987 - JavaScriptライブラリ「Forge」における複数の署名検証不備の脆弱性（2026年7月16日）
• ▸ CERT/CC VU#725167 - Signature Forgery Vulnerabilities in RSA-PKCS and ED25519 Implementations
• ▸ node-forge Security Advisory - RSA-PKCS signature forgery（CVE-2026-33894）（2026年3月24日）
• ▸ node-forge Security Advisory - Ed25519 signature forgery（CVE-2026-33895）（2026年3月24日）
• ▸ npm - node-forge