Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#32413 closed defect (bug) (invalid)

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

Reported by: zergling81 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: Cc:


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:


but these would not:


Change History (4)

#1 @zergling81
6 years ago

  • Summary changed from Certain file suffixes in $_GET variable break user session to Including http://*. in $_GET variable breaks user session

#2 @zergling81
6 years ago

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.

#3 @zergling81
6 years ago

  • Resolution set to invalid
  • Status changed from new to closed

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.

#4 @ocean90
6 years ago

  • Milestone Awaiting Review deleted
  • Version 4.2.2 deleted
Note: See TracTickets for help on using tickets.