Jan 22 · 3 min read

WordPress project continue its path towards, somewhere… Maybe people there know what are they doing, but for the rest of the audience doesn’t seems that way. Month back Gutenberg was introduced (I like the project, beside I have some remarks about it…) and also roadmap for 2019 was introduced. There we all learned that site health mechanisms would be introduced in the core… And they are introduced, check the beta.

How it is called a condition in which your immune system mistakenly attacks your body?

Right after the merge in the core I already mentioned that isn’t the right time for introducing this “features” and that takes its debt. One of the security issues was discovered and fixed, but that wasn’t the main reason why I bring this argument on the table.

Main feature is biggest enemy

One of the main feature in the merge in fact is the biggest enemy of the WordPress and that is:

Extensions are only paused in the admin backend and a few other areas while for example the frontend stays unaffected, and thus broken. Since it is impossible to predict which functionality the broken extension is responsible for, it would be dangerous to have it disabled in the frontend.

Stopping extensions based on Fatal Error is more than fatal for WordPress as a whole, at any place, in any time.


Grab WordPress 5.1 beta 2, WooCommerce 3.5.3 (There is 3.5.4 with security fixes that mitigate case 1 and few another) and set them up on your local environment. Create ShopManager account and contributor account. Add the following code in the constructor of WooCommerce in plugins/woocommerce/class-woocommerce.php :

//poc cause fatal error ;)
if ( isset($_GET["trigger"]) ){
$mb = str_repeat("A", 10000000);
while( true ){
$mb .= $mb;

Case 1 (attack described here, now with serve happy even easier to be performed)

  • Log in as ShopManager
  • request wp-admin with &trigger=yes
  • edit the administrator password

Case 2

  • Log in as Contributor
  • request the wp-admin with &trigger=yes
  • ShopAdmin can’t use the backend, even more can meddle with users in vulnerable versions
  • If contributor sets this requests in one seccond, who will be able to enable Woo again in the backend?

WordPress still in wrecking ball period

Enough with the PoC and theory, let we grab out lab coats and show something worth here. WordPress (beside many another types) is vulnerable from DOS attacks and that is buried in its code! From the previous knowledge situation is like this…

memory_limit >= post_max_size * 66 * 3

This means that PHP defaults post_max_size = 8M and memory_limit = 128 are more than enough for one request with one parameter as contributor to fill in the process memory and to cause crash into desired place in the desired plugin — open source ;)!

On the default PHP, 3MB post parameter in request, that is going to be esc_sql-ed would be enough to cause fatal error and to pause any plugin :) 

Even more, those types of attacks could be supplied by a visitors, stored in to DB and to cause administrative user to be unable to fix issue until plugin is disabled. Frontend of the WordPress instance will be used for determining of those two values (post_max_size and memory_limit), because only search parameter give us 66 * 3 * … case.
Most important, this attack is easy to be automated and to literally sink all of the 5.1 instances out there.

Attack scenarios

  • Imagine all of those WooCommerce sites to not be able to access the backend
  • Imagine all of those WordPress instances that allow low privileged users being protected by WordFence or another endpoint security plugins
  • Imagine paused authentication and authorization plugins
  • Imagine remote Akismet turn off
  • Imagine low privileged users interrupting work of complete instalations

and all of this by only one request, near the limit of the post max size being filled with % signs.

WordPress, serve happy, don’t push this in the core!


If you are wp developer or wp host provider or wp security product provider with valuable list of clients, we offer subscription list and we are exceptional (B2B only).


Attack sources + web application security


Written by




Attack sources + web application security

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade