[buddypress-trac] [BuddyPress Trac] #9065: PHP 8 Fatal error: Malformed inputs can cause fatals.

[buddypress-trac]

#9065: PHP 8 Fatal error: Malformed inputs can cause fatals.
--------------------------+-----------------------------
 Reporter:  dd32          |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Core          |    Version:
 Severity:  normal        |   Keywords:
--------------------------+-----------------------------
 A number of buddypress pages/routes/views use `stripslashes()` on the
 input, when coupled with malformed input this causes warnings such as this
 in PHP 7.4, and fatals in PHP 8.1:

 > PHP 7.4 E_WARNING: stripslashes() expects parameter 1 to be string,
 array given in plugins/buddypress/bp-blogs/bp-blogs-template.php:178

 > PHP 8.1 Fatal error: Uncaught Error: stripslashes(): Argument #1
 ($string) must be of type string, array given in plugins/buddypress/bp-
 blogs/bp-blogs-template.php on line 178

 Replacing the calls to `stripslashes( $_REQUEST[...] )` with `wp_unslash(
 ... )` will **partially** resolve this, as it'll cause arrays (the most
 obvious incorrect input usually) to be handled correctly, and the invalid
 data passed to the underlying classes to usually be handled incorrectly.

 Eg:
 > GET https://example.org/sites/?Search&sites_search[foo]=bar

 If we use the example warning/fatal above, and replace it with
 `wp_unslash()` we then end up with a warning/fatal of this instead:
 > Fatal error: Uncaught Error: addcslashes(): Argument #1 ($string) must
 be of type string, array given in wp-includes/class-wpdb.php on line 1785

 This is ultimately because `bp_esc_like( $array_data )` is then called
 which is incorrect use of the function. The sanitisation of the input is
 still not handled right, but is a step forward towards the correct
 handling of the data.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/9065>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac