Harden unserialize() with allowed_classes => ['stdClass'] and add override hook

[Copilot]

wp search-replace called unserialize() without restricting class instantiation, allowing arbitrary magic methods to execute on data retrieved from the database. This adds ['allowed_classes' => ['stdClass']] as the default, blocking instantiation of arbitrary user-defined classes while still allowing stdClass — a built-in PHP type with no magic methods that WordPress uses extensively for theme mods, widget data, and other serialized options.

Changes

• src/WP_CLI/SearchReplacer.php: Passes ['allowed_classes' => ['stdClass']] to unserialize() by default. The value is resolved once per SearchReplacer instance via a new filter hook:

  WP_CLI::add_hook( 'search_replace_unserialize_options', function() {
      return [ 'allowed_classes' => [ 'stdClass', 'MyPlugin\SafeClass' ] ];
  } );

• features/search-replace.feature:

  • Adds a scenario verifying the default behavior blocks user-defined class instantiation and the hook restores it for specific classes. The scenario uses a custom MyClass object stored directly via SQL to demonstrate that custom classes are converted to __PHP_Incomplete_Class by default (warning + 0 replacements), and the hook can allow them (1 replacement).
  • Updates the three PHP-version-specific mysqli_result scenarios — previously each PHP version triggered a different error path during object iteration/deserialization; with custom classes blocked by default, mysqli_result is never instantiated on any version, so all three now expect the same "Skipping an uninitialized class" warning and 1 replacement (from the malformed cereal_isation_2 entry which falls through to raw string replacement).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!