Make WordPress Core

Opened 8 years ago

Closed 6 years ago

#37957 closed defect (bug) (invalid)

WordPress Maximum Post Submit Fields

Reported by: nathanmemoria's profile nathanmemoria Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords:
Focuses: administration Cc:

Description (last modified by SergeyBiryukov)

Wordpress submits post/page/custom post data & metadata in an HTTP post request. Because of a DOS vulnerability in PHP (http://www.phpclasses.org/blog/post/171-PHP-Vulnerability-May-Halt-Millions-of-Servers.html), a limit to php fields was added as the default.

It there are 1,000+ fields, the default is to truncate these fields without any notice. Several of my clients have suffered from this issues. Specifically, plugins that use a custom post type with a lot of meta data will be effected.

This seems to be a core issue rather than a plugin issue. There are two solutions:
Ideally, the data should all be wrapped in one field and submitted (as ajax requests currently are), or less ideal there should be a warning when data is lost.

Change History (5)

#1 @swissspidy
8 years ago

  • Version trunk deleted

#2 in reply to: ↑ description @nathanmemoria
8 years ago

There was a typo in my original description. It there are 1,000+ fields, the default is to truncate these fields without any notice.

#3 @SergeyBiryukov
8 years ago

  • Description modified (diff)
  • Summary changed from Wordpress Maximum Post Submit Fields to WordPress Maximum Post Submit Fields

#4 @stephenharris
8 years ago

Unfortunately the proposed solution simply exposes the vulnerability again.

The limit is there to prevent a DOS attack which uses a large number of POST fields with a high collision rate (in the underlying hash table) to make populating the $_POST array expensive. (The idea is that the fields each have a different key, but they map to the same key in the hash table.)

If you're bundling data into one field, presumably at some point you're going to wait to extract it out into an array. So effectively you're going to build an arbitrary sized array which could be very large and contain a high number of collisions.

Nor do I think this is a core issue - plug-in developers should 'namespace' their field names (the limit applies to each nesting level of a sub array).

#5 @desrosj
6 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

PHP has a configuration variable, max_input_vars, which allows you to increase the number of input variables allowed if desired. max_input_vars is set to 1000 by default. FWIW, an E_WARNING is also triggered if more variables than max_input_vars allows is passed so developers and site administrators can be made aware.

I'm going to close this one out as it's not really a WordPress issue.

Note: See TracTickets for help on using tickets.