SQLiteの重大CVEがLLM生成の可能性、JFrogが検証結果を公表

虚偽CVEの疑い

セキュリティ企業JFrogの研究者が、SQLiteに関する複数のCVEが実際には存在しない脆弱性を報告している可能性を指摘しました。新規に作成されたGitHubリポジトリ「programmervuln/cveadvisory-」が、SQLiteを含む50件以上のCVEアドバイザリを公開したことが発端です。この中の一部はNVDによってCriticalと判定され、CISAのADPもそれに同意していました。

しかしJFrogが詳細に検証したところ、主張は崩れました。引用されたコードが対象バージョンに存在しない、PoCを実行してもクラッシュしない、SQLite公式の脆弱性ページにも掲載されていないなど、重大な不整合が確認されています。具体的には、コードの不整合、PoCの再現失敗、公式ページへの非掲載の3点が挙げられます。

検証で判明した問題点

JFrogは公式のSQLiteリポジトリをクローンし、対象バージョン（3.41.0、3.51.2、3.51.3）のソースコードと照合しました。例えばCVE-2026-51302では、脆弱性の原因とされる関数「exprComputeOperands()」がバージョン3.41.0には存在せず、後日追加されたものでした。CVE-2026-51303では、修正されたとされるバージョン3.51.3への差分の中に該当コードの変更がないことが確認されています。

また、CVE-2026-51300で引用された行番号はコメントやメモリ割り当ての行であり、脆弱性とは無関係でした。CVE-2026-51296に至っては、対象バージョンのjson.cは2706行しかないのに、3555行と3575行が引用されていました。いずれもPoCを実行しても異常は発生せず、メモリエラーも起きていません。

CVEプロセスの構造的問題

このような偽のCVEが通ってしまう背景には、CVE申請プロセスの仕組みがあります。MITREの公開フォームは身元確認がなく、誰でも脆弱性の説明とCVSSスコアを提出できます。かつてNVDが手動で分析・検証し、安全網として機能していましたが、2024年2月以降は大量の報告に押され、深い分析を事実上中断しています。

CISAなどのAuthorized Data Publishers（ADP）が補完を試みていますが、世界のパイプラインは断片化し、バックログが積み上がっています。PoCやバグの再現がどの段階でも必須ではないため、もっともらしい虚偽のアドバイザリがそのまま流れてしまう構造です。そのため、NVDのスコアがそのまま事実を反映しているとは限らなくなっています。

影響と注意点

虚偽のCVEは、セキュリティ対応の現場に実害を及ぼします。重大度が高いと自動で優先対応される環境では、存在しない脆弱性の調査やパッチ適用に人材と時間を浪費する恐れがあります。特にAIによる自動トリアージを導入している場合、存在しない関数を探して修正コードを生成するという誤った行動を引き起こす可能性があります。

JFrogの分析によれば、このGitHubアカウントが公開した55件のアドバイザリのうち、54件は完全に捏造されており、1件だけ実際のバグを含んでいたとのことです。新規の未知の企業からのCVEをむやみに信頼せず、公式の情報源と照合し、可能な限りPoCを再現するプロセスが重要です。セキュリティ運用では、情報の真偽を確認する仕組みを組み込む必要があります。