WP_Query::parse_query() does not handle invalid query arg values - #12738
WP_Query::parse_query() does not handle invalid query arg values#12738josephscott wants to merge 1 commit into
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
Pull request overview
This PR aims to prevent fatal errors during request parsing by validating that certain public query variables (currently feed) are provided as single scalar values rather than arrays, and returning a 400 response early when invalid values are detected.
Changes:
- Adds a private allowlist (
$single_value_query_vars) for scalar-only public query vars. - Introduces an early validation loop in
WP::parse_request()that callswp_die()with a 400 response if a scalar-only var is non-scalar (e.g. an array).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| * @since 7.1.0 | ||
| * @var string[] | ||
| */ | ||
| private $single_value_query_vars = array( 'feed' ); |
| wp_die( | ||
| __( 'Invalid value for a query variable.' ), | ||
| __( 'Error, this request could not be processed.' ), | ||
| 400 | ||
| ); |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
peterwilsoncc
left a comment
peterwilsoncc
left a comment
There was a problem hiding this comment.
As mentioned on the ticket, I think this is a solid approach.
I've made a couple of notes inline.
| wp_die( | ||
| __( 'Invalid value for a query variable.' ), | ||
| __( 'Error, this request could not be processed.' ), | ||
| 400 | ||
| ); |
There was a problem hiding this comment.
What do you think of triggering a 404 if the URL has been messed around with?
Arguably /?feed[]=rss&feed[]=atom doesn't exist and this would trigger the website's theme appropriate 404 page rather than the generically designed wp_die() error messaging.
| wp_die( | |
| __( 'Invalid value for a query variable.' ), | |
| __( 'Error, this request could not be processed.' ), | |
| 400 | |
| ); | |
| $this->query_vars['error'] = 404; | |
| unset( $this->query_vars[ $wpvar ] ); |
| * @since 7.1.0 | ||
| * @var string[] | ||
| */ | ||
| private $single_value_query_vars = array( 'feed' ); |
There was a problem hiding this comment.
I'd make this public to allow theme and plugin authors to do either of two things:
- Add to the list, eg an SEO plugin may wish to add their
sitemapquery var to the list - Remove from the list,
WP_Queryis pretty flexible and a plugin might make use of the various filters to modified valid query vars and modify the SQL query accordingly
https://core.trac.wordpress.org/ticket/60745
AI assistance: Yes
Tool(s): Claude
Model(s): Opus 5
Used for: Rubber ducking for ideas on approaches
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.