Make WordPress Core

Opened 6 years ago

Last modified 3 years ago

#12416 closed defect (bug)

*_option(), *_transient() and *_meta() functions should all expect unslashed data. — at Version 1

Reported by: Denis-de-Bernardy Owned by: ryan
Milestone: 3.0 Priority: high
Severity: critical Version: 3.0
Component: Security Keywords: needs-patch
Focuses: Cc:

Description (last modified by Denis-de-Bernardy)

Following up on:


It's totally irresponsible to expect plugin authors to escape whatever they send into get_option(). As things stand:

  • get_option(), delete_option(), get_site_option() assume it's slashed
  • add_option(), update_option(), add_site_option() seem to assume it's unslashed, as does get_option()
  • *_transient() seem to expect unslashed input.
  • delete_site_option() is very special: it expects slashed input if you're not on using multisite, but unslashed if you are
  • update_site_option() is equallty special: it needs slashed input if the option is not loaded already, and unslashed input if it is

the list goes on, and on... these inconsistencies, which come on top of the *_meta() functions, which expect slashed data.

it's totally nuts, insecure, and irresponsible. especially considering calls in WP such as:

  • get_option("{$size}_crop");

or functions such as:

function form_option( $option ) {
	echo esc_attr( get_option( $option ) );

function get_settings_errors( $setting = '', $sanitize = FALSE ) {
	global $wp_settings_errors;
	//... isn't it ironic that using sanitize here makes it LESS secure?
	if ( $sanitize )
		sanitize_option( $setting, get_option($setting));
	// ...

we're asking for trouble here...

Change History (1)

#1 @Denis-de-Bernardy
6 years ago

  • Description modified (diff)
  • Summary changed from *_option() should all expect unslashed data. to *_option(), *_transient() and *_meta() functions should all expect unslashed data.
Note: See TracTickets for help on using tickets.