SQLインジェクションは死んでいない――今も増加する古典的脆弱性とその対策

【なぜ重要か】 2026年7月、WordPressコアに認証不要のリモートコード実行を可能にするSQLインジェクション脆弱性が発見され、緊急パッチが適用された。推定5億以上のサイトが影響を受け得る事態であり、「SQLiは過去の問題」という認識がいかに危険かを改めて示した。GitHubアドバイザリーデータベースによれば、SQLインジェクションの報告件数は2023年の2,096件から2025年には2,850件へと毎年増加しており、日本のエンジニアやセキュリティ担当者にとっても無視できない現実である。

【ポイント】

• 件数は増加中：SQLインジェクション・コマンドインジェクション・パストラバーサルの3つで全報告の約1割以上を占め続けており、OWASPが2025年Top 10で5位に下げたのは問題が解決したからではなく、他カテゴリとの相対的な順位変動に過ぎない。CVE総数はインジェクション全体で60,000件超、SQL単体でも14,000件超に上る。
• ORMや既存フレームワークも完全ではない：DjangoのCVE-2024-42005のように、安全と思われていた組み込みメソッドがフィールド名を直接SQLに埋め込んでいた事例があり、「フレームワークを使っているから大丈夫」という思い込みが盲点を生む。
• AIコード生成ツールも同じ誤りを再現する：NYU/Cornellの研究ではGitHub Copilotが生成したコードの約40%が脆弱であり、ChatGPTを使った検証でも約12%がSQLインジェクション可能な結果となった。AIは脆弱なコードを含む公開コードで学習しているため、同程度の頻度で脆弱なコードを出力する。
• 静的解析（SAST）にも限界がある：今回のWordPress脆弱性は、不正なバッチリクエストによって内部処理が狂ったときのみ悪用可能となるクロスリクエストの相互作用を含んでいたため、静的スキャナーでは検出できなかった。最先端モデルが4つのエージェントを6時間稼働させて初めて発見された類の脆弱性である。
• ランタイム保護（RASP）が最後の砦：Aikido Zenはアプリケーション内部で動作するインアップファイアウォール（RASP）であり、ユーザー入力がDBクエリ等のデータシンクに到達する直前に攻撃ペイロードをブロックする。WAFがネットワーク層で不審な入力を遮断するのに対し、RASPはコードレベルで危険な入力を識別するため誤検知が少なく、依存ライブラリ経由の脆弱性にも対応できる。

【まとめ】 SQLインジェクションは「解決済みの古い問題」ではなく、件数・影響範囲ともに現在進行形の脅威である。根本対策としてはパラメータ化クエリの徹底・SAST/AIペンテストによる継続的な検出が不可欠だが、それだけでは不十分なケースが必ず存在する。ランタイム保護（RASPなど）を多層防御の一環として導入し、コーディング基準が届かない箇所もカバーする体制を整えることが現実的な次のアクションとなる。