Including http://*. in $_GET variable breaks user session

[zergling81]

In 4.2.2 (but not 4.1.5) including a URL in a $_GET variable will prevent WordPress from identifying the current user via functions like current_user_can and get_currentuserinfo, breaking any functionality dependent on same, such as access to private pages, etc.

Reproduction steps:

1. Install clean 4.2.2 with no plugins and the Twenty Fifteen theme.
2. Create private page.
3. Visit private page to confirm that you can see it normally.
4. Add a URL as the value of a $_GET variable, and reload the page with the modified URL.

The issue seems to have to do with string matching, as it occurs regardless of URL encoding and ONLY occurs with a complete "​http://*." or "​https://*." string (where * is a wildcard) - omitting any character of the string averts the issue.

Thus, any of the following would produce the error:

​http://www.example.com?page_id=5&randomvariable=http://www.yahoo.com
​http://www.example.com?page_id=5&randomvariable=http%3A%2F%2Fwww.yahoo.com
​http://www.example.com?page_id=5&randomvariable=http://www.

but these would not:

​http://www.example.com?page_id=5&randomvariable=www.yahoo.com
​http://www.example.com?page_id=5&randomvariable=www.yahoo.com
​http://www.example.com?page_id=5&randomvariable=http://www
http:/www.example.com?page_id=5&randomvariable=http:/www.yahoo.com

[zergling81]

I should add, it doesn't matter what comes before the first period, so long as there is something - ​http://abc.yahoo.com or ​http://yahoo.com would produce the bug, ​http://.yahoo.com would not.

[zergling81]

This looks to be a hosting environment issue and not a Wordpress issue - my reproduction works reliably on Hostgator shared hosting, but not on my local server. On Bluehost Wordpress hosting, "​http://*." does not cause problems - but a range of popular file suffixes (.jpg, .jpeg, .png, .pdf, .mp3 but NOT .doc, .aiff, .tiff) in the variable value produce the exact same behavior.

With this knowledge in hand, I have managed to elicit the behavior from a 4.1.5 install as well as a generic HTML page. So, it's somebody's issue, but not a WP bug, contrary to prior appearances.