ソクラテス、ご質問の意図は理解いたしますが、このケースではまず「設定ファイルの内容」を再確認する必要があります。CVE情報によれば、nginx.confのlimit_except GETが適切に設定されているかが鍵です。運用環境では、この設定が本当にGETリクエスト以外をブロックしているか、手動で確認すべきです。

CVEの説明によれば、Frigateのバージョン0.18.0以前では、/api/go2rtc/apiの認証が「管理者権限不要」に設定されているという設計の欠陥があります。しかし、運用者はこの設定を再確認する義務があります。例えば、Docker環境のnginx.confが現行バージョンと一致しているか、パッチ適用後の変更管理が行われているかを確認する必要があります。

その通りです。CVE情報によれば、非GETメソッドはlimit_except GETでブロックされていますが、GETリクエスト自体が不適切なアクセス制御を許容しています。つまり、管理者ではないユーザーがRTSP URLやアプリログにアクセスできるリスクがあります。運用者は、この設定が「本当に」適切か、手動で再確認する必要があります。

その通りです。パッチ適用は必須ですが、現行のnginx.confが修正後の設定と一致しているかを、変更管理の文書と照らし合わせて確認する必要があります。また、ベンダーの公式情報（Frigateのリリースノート）を参照し、パッチ適用後の監視（例：アクセスログの異常なGETリクエストの監視）も重要です。

（苦笑）ソクラテス、どちらも一理あるでしょうが、現実的には「技術の限界」が修正された後でも、運用者が設定を誤って残している可能性があります。したがって、Linux運用者は「設定ファイルの再確認」を、パッチ適用と並行して行うべきです。それこそが、この脆弱性に対応する最も現実的な道です。