first_security_report

Posted on Mar 30, 2026

はじめに

卒業を控えた2月末、WordPressのプラグインから脆弱性を発見し、報告することができました。
今回は、脆弱性調査から実際に報告した流れを記します。
CVEが発行された場合はまた別の記事にでも書こうと思います。

きっかけ

Webセキュリティの脆弱性について触れることが多くなり、この学びをどこかに発散したかった。
そして、脆弱性の第一発見者になってみたかったから。
また、他校の卒業展にて未知の脆弱性の発見, 報告が題材の出展があり、お話を聞いたことが引き金でもあります。
特にRCEなどマシンを掌握する脆弱性についてはハッカー感が満載でロマンがあります。
密かに在学中にCVE採番を目指していました。

調査対象の選定

まずは調査したい対象のシステムを探します。
セキュリティに強いひとたちの話や、バグハンター記事を探すと、大きいコアシステムではなく、小さいサブシステムが穴場である。という情報を得ました。
それらを踏まえて、プラグインなどの小さい規模のプログラムに目を向けることにしました。
ただ、やみくもに調査することは時間が足りませんし、疲れてしまいます。
ユーザ入力を受け取る箇所と実際に発火する関数の箇所を見るほうが断然に楽です。

製品名は伏せますが、とあるWordPressのプラグインに着目しました。
例えば、以下のようなコードがあればかなり怪しいです。

<?php
if isset($_POST['user_input']) {
    $user_input = $_POST['user_input'];
}
else {
    $user_input = '';
}
?>

ユーザ入力をそのまま受け取って $user_input に格納しています。
ユーザ入力から何が渡されるかはわからないので、有害な文字列を受け取ってもおかしくないです。
例えば、;cat+%2Fetc%2Fpasswd# という文字列を受け取ってしまう場合を考えると、コード内部で shell_exec() や exec() や system() や passthru() などに $user_input を引き渡していると、PHPでOSコマンドインジェクションが成立してしまいます。

<?php
$user_input = ';cat /etc/passwd#'
$origin_name = 'test'
exec(mv $origin $user_input) // ファイル名を任意の名前に変更できる想定
?>

値を入れて組み立てると、以下のようになります。

<?php
exec(mv test ;cat /etc/passwd#)
?>

こうなると、 mvコマンドのフォーマットが崩れ、実行されなくなります。
その後、セミコロンから後のコマンドが解釈されて、 catコマンドが実行されます。
また、シャープはPHPにおける一行コメントアウトです。
exec関数がまだ後ろに続く場合、コメントアウトすることによって、エラーや別の処理を止めます。
このように、コードを眺め、$_POST や $_GET などのメソッドをどういった使い方をしているかを中心に調べて行きました。
また、WordPressはCSRFの対策を明示的にしないといけない(WordPress側にはセキュアな処理がない)ので、OSコマンドインジェクションとCSRFを探しました。

報告する機関

次に見つけた脆弱性を報告する窓口についてです。 今回見つけたプラグインはソースコードに SECURITY.md というマークダウンファイルが添付してあり、そこで指定されていました。
PatchStack と呼ばれる脆弱性報告プログラムに登録されており、プラグイン開発者でなく、セキュリティーベンダーに報告する形でした。

簡潔に伝える

脆弱性報告レポートの書き方についてです。
技術者向けに英語で書かなければ伝わりません。
また、直接開発したひとが読むわけではないので、再現手順は丁寧にしました。
実際の報告レポートやLLMの回答を参考に、フォーマットを洗い出しました。

完成したフォーマット

  • Title(タイトル)
  • Table of Contents(目次)
  • Overview(概要)
  • Vulunerabiliry Summary(脆弱性の概要)
  • Affecred Product Infomation(該当するプログラム)
  • Test Ebviroment(テストした環境)
  • Technical Details(技術的な詳細)
    • Source(ユーザー入力を受け付ける箇所)
    • Sink(ユーザー入力が実行される箇所)
  • Proof of Concept(PoC)
    • Step 1 xxx
    • Step 2 yyy
    • Step 3 zzz
  • Recommended Remediation(推奨する修正案)
  • CVE Request(CVE採番要求)
  • Contact Infomation(連絡先)

あとは忠実に項目を埋めていきます。 一番時間がかかったのは、PoCでした。 発見した脆弱性にはテクニックが必要だったので、それを一から説明すること、スクリーンショットを貼ってわかりやすく工夫して対処しました。
他人が書いたコードは読みにくいので、コメントアウトや意図をいれるように心がけました。