WP Cerber Security 9.7.3

English version: WP Cerber Security 9.7.3

アルテミス2号がすでに月面から帰還の途上にある今こそ、我々自身のシステムを徹底的に見直す絶好の機会だと感じた。もし我々が未だにサーバーログに記録された回避可能な警告を追いかけている間に、我々のヒーローたちが地球に帰還してしまうとしたら、それは実に気まずい状況だ。

そこで私たちは、地味な作業に注力しました。具体的には、設定時の検証を強化したり、準備状況ウィジェットの診断機能を改善したり、本来必要のないところで静かにノイズを発生させていたエッジケースを整理したりしました。

プラグイン設定における正規表現パターン検証

ファイアウォールパスの除外、ログの除外、スパム対策の除外など、正規表現パターンを受け入れるすべてのWP Cerber設定において、 「保存」をクリックした瞬間にパターンの構文が検証されます。パターンにタイプミスや不均衡なグループが含まれている場合、設定ページに、問題のあるパターンを具体的に示す明確で分かりやすいエラーメッセージが表示されます。入念に作成した除外ルールが本番環境で「なぜ機能しないのか」と悩む必要はもうありません。無効なパターンは、設定エラーが発生する前に検出されます。

バグ修正

スラッシュを含む正規表現パターンが動作するようになりました

「これらの場所をログに記録しない」トラフィックインスペクター設定で、スラッシュを含む正規表現パターン（例： /api/v2/callbackのようなURIに一致させるパターン）を使用した場合、パターンがサイレントに失敗したり、PHP警告（ preg_match(): Unknown modifier ）が発生したりすることがありました。根本原因は、以前のコードで正規表現の区切り文字として/使用していたことです。このバグを修正しましたので、パターン内のスラッシュは意図どおりに動作するようになりました。

存在しない地域への翻訳ダウンロードが失敗しなくなりました

WordPressの設定によっては、i18nサブシステムが、実際にはリポジトリに翻訳ファイルが存在しないロケールを誤って識別してしまうことがありました。そのため、アップデート時に「WP Cerber Security (haz) の翻訳を更新中… ダウンロードに失敗しました。見つかりません。」という誤ったエラーメッセージが表示されていました。WP Cerberは、ダウンロードを開始する前に翻訳リポジトリにロケールが存在することを確認するようになったため、この誤検出は完全に解消されました。

サーバーエラーログメッセージを削除しました

特定の条件下でサーバーのエラーログにノイズが発生する可能性のある、一連の特殊なケースを特定し、解決しました。

• preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated – PHP コードのコメント削除ルーチンがマルウェアスキャンまたはファイアウォール検査中に null 値を受け取った場合に発生しました。この関数は現在、厳密な文字列型付けを強制します。
• Constant CRB_DOING_BG_TASK already defined – WordPress が同じリクエスト内で日次スケジュールタスクを複数回実行した場合に発生する可能性があります。タスクランナーは、定数を定義する前にその存在を確認するようになりました。
• Attempt to read property "ID" on null – コメントフォームの reCAPTCHA フィルターが実行された時点で、グローバルオブジェクト$postがまだ利用できないページで発生していました。現在は、プロパティにアクセスする前にオブジェクトが存在することを確認するようにしています。
• Call to undefined function curl_init() – cURL 拡張機能が利用できないサーバーでは、クラウド通信モジュールが cURL セッションの初期化を試みる前に関数の存在チェックを実行するようになり、この致命的なレベルのメッセージが表示されないようになりました。
• Undefined array key "primary_ip" / Undefined array key "local_ip" – クラウド API リクエストから返された cURL 情報配列にこれらのキーが含まれていない場合に発生しました。現在は両方とも null 合体演算子を使用してアクセスされるため、通知は表示されなくなります。

バージョン9.7.3では、より厳格な設定検証を実施し、表面的なPHP警告を排除することで、日々のトリアージ時間を直接的に短縮します。サーバーログがよりクリーンになり、誤検知が減り、WordPressサイトが安定性、予測可能性、そして高度に最適化されたセキュリティフレームワーク上で稼働しているという安心感を得られます。