WP Cerber Security 9.9.3

At a Glance

We built version 9.9.3 around correctness in the places you rely on when something goes wrong. This release repairs how WP Cerber behaves during fatal PHP failures, fixes IPv6 range matching in the Access Control Lists, and makes admin notices render in your own language.

Key Highlights

Fatal PHP failures are handled correctly again. When our error logging was active, an uncaught failure could silence the WordPress critical-error page and the Recovery Mode email. We fixed that.
Diagnostics you can trust. The fatal error that actually terminated a request now reliably reaches the Traffic Inspector log, keeping your forensics accurate.
IPv6 ranges behave deterministically. Valid ranges in dash or wildcard notation are no longer rejected, and range boundaries now match inclusively.
Admin notices in your locale. Messages generated by unattended background requests are now translated at the moment you read them, not at the moment they were created.

Security Changes

IPv6 range matching in the ACL is fixed. Our range parser compared the lower-order chunks of an IPv6 address even when the leading chunks had already established the correct order. As a result, some perfectly valid IPv6 ranges specified in dash or wildcard notation were rejected when you added an Access Control List entry or filtered records in the Activity and Traffic log viewer. The parser now compares the remaining chunks only when both boundaries share the same leading chunk, while reversed and zero-length ranges are still rejected. Your ACL now accepts every valid range you throw at it.

IPv6 range boundaries are now inclusive. We fixed the boundary comparison so that the first and last addresses of an IPv6 range are treated as part of the range. Access decisions across the entire range are now deterministic, edge addresses included.

Admin Experience

The email sending issue message is now translated at render time. On a non-English website, the notice about a failed email could appear in the locale of the request that failed to send it, which is usually an unattended request such as a scheduled report or a visitor-triggered alert. The message is now resolved in the administrator’s locale at the moment it is displayed.

Settings recovery messages are now localized correctly. If the plugin settings were corrupted on a non-English website, the recovery report was shown to the admin untranslated. We were not happy with that either. The message is now rebuilt and translated when it is rendered, in the locale of the administrator reading it.

Readiness widget messages received a proper i18n implementation. Several messages in the widget were missing localization and could not be translated. That gap is closed.

Reliability Improvements

Faster database layer on hot paths. We reduced identifier validation overhead in our query builder by replacing regex-based checks with a lightweight character scan. Frequently executed database operations are now more efficient, and the existing validation rules and query behavior are fully preserved.

Smarter handling of reported issues. The registry that powers admin issue notices can now re-evaluate each issue just before it is shown, update it, or drop it entirely once it is resolved. Importantly, we designed the failure path first: an error during that step never hides an issue from you.

Compatibility testing. We tested this release with PHP 7.4.33, 8.0.30, 8.1.34, 8.2.33, 8.3.33, 8.4.24, and 8.5.9, and with WordPress 5.8.14, 6.6.6, 6.7.6, 6.8.7, 6.9.6, and 7.0.3.

Bugfixes

Uncaught fatal failures no longer bypass WordPress recovery. This is the most consequential fix in the release. When error logging was active and an uncaught Throwable occurred, such as an unhandled exception, a type error, or a parse error, our handler terminated the normal PHP fatal-error processing. That could prevent WordPress from showing its critical-error page, sending the Recovery Mode email, or reverting a broken PHP edit made through the built-in plugin or theme editor. Affected failures could also be missing from debug.log when WP_DEBUG_LOG is enabled. Non-fatal PHP errors were never affected by this bug.

Fatal errors now reliably reach the Traffic Inspector log. Not all PHP errors were being logged. Our own shutdown routines perform database and network operations that may produce additional diagnostics, and since PHP keeps only a single last-error slot, a later warning could replace the fatal error that terminated the request. We now snapshot the last error at the very start of our shutdown callback, so our own housekeeping can no longer overwrite it. In the spirit of transparency: shutdown callbacks registered by other code before ours may still modify the last error before we run.

Quick navigation no longer emits PHP warnings. Multi-value query parameters could reach scalar string comparisons in the quick navigation block, producing Array to string conversion warnings. Depending on your PHP error configuration, these warnings could pollute logs, appear in the admin output, or corrupt an AJAX response.

The bottom line

Version 9.9.3 makes failures predictable and diagnostics trustworthy. Fatal errors now reach both WordPress recovery tools and our logs, so triage starts from accurate data. IPv6 ranges work correctly in the ACL and in log filters. Admin notices appear in your own language, exactly when and where you read them.

Wonder what WP Cerber got in the previous version?

Review the release note for WP Cerber Security 9.9.

How to update WP Cerber

We recommend enabling automatic updates to ensure you always have the latest security features and performance improvements: how to enable automatic updates in the plugin settings.