それは、管理者が「セキュリティの壁」を自ら壊しているようなものです。カスタムPHPハンドラが設定されていて、reCAPTCHAが無効なら、誰でもサーバーに好きなコードを叩き込むことができるのです。確認すべきは、まず拡張機能のバージョンが2.4.3.2未満か、カスタムハンドラが設定されているか。それと、reCAPTCHAが有効になっているか——これが命綱です。

影響は限定的ですが、リスクは極めて高いです。まず、phpのバージョンや拡張機能のデプロイ方法を確認してください。パッチは公式サイトから入手し、変更管理の記録を残すことが肝心です。また、この脆弱性が発見された日時を確認し、過去のアップデート履歴と照らし合わせてください。

監視の対象は「異常なPHPコードの実行」です。例えば、ログに予期しないeval()呼び出しが記録されていないか、またはフォーム送信後に異常なリクエストが発生していないか。また、ベンダーの公式情報に目を向けて、彼らがパッチを提供しているかを確認してください。

カスタムハンドラの設定が「オプション」であるため、開発者や運用者が気づかない可能性があります。また、reCAPTCHAが無効な状態が長期間続くケースも考えられます。定期的な設定確認と、拡張機能の使用状況のレビューが重要です。

「セキュリティの責任は、常に運用者にある」ということです。パッチは「他人に任せきり」にせず、自分で確認し、変更管理を徹底してください。また、ベンダーの情報に依存しすぎず、自社の環境に合った対策を講じましょう。——さもなくば、次のニュースで「Joomlaのフォームがまた悪用された」なんて、笑い話では済まされないでしょう。