WP allows to inject random strings into archive page urls, still returning 200

[paulschiretz]

After checking back with @johnbillion from WordPress on (hackerone) i disclose this issue here.

Preconditions
Standard wp install.
Some demo data containing at least 2 Blog categories. One Parent Category and a child of that category.

Issue
When working with archive pages the query for the right taxonomy is way to sparse. This allows me to access pages that don't exist and wp still returns a 200 response.

When for instance working with blog categories, as long as the last category term exists wp will return the last category, no matter what i typed as url before that.

To be clear a quick example:
Wordpress.org has a category called asides, if i access it:
​https://wordpress.org/news/category/releases/ => returns 200 a valid page.
BUT:
I can also type:
​https://wordpress.org/news/category/%20AND1=1/releases/ => returns 200 a valid page.

Ma.tt has a category called asides, if i access it:
​https://ma.tt/category/asides/ => returns 200 a valid page.
BUT:
I can also type:
​https://ma.tt/category/this_is_random_content_that_doesnt_exist/asides/ => returns 200 a valid page.

This is possible for all archive pages in wordpress, wocommerce and ecosystem, as long as the first and the last term match something existing a valid response is returned.

Why is this a critical
Just imagine what happens if i do this on a server using a page cache - like a lot of wordpress sites do.
Write a simple script that calls archive urls with an url pattern like ​https://wordpress.org/news/category/SOMETHING_I_WANT_TO_ADD/releases/ an make a couple of 1000 calls.

Steps To Reproduce:

1. Find any WordPress site with an archive page, a blog page for instance.
2. Find a matching term on 1st level of the archive category(term) hierarchy
3. Find a matching term on 2nd level of the archive category(term) hierarchy
4. Call the site with ​https://example.com/blog/KNOWN_CAT/SOMETHING_I_WANT_TO_ADD/KNOWN_CAT/

We need to somehow fix the terms query to make sure each term exists before returning a 200. if one of them is missing return a 404, or if needed a 301 to the parent term.

[SergeyBiryukov]

Hi there, welcome to WordPress Trac! Thanks for the report.

Just linking to some related tickets here: #14773, #17653, #35437.

[hellofromTonya]

Hello @paulschiretz,

Welcome to WordPress Core Trac.

I'm doing triage today on 6.6.x releases by determining if the reported bug was introduced in the marked 6.6.x (e.g. 6.6.2) release.

The terms query was not changed in 6.6.2. In reviewing the 6.6.2 changes, I'm seeing any that appear to affect what is being reported here in this ticket.

For now, I'm removing the Version (meaning the release that introduced the bug). Once this issue is investigated and its root cause found, the Version can/should/will be updated for contextual purposes.

Other triage changes:

• Adding has-testing-info keyword, as the step-by-step instructions on how to reproduced are in the description. Thank you for providing these instructions.

• Removing the needs-patch keyword, until the report is investigated and determined a fix is needed in Core.

[paulschiretz]

Hi @hellofromTonya,

Thanks for getting to that so fast. I wasn't aware version means version that introduced the bug, thought of it more like version in which it is reproduceable.

Thanks for clarifying that!

Let's hope this one gets fixed soon, took me a couple of hours till i found out it's core behavior.