After updating WP Cerber (observed around the 9.7.x → 9.8.x update), the site started throwing a fatal error on every page load (since wp-cerber.php loads via wp-settings.php), and on plugin activation:
PHP Fatal error: Uncaught TypeError: array_merge(): Argument #1 must be of type array, bool given
in /wp-content/plugins/wp-cerber/cerber-settings.php:816
Stack trace:
#0 .../cerber-settings.php(816): array_merge()
#1 .../cerber-ds.php(892): crb_get_settings()
#2 .../cerber-load.php(133): require_once('...')
#3 .../wp-cerber.php(233): require_once('...')
Re-uploading/reinstalling the plugin files did not fix it — the identical error came right back, which pointed to a database issue rather than a files issue.
Root cause found: the wp_options row cerber_configuration was corrupted (not a valid/complete serialized PHP structure). In crb_get_settings(), crb_unserialize() returns false for this corrupted-but-non-empty value, so the $use_defaults fallback branch (crb_get_default_values()) never runs, and the code proceeds to array_merge( $cache, $defaults_pro ) with $cache === false, which is a fatal error under PHP 8+.
Workaround: back up and then delete the cerber_configuration row from wp_options, then reload/reactivate the plugin — it regenerates a clean cerber_configuration with defaults. General settings (firewall mode, login limits, notifications, 2FA config, etc.) have to be reconfigured, but data in other tables (cerber_blocks, cerber_acl, cerber_log, cerber_traffic, cerber_lab*, wp_cerber_files) is untouched.
This happened identically across multiple sites updated around the same time, which suggests the corruption is introduced by the update/migration process itself rather than by individual server/DB configuration. Could you take a look at what in the 9.7.x → 9.8.x migration path might be writing an invalid value to cerber_configuration?