Rewrite Rules: Only treat a leading www. as optional in url_to_postid()

[youknowriad]

url_to_postid() compares the URL's host to the site's host after removing www. from both. The removal is unanchored, so it strips www. from anywhere in the host, not just the prefix. On a site at example.com:

url_to_postid( 'https://exwww.ample.com/?p=16' )   // 16
url_to_postid( 'https://example.cwww.om/?p=16' )   // 16
url_to_postid( 'https://evil.com/?p=16' )          // 0

Both are ordinary registrations (ample.com; cwww.om under Oman's TLD). Since a post ID from this function is widely treated as proof that a URL is internal, a lookalike domain currently passes that test.

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

This surfaced while reviewing #12870 on that ticket, which uses url_to_postid() for a trust decision. Worth fixing on its own regardless of what happens to that PR.

Changes

Anchor the removal so only a leading www. is optional, matching the idiom already used in ms-functions.php and ms-blogs.php:

$url_host = preg_replace( '|^www\.|', '', $url_host );

Testing

A data-provided case in tests/phpunit/tests/rewrite.php covers the site host, the www. prefix, both collisions, an unrelated host, and the site host as an attacker subdomain. Reverting only the source change fails exactly the two collision cases.

npm run test:php -- --filter Tests_Rewrite    # 92 tests, 279 assertions

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Research, implementation, and tests; reviewed and edited by me.

[github-actions]

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 props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props youknowriad.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The 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

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[irozum]

Good catch and a clean, minimal fix — anchoring the www. strip to the start of the host closes a real spoofing gap (exwww.ample.com / example.cwww.om currently alias to example.com), and it matches the same anchored idiom already used in ms-blogs.php/ms-functions.php, so this brings url_to_postid() in line with the rest of core rather than introducing a new pattern.

Checked out the branch and ran the affected suite plus the standard gates: Tests_Rewrite (92 tests, 279 assertions), composer lint:errors and phpstan on the two changed files — all clean. Traced the surrounding code by hand: the strict !== comparison a few lines down means this fix only ever makes matching stricter (fewer false positives), so there's no realistic backward-compat concern for existing callers.

One minor observation, non-blocking: the linked ticket #65016 is about auto-approving self-pingbacks, not this bug — the PR body explains it surfaced while reviewing #12870, which is reasonable, but there's no dedicated ticket for the url_to_postid() issue itself. Worth flagging to committers in case they'd rather this land under its own ticket for changelog/props purposes, though it's not something I'd block on.