再現手順（概念的な PoC — 実行可能なペイロードは含まれません）

1. Smart School に accountant、admin、または superadmin ロールのユーザーとしてログインします。
2. Download Center → Upload Share Content に移動します。
3. アップロード / 共有ワークフロー中に HTTP リクエストを（例：Burp などのプロキシを使用して）傍受します。
4. ファイル名が .php で終わるファイルをアップロードします（サーバー側のチェック / フィルターは、通常のファイルタイプ検証を通じて PHP アップロードをブロックしようとします）。
5. 同じアップロード / 送信リクエストで、代替の YouTube URL フィールドにも値を入力します（YouTube オプションを処理するロジックパスが、アップロードされたファイルの受け入れと保存を誤って許可します）。
6. 共有 / アップロードフローを完了し、サーバーの応答を確認するか、返された保存ファイルパスを観察します（アプリケーションが保存パスを公開します）。観察された保存パスパターンの例: /uploads/school_content/material/media/!file.php
7. 返された URL を介して保存された .php ファイルにアクセスし、コード実行をトリガーします（ファイルに実行可能な PHP コードが含まれている場合）。

概念実証（高レベル）

• 脆弱なフローを介してアップロードされた PHP ファイルは、Web アクセス可能なディレクトリに書き込まれ、HTTP で直接呼び出すことができます。
• この脆弱性はロジック / 検証バイパスです（代替の YouTube URL コードパスが、通常のアップロードフローと同じ厳格なファイルタイプ制限を適用できていません）。

緩和策 / 推奨される修正

ベンダー側の修正（推奨）:

1. ロジック欠陥を修正し、代替の YouTube URL パスおよびその他の特殊なアップロードパスが、通常のアップロードフローと同じファイルタイプ検証とフィルタリングを適用するようにします。また、YouTube URL が有効 / 存在するかどうかも確認します。
2. アップロードされたファイルの実行をブロックするため、アップロードされたコンテンツを Web ルート外に保存するか、サーバー側コードを決して実行しない安全なハンドラーを通じてアップロードを提供します。
3. サーバー側の MIME タイプと拡張子チェックを実施し、ブラックリストではなく許可されたファイルタイプのホワイトリストに対して検証します。
4. 保存されたファイルを安全な拡張子にリネームし、元の拡張子を保持せずに名前をランダム化します。
5. 正しいサーバー権限を設定し、アップロードされたファイルが実行可能にならないようにします（例：chmod で実行権限を削除、アップロードディレクトリで PHP を実行しないように Web サーバーを設定）。
6. 不審なアップロードとアップロードされたファイルへのアクセス試行のログ記録と監視を追加します。
7. ロールベースの制限を適用 — コンテンツのアップロードを許可するロールを厳格化し、特権ロールには追加の検証を要求します。

管理者向けの回避策:

• 可能であれば、問題のあるアップロード / 共有機能を一時的に無効化します。
• アップロードアクセスを少数の信頼できるアカウントに制限します。
• /uploads/... ディレクトリでの .php の実行を禁止するように Web サーバーを設定します。

参考情報

• 報告されたデモインスタンス: https://smart-school.in/demo
• MITRE CVE ID 予約済み: CVE-2025-60500