Having a malformed post type query in $_GET or $_POST yields a critical error

[hheuzebrutc]

Steps to reproduce:

• Go to a fresh install's homepage
• Add ?attachment[foo]=bar to the url
• press enter

With the "attachment" post type, only the front page will crash, other pages will yield a 404. However, doing this with any custom post types the site might have can crash any page (as long as the post type is public).

What's especially annoying for me is it also works with $_POST. If I make a form with an input name like public_post_type[sub_array], the site crashes upon submission and my form is never processed.

[mindctrl]

Hi @hheuzebrutc, welcome to Trac and thanks for the report!

I am able to reproduce the fatal error.

I'm not sure how common this is, but attachment is supposed to be a string, as it's used to fetch an attachment by slug/post_name. It looks like type validation is handled mostly in WP_Query::parse_query(), but attachment isn't checked properly. We probably need an is_scalar check, like what is done with subpost (which, if provided, gets assigned to attachment).

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

## Summary
This ignores non-scalar values when sanitizing post_type query vars in WP::parse_request(), preventing malformed array input from surfacing PHP warnings during front-end requests.

## Testing Instructions

1. Request /?post_type[][]=page&post_type[]=post on a local site with WP_DEBUG_DISPLAY enabled.
2. Confirm no warning is emitted before the page output.
3. Run npm run test:php -- --filter Tests_WP_ParseRequest.

[westonruter]

Replying to hheuzebrutc:

• Add ?attachment[foo]=bar to the url

How did you come to add this to the URL?

[hheuzebrutc]

Well at first I wasn't touching the URL at all, as mentioned above I was making a custom form as a shortcode, with several input fields grouped together in an array that happened to have the same name as one of my custom post types, something like post_type[input_name]. And no matter what I did, WordPress Core always crashed before my form had a chance to be processed. I figured it was something to do with query vars and tried it with the URL as well. I chose attachments in my example because as far as I can tell, it's the only public post type that's guaranteed to do this on every WordPress site.

[westonruter]

It is worth hardening what is passed from input vars.

What does this PR add over the existing one ​https://github.com/WordPress/wordpress-develop/pull/11650? I think efforts should be consolidated there, and this PR be closed.

Closing in favor of #11650 so review stays consolidated in one place for Trac ticket #65123.

@westonruter Agreed. #11650 already covers the same ticket and broader query-var handling, so it makes more sense to consolidate review there instead of splitting effort across two PRs. I am closing this PR in favor of #11650.

[yusufmudagal]

Tested PR ​https://github.com/WordPress/wordpress-develop/pull/11650

Before the patch, passing a non-scalar attachment value to WP_Query::parse_query() set is_attachment and is_single, and constructing a custom post type query with an array query var triggered a fatal error in sanitize_title_for_query().
After the patch, attachment is normalized to an empty string, both flags remain false, and the custom post type query completes without a fatal error.

Patch tests well for me.