Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 8 years ago

#24884 closed defect (bug) (fixed)

WP_Query's "m" parameter is cast to an int which is a problem due to 32-bit signed intergers

Reported by: viper007bond's profile Viper007Bond Owned by: nacin's profile nacin
Milestone: 3.7 Priority: normal
Severity: normal Version: 3.5.2
Component: Query Keywords: has-patch
Focuses: Cc:

Description (last modified by Viper007Bond)

WP_Query's m parameter accepts MySQL datetimes basically. These values can be up to 14 characters long (YYYYMMDDHHMMSS). For the long values, you end up with 2147483647 when the passed value is run through absint(). While in the process of being used to create a query, it is further validated by being run through preg_replace( '|[^0-9]|', '', $q['m'] ) which makes the integer casting redundant.

Attached is a patch that fixes this issue by just using regex to validate the value.

I discovered this while writing unit tests for #18694 and with the patch on this ticket applied, the unit tests now work as expected. This is another case of unit tests saving the day! :)

Attachments (1)

24884.patch (969 bytes) - added by Viper007Bond 11 years ago.

Download all attachments as: .zip

Change History (7)

11 years ago

#1 @Viper007Bond
11 years ago

  • Description modified (diff)

#2 @wonderboymusic
11 years ago

  • Milestone changed from Awaiting Review to 3.7


#3 @Viper007Bond
11 years ago

Unit tests for this are included as a part of #18694.

#4 @nacin
11 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In 25138:

Don't cast the 'm' query variable to an integer as the value can exceed the range of a 32-bit signed integer.

props Viper007Bond.
fixes #24884.

#5 @nacin
11 years ago

Tests added in [25139].

#6 @boonebgorges
8 years ago

In 37324:

Query: Discard non-scalar 'm' instead of attempting to sanitize.

WP_Query discards most non-array date values ('year', 'monthnum', etc) by
casting to integer. Since [25138], the 'm' parameter has been handled
as a string; see #24884. However, the string-handling introduced in [25138]
blindly attempted to handle arrays and other non-scalar types as strings,
resulting in PHP notices and invalid MySQL syntax.

Props vortfu.
Fixes #36718.

Note: See TracTickets for help on using tickets.