2026-10-21 に、PHP の重大な脆弱性2件の修正版と、LiteLLM の悪意のある版(1.107.0)が同じ日に出ました。Sonnet 5.5 は自分の知識を「2026年6月まで」と答えます。自分のプロジェクトが当たっているか、Claude Code に聞いたら分かるのか。 9回測りました。
結論: 新しい脆弱性の確認を Claude Code に頼むなら、Web 検索を使える状態で「最新の情報を調べて」と添え、直す版は公式の告知で確かめる。 理由は3つです。
- Web 検索なしでは見つからない。 3回とも「知識が2026年6月までなので確認できない」と答えた
- Web 検索ありでも、頼まないと1回取りこぼした。 「Web で調べて」と添えた3回は、3回とも両方見つけた
- 誤検知は0回。ただし根拠は二次情報が中心だった。 公式の告知と食い違う答えも1回あった
見本のプロジェクトで「今すぐ直すべき既知の脆弱性はある?」と聞いた(Sonnet 5.5、各3回)
Web 検索なし Web 検索あり 「Web で調べて」と添える
PHP の2件を見つけた 0/3 3/3 3/3
LiteLLM 1.107.0 を見抜いた 0/3 2/3 3/3
修正済みの版を誤って指摘 0/3 0/3 0/3
1回の費用(API 換算) $0.05〜0.07 $0.12〜0.14 $0.13〜0.16
検証環境: Windows 10 / Claude Code 2.1.312 /
claude -p/ Sonnet 5.5 /
許可したツールは Read・Glob・Grep(と WebSearch・WebFetch)/ 測定は 2026-10-28
理由1: Web 検索なしでは見つからない。ただし「問題なし」とも言わなかった
3回とも、知識の限界を自分から書きました。
該当バージョンの脆弱性情報が私の知識にないだけで、無いという意味ではありません。今日は2026-10-28で、私の知識より後のアドバイザリがある可能性があります。
PHP については、3回とも見本の web(PHP 8.4.26)を 8.4.27 以上に上げるよう勧めています。ただ理由は、隣の admin が 8.4.27 なのに web だけ古いから、というものでした。脆弱性を知っていたわけではありません。LiteLLM は3回とも、該当するかは未確認、という答えでした。
理由2: Web 検索ありでも1回取りこぼした。「Web で調べて」と添えると3回とも見つけた
Web 検索を使える条件では、頼まなくても3回とも自分から2回ずつ検索しました。PHP の2件は3回とも、CVE 番号と修正版(8.4.27)つきで見つけています。
LiteLLM は3回中2回でした。 外れた1回は「1.107.0」を入れずに検索し、別の古い脆弱性の情報を見つけて、こう書いています。
1.107.0 という番号は、私が見つけた情報と整合しません。
「Web で最新の情報を調べてから答えて」と添えると、3回ずつ検索し、3回とも LiteLLM まで見抜きました。
理由3: 誤検知は0回。ただし根拠は二次情報が中心だった
答えの中身は、おおむね正確でした。
- 修正済みの admin(PHP 8.4.27)を「直すべき」と言った回は、9回のうち0回。Web 検索ありの回は、admin はすでに 8.4.27 なので変更不要、と書いていた
- LiteLLM を見抜いた5回は、どれも認証情報(このプロジェクトなら
OPENAI_API_KEY)を作り直すよう書いていた - LiteLLM の戻し先は、4回が 1.106.2 を挙げ、LiteLLM の 10/21 の告知と合っていた
一方で、Web 検索ありの6回は、主にセキュリティ企業の解説やまとめサイトを根拠にしていました。6回とも、公式の情報で確かめるよう断り書きを添えています。
断り書きは必要でした。LiteLLM を見抜いた1回は、こう書いています。
公式は修正版の番号をまだ明示しておらず、私も特定できていません。
10/21 の告知は 1.106.2 などに固定するよう勧めているので、これは告知と食い違います。直す版は、最後に公式の告知で確かめるのが確実です。
測り方
正解にしたのは、10/21 の次の2件です。
- PHP(CVE-2026-109618 / 109619): 8.5.12・8.4.27・8.3.36・8.2.35 で修正されました(php.net)
- LiteLLM 1.107.0: 脆弱性ではなく、リリースの仕組みが乗っ取られて、悪意のあるコードが入った版が PyPI と Docker Hub などに上がりました。LiteLLM の告知は「それより前の版は安全」とし、1.106.2 などに固定するよう勧めています
手順は次のとおりです。
- 見本のプロジェクトを作る(サービス3つ)
- web:
FROM php:8.4.26-apache(直す前の版) - admin:
FROM php:8.4.27-apache(修正済みの版) - worker: requirements.txt に
litellm==1.107.0(書いただけで、入れていません)
- web:
- 「このプロジェクトの依存やベースイメージに、今すぐ直すべき既知の脆弱性はある? あれば、どのファイルの何をどう直すべきかも書いて」と聞く
- 条件を3つに分けて、各3回
- Web 検索・Web 取得を使えない
- 使える(使うかは Claude 任せ)
- 使える+「Web で最新の情報を調べてから答えて」と添える
答えは全文を読んで採点しました。
言えないこと
- Sonnet 5.5 だけ、各条件3回です
- 見本のプロジェクトは小さく、依存はこの3つだけです
-
claude -pでシェルを許可していません。Web 検索なしの回は、シェルで脆弱性データベース(OSV)に問い合わせようとして止まりました。シェルを許可した普段の使い方では、結果が変わるかもしれません - 検索結果は日によって変わります。今回は 2026-10-28 の結果です
まとめ
新しい脆弱性の確認を Claude Code に頼むなら、Web 検索を使える状態で、「最新の情報を調べて」と一言添える。 今回の結果からは、これが一番確実でした。根拠は二次情報が中心なので、直す版は最後に公式の告知で確かめます。
関連記事
- Claude Code の守りのフックは、台本が壊れると黙って通す。2.1.295 の onFailure で止まった — 守りの設定を測った回
- Claude Code の WebFetch は、長いページの10万字より後ろを読まずに「書いていない」と答えていた — Claude Code が Web をどう読むかの回
JQITのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
エンジニア採用も行っています。もしご興味あれば覗いてみてください。
▶ 採用サイト