[wp-trac] [WordPress Trac] #54160: sanitize_key() / _wp_customize_include() is not able to handle non-scalar values

WordPress Trac noreply at wordpress.org
Wed Sep 22 07:47:50 UTC 2021


#54160: sanitize_key() / _wp_customize_include() is not able to handle non-scalar
values
--------------------------+------------------------------
 Reporter:  dd32          |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Formatting    |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------------------
Description changed by dd32:

Old description:

> On WordPress.org it's common to see PHP Warnings such as the following:
>
> > E_WARNING: strtolower() expects parameter 1 to be string, array given
> in wwp-includes/formatting.php:2140
>
> This is ultimately being triggered by a request similar to
> https://example.org/?customize_changeset_uuid[]=junk
>
> This query variable is not intended on containing an array, and the above
> warning is triggered by `_wp_customize_include()` calling `sanitize_key(
> array( ... ) )`.
>
> Either `_wp_customize_include()` should validate the input, or
> `sanitize_key()` should validate the input to the function. Normally I
> would lean towards the former, but in this case I think it might be
> better for the latter for where it's called in other contexts.

New description:

 On WordPress.org it's common to see PHP Warnings such as the following:

 > E_WARNING: strtolower() expects parameter 1 to be string, array given in
 wp-includes/formatting.php:2140

 This is ultimately being triggered by a request similar to
 https://example.org/?customize_changeset_uuid[]=junk

 This query variable is not intended on containing an array, and the above
 warning is triggered by `_wp_customize_include()` calling `sanitize_key(
 array( ... ) )`.

 Either `_wp_customize_include()` should validate the input, or
 `sanitize_key()` should validate the input to the function. Normally I
 would lean towards the former, but in this case I think it might be better
 for the latter for where it's called in other contexts.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54160#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list