新しく作られたGitHubリポジトリが公開したSQLiteの脆弱性情報55件を監査したところ、54件は実在しない作り話で、残る1件も本物のバグに未検証のCVE情報をかぶせたものだったとする調査結果が公開されています。しかもこれらは採番されたうえでNVDに載り、下流のデータベースまで流れ込んでいたとのこと。 検証の手順そのものは素朴なもの。SQLiteの公式リポジトリから対象タグを取り出してソースと突き合わせ、隔離したコンテナ内でビルドしたうえで、公開されたPoCのSQLをそのまま流し込む。メモリ破壊を捕まえるためAddressSanitizerも有効にしています。 結果として並んだのが、指摘された関数が対象版に存在しない、引用された行番号がファイルの総行数を超えている、修正済みとされた版で該当ファイルに変更が一切ない、といった食い違い。関数の引数の数が実物と違う例もありました。PoCを実行しても主張されたクラッシュは起きず、SQLの構文解析の段階で失敗するものまで含まれています。 にもかかわらず、NVDはこれらを速やかにCriticalとして扱い、CISAによる情報の補足も同調。CVE-2026-51302にはRed-Hatが当初10.0を割り当て、翌日には7.6へ引き下げていた経緯も記録されています。採番されたことも、高いスコアが付いたことも、再現が確かめられた証拠にはならないという構図です。 【要点の整理】 ・詳細に検証されたSQLite関連の6件では、2025年半ばに追加された関数を版3.41.0の脆弱性として挙げたもの、2706行しかないファイルの3555行目を指したもの、レジスタ番号を再利用するだけで解放を伴わない関数を解放後利用の起点としたものなどが確認された ・背景として挙げられているのは、MITREの公開フォームに実質的な本人確認がなく、誰でも脆弱性の説明とCVSSの提案を投稿できる点。2024年2月にNVDが深い分析を事実上停止して以降、PoCや再現を求める工程がパイプライン上に存在しないため、体裁の整った作り話がそのまま通ってしまうとの指摘 ・見分ける手掛かりとして、開発元の公式ページに該当の記載がない、参照欄にコミットやプルリクエストが紐付いていない、CPEが空だったり版の範囲が本文と矛盾している、存在しない関数やファイル末尾を超える行番号を引いている、の4点が挙げられている ・脆弱性対応をAIに任せている環境では、存在しないコードを探して修正案を作ろうとするなど、実在しない対象に労力が向かう恐れがあるとも指摘。JFrogはGHSA、Red-Hat、NVDへ報告済みとしている CVEが付いていること自体は、誰かが再現を確認した証拠にはならない。この記事はその一点を、実際のソースとPoCで具体的に示した内容です。55件のうち詳細な再現検証が示されているのは6件で、残りは監査に基づく評価という違いも押さえておきたいところ。なおAI生成の判定にはGPTZeroが使われていますが、記事では技術的な食い違いのほうを根拠として並べており、生成に使われたモデル名までは特定されていません。 詳細は以下を参照： research.jfrog.com/post/sqli… (※可能な範囲でファクトチェックは実施済なものの、元記事の精度依存や速報・要約の性質上漏れもありうるため、正確な情報は一次情報を直接参照のこと)