Fatal Error caused by Uncaught TypeError: trim(): Argument #1 ($string) must be of type string, array given in /www/example_website/public/wp-includes/class-wp-query.php:803

[rlmc]

I found this in my error.log file on my web server. If I paste the same url onto my website, it does indeed cause a fatal error. Here is the full entry from the error.log file...the only change I made is to disguise my website as example.com:

2022/09/11 01:49:53 [error] 90419#90419: *4359495 FastCGI sent in stderr: "PHP message: PHP Fatal error:  
Uncaught TypeError: trim(): Argument #1 ($string) must be of type string, array given in /www/example_website/public/wp-includes/class-wp-query.php:803

Stack trace:
#0 /www/example_website/public/wp-includes/class-wp-query.php(803): trim(Array)
#1 /www/example_website/public/wp-includes/class-wp-query.php(1792): WP_Query->parse_query()
#2 /www/example_website/public/wp-includes/class-wp-query.php(3586): WP_Query->get_posts()
#3 /www/example_website/public/wp-includes/class-wp.php(648): WP_Query->query(Array)
#4 /www/example_website/public/wp-includes/class-wp.php(775): WP->query_posts()
#5 /www/example_website/public/wp-includes/functions.php(1330): WP->main('')
#6 /www/example_website/public/wp-blog-header.php(16): wp()
#7 /www/example_website/public/index.php(17): require('/www/example...')
#8 {main}
  thrown in /www/examplewebsite" while reading response header from upstream, client: 82.199.155.149, server: www.example.com, 
request: "POST /example_page?q=user%2Fpassword&name%5B%23post_render%5D%5B%5D=passthru&name%5B%23type%5D=markup&name%5B%23markup%5D=id HTTP/1.1", 
upstream: "fastcgi://unix:/var/run/php8.0-fpm-examplewebsitehhub.sock:", host: "www.example.com:61359"

[brookedot]

This recently came up in wp-includes/class-wp-query.php:1973 on a site I was working on. As the site was running WordPress 6.1, I am linking to the same line in 6.2 but the line number has changed
​https://github.com/WordPress/wordpress-develop/blob/6.2/src/wp-includes/class-wp-query.php#L2011-L2014

The URL passed looks like this:
www.example.com.com/tags/the-tage/?page[%24eq]=1

In this case, some bad actor seems to be trying to brute-force the URL. It appears the solution may be to add some additional validation on the page query to return if anything but a string on the trim.

Looking at the original report though, it seems there may be several places where adjustments need to be made.

Thoughts?

[SergeyBiryukov]

Hi there, thanks for the report!

I believe the original issue has been fixed in [53891] / #17737.

It looks like $q['page'] was not a part of that commit though, and needs a similar fix as per comment:2.

[brookedot]

Thanks for pointing me to the PR which fixes the original portion of this ticket @SergeyBiryukov!

I have created a PR over at GitHub to fix the $page portion, this is my first time doing a PR in GitHub instead of via SVN so let me know if I did it right.

​https://github.com/WordPress/wordpress-develop/pull/4920

This PR builds on the work completed with the closure of Trac-17737

It ensures that the value of $page in a query is scalar prior to attempting to trim or assign it to an absint avoiding a fatal error if an array is passed.

Fixes: (comment 2)

Trac ticket:https://core.trac.wordpress.org/ticket/56558

Edit: update first Trac link as the PR was associated with the wrong trac ticket.

Thanks for the PR! Left a minor comment, looks good to me otherwise 🙂

Thanks for the PR! Left a minor comment, looks good to me otherwise 🙂

Yep, I did briefly think about that ;)

[nicolefurlan]

@rlmc could you add testing instructions to this ticket?