古典的な脆弱性は消えていない。出る場所が変わった — 2026年8月22日の6件で読む40年史

2026年8月22日、Aikido Intelの日次レポートに新着として流れた脆弱性は29件。そのうちCritical/Highは6件だった（CVE自体の公開日は4月〜8月20日で、8月22日は日次に載った日である）。

一覧を眺めて気づくのは、「型」の欄に新しい言葉がひとつもないことだ。Path Traversal、XSS、Code Injection、Deserialization。どれも20年から40年、セキュリティの世界にいる古典である。

もちろん、新しい種類の脆弱性や攻撃面も生まれている。この記事が言いたいのはそこではない。古典的な型が、新しい技術の層にも繰り返し現れる、ということだ。6件をきっかけに「型」の歴史をたどり、最後に、1件ずつの深刻度だけを見ていると見落とす「合わせ技」の話をする。

1. Path Traversal — 1990年代のCGIから、2026年のサンドボックス基盤へ

「../」を使って許されていないディレクトリへ抜ける手口は、1990年代のCGIスクリプト時代にはすでに定番だった。世界的に知られるきっかけは2001年のNimdaワームで、IISのUnicodeディレクトリトラバーサルを踏み台に、数時間で世界中に広がった。

以来25年、CWE Top 25の常連である。一向に消えない理由は単純で、これは「バグ」というより「論理の穴」だからだ。言語やコンパイラでは防げない。ファイルパスという文字列をどう解釈するか、という設計判断の問題である。

今回の cap-primitives は、その皮肉を象徴している。このクレート（Rustでいうライブラリ／パッケージ）は、cap-std というRustのライブラリ群の土台で、目的はひとつ。「プログラムに、最初に渡したフォルダの中しか触らせない」ことだ。たとえば /data フォルダを渡したら、どんなパスを指定されても /data の外には出られない。そういう「鍵のかかった箱」を作るための部品である。

その箱に、外へ出られる穴が見つかった。手口そのものは昔の単純な「../」ではなく、末尾のスラッシュとシンボリックリンクの扱いをめぐる挙動の組み合わせで、アドバイザリ自身が Path Traversal（CWE-22）と Link Following（CWE-59）の両方に分類し、閉じ込めを完全に破れるとしている。だが「本来閉じ込めたディレクトリの外へ出られる」という型は同じだ。Rustという言語はメモリ破壊（古い型の筆頭）を仕組みごと消したが、「このパスは箱の外か内か」という判断の誤りまでは言語では消せない。守る側が積んだ最前線の層に、古典がそのまま再出現している。

2. XSS — 「軽い脆弱性」という感覚が一番通用しない場所で

Cross-Site Scriptingという名前が付いたのは2000年、Microsoftの命名による。2005年、MySpaceで「Samyワーム」が20時間で100万人超に広がり、XSSが「ブラウザの中で自己増殖できる」ことを世界に示した。OWASP Top 10でも長く主要項目として扱われ、2021年版ではInjectionに統合された。

それでも現場では、XSSは「他の脆弱性より軽い」と扱われがちだ。サーバーを乗っ取るわけではない、という理屈である。

今回の spring-security-oauth2-authorization-server は、その感覚が最も通用しない場所にXSSが出た例だ。内容は、既定の同意画面（Default Consent Page）が攻撃者の値をエスケープせずに表示するというもので、独自の同意画面を使っていれば影響しない。しかし認可サーバーとは、ユーザーが「このアプリにどの権限を与えるか」を判断する場所である。そこで攻撃者のスクリプトが動く。XSSは同じでも、出る場所によって意味が変わる。

3. Code Injection — eval() の時代からAIエージェントの時代へ

「データのつもりで渡した文字列が、命令として実行される」。この構図は1998年、rain.forest.puppyがPhrack誌でSQLインジェクションを紹介したときから変わっていない。PHPの eval() に外部入力を渡す事故が量産され、2015年にはPortSwiggerのJames Kettleがテンプレートインジェクション（SSTI）として体系化した。

今回の agno はAIエージェントのフレームワークで、スコアは98、今日の最高値だ。中身は意外なほど古典的で、FunctionCall（モデルが呼び出す関数）の引数にある field_type という値がそのまま Python の eval() に渡されていた。攻撃者がこの値に手を出せれば、任意のPythonコードが動く。分類もEval Injection（CWE-95）である。

つまり「AIだから新しい種類の脆弱性になった」のではない。モデルが関与するFunctionCallという新しい入口から、昔ながらのEval Injectionに到達した。AIエージェントという新しい実行基盤の中にも、結局 eval() という古典的な危険が残っていた、ということだ。

4. Deserialization — Javaが11年付き合い続けている問題

デシリアライズとは、ファイルや通信で受け取ったデータを、プログラムの中で使えるオブジェクトに組み立て直す処理のことだ。問題は、Javaではこの「組み立て直し」の途中で、受け取ったデータの指示どおりにプログラム側のコードが動いてしまう場合があること。攻撃者が細工したデータを送れば、組み立てているつもりで攻撃者の命令を実行している、という状態になる。

これが広く知られたのは2015年。1月の研究発表（Frohoff と Lawrence の「Marshalling Pickles」）で道筋が示され、11月に「どこにでも入っている部品（Apache Commons Collections）を使えば実際に動く」ことが公開されると、WebLogic、JBoss、Jenkinsなど主要なJava製品が軒並み該当した。

そして2026年8月、Springで2件。spring-graphql は条件が重なれば任意コード実行に至り、spring-integration-jdbc は攻撃者がDBのメッセージ格納列（INT_MESSAGE.MESSAGE_CONTENT）へ細工したデータを書き込めることが前提だが、そこから任意コード実行に至る。前提条件はあるにせよ、11年経っても、Javaエコシステムはこの型と決着がついていない。

5. 並べて見えること — 型は残り、場所だけが移る

CGI → Webフレームワーク → サンドボックス基盤 → AIエージェント。守る側が層を積むたびに、その新しい層に古典が再出現している。

この表にない古典もまだ現役である。SQLインジェクションは2008年のHeartland（カード情報1億件超）、2011年のSony Picturesと被害が続き、今も毎週のように新しいCVEが出る。メモリ破壊は1988年のMorrisワーム、1996年の「Smashing the Stack」、2014年のHeartbleedと40年の歴史があり、Rustはこれを消すために生まれた。SSRF（サーバーに代わりに取りに行かせる型）はクラウド以前は地味だったが、2019年のCapital One以降は花形になった。「置き場所で格が変わる」典型である。

6. 合わせ技 — 被害の大きさは1件のCVSSでは決まらない

ここからが本題かもしれない。

脆弱性の深刻度は1件ごとに付く。CVSSも、Aikidoのスコアも、1件を評価する数字だ。足し算も掛け算もできない。ところが歴史上の大きな侵入は、ほぼ例外なく複数の要素をつないで起きている。

• Samy (2005)：MySpaceのページに仕込んだスクリプト（Stored XSS）が、見た人のログイン済みブラウザで動き、その人の権限でプロフィール更新を実行した。XSSだけでは自分のページに細工が載るだけで増えない。「ログイン済みの権限」と「プロフィール更新機能」が揃って、見た人が次の感染源になった。
• Capital One (2019)：WAFの設定ミスで「サーバーに代わりに取りに行かせる」（SSRF）→ 向き先をAWSの内部アドレス（メタデータサービス）にして一時的な認証情報を入手 → その認証情報に付いていたIAMロールの権限が広すぎて、S3のデータ1億件を読めた。SSRFだけなら何も盗れない。権限が絞られていれば1億件にならない。3つ揃って初めて大事故になった。
• Webシェル設置の定番：ファイルをアップロードできる（画像投稿など）＋保存先のパスをずらせる（Path Traversal）。画像フォルダでなく、Webサーバーが実行してしまう場所に置けた時点で、そのサーバーは攻撃者のものになる。

今日の6件に当てはめるなら、公開情報から「この2件は直接つながる」と言える組み合わせはない。だからこそ問うべきは、1件ごとの点数ではなく、次の3つだ。

1. agno の eval() が動く先は、社内のどのAPIやデータにつながっているか。コード実行は終点であると同時に、他のすべての入口になる。
2. 認可サーバーの同意画面は既定のままか。そこで何を扱っているか。
3. spring-integration-jdbc のメッセージ格納列に、誰が書き込めるか。前提条件が「自分の環境では満たされていないか」を確認するのが脆弱性管理である。

「うちはHighが3件あるがCriticalはない」は、安心材料ではない。深刻度は部品の点数であって、組み立て後の点数ではない。

おわりに

40年分の歴史を6行の表に圧縮すると、対策技術は確実に進歩しているのに、古典的な型は一つも退場していない、という事実が残る。新しい技術が登場しても、古い脆弱性が消えるわけではない。同じ型が、新しい場所に移って現れる。そして本当の危険度は、その脆弱性が何と隣り合っているかで変わる。

だから脆弱性管理で問うべきは「このCVEは何点か」だけではない。「この型は、うちのどの層に、他の何と隣り合って出ているか」である。

---

参考（一次情報）

• Aikido Intel: https://intel.aikido.dev
• CVE-2026-35002 / GHSA-hp8f-xmx4-4qrg / CVE-2026-59324 / CVE-2026-59316 / CVE-2026-59285 / CVE-2026-59307