Mar 5 · 3 min read
Image taken from here

WordPress is CMS e.g. PHP and MySQL only web application. There is story about that DBMS exclusivity which continue with another exclusivity, but that isn’t today’s topic. It is most popular CMS around the web, leads with number of WP powered web sites ~33%, it is a champion between hacked CMS systems with astonishing 90% (~45% of hacked WP were with latest core updates)…

When we speak about threat model we should always consider WorPress as PHP and MySQL application and any “feature” in it, should be taken into consideration.

WordPress meta

Every post in WordPress has its own meta data and this meta data is divided in two groups: protected meta, which is used for storing sensitive information which couldn’t be accessed from the front, marked with leading _ in the meta_key and regular meta data which could be created/changed via WP admin and could have any character in 0 position (remember this it is important). The past told us that WordPress security team failed big time to “protect” the protected meta, but is this case for today? Ofc. it is!

MySQL stronK

Using MySQL as DBMS means one thing: considering all of its features into threat model. That means we should know how string compare works there, but also checking for edge cases is must too. So, let we check (open your MySQL console), what will be the output of the following query?

select '_je_thank_you_matik' = '_je_thank_you_matik'

It will be 1 e.g. those values are equal and that happens for char / varchar type columns when get compared by =and is case for: Unicode control characters and many many more existing chars (feel free to determine them all, it is easy, but that isn’t guarantee that there won’t be new in future). :)

WordPress side

In order to protect its meta data WP relies on is_protected_meta function and there we have just check for the first character of meta name => any character that gets avoided in MySQL =comparison as leading character will do the job. What will do existing code if we set up post_id as valid attachment?

$post_id = 1; //any existing attachment post
$meta_key = "\x11"."_wp_attached_file";
$meta_value = "wp scotch RCE";
if ( !is_protected_meta($meta_key) ){
update_metadata("post", $post_id, $meta_key, $meta_value);

This means that every SQL code in the WordPress core where comparison via = is performed could be tricked with those characters in order to update or select data that shouldn’t be updated or selected!

Example broken core functions: update_metadata, update_post_meta, update_option, _filter_query_attachment_filenames, attachment_url_to_postid, … and this is not everything, WP as it is allows us to insert any meta_key value not sanitized, except “protected”!

Attack surface

Attack surface is quite big if we got into consideration free writing of any meta key value, querying/manipulating postmeta table outside core functions and update_ calls usage. Now, if you combine them we sit on a powerful protected meta validation bypass technique! Please don’t forget that WP is PHP/MySQL application so those features have also bigger impact than showed examples in the form of core functions. Let we use the power of search and determine some interesting places among best plugins, the ones with highest quality and team expertise:

  • WP-Job-Manager, here. Consider how meta is retrieved and how is updated.
  • Jetpack, here. Consider how meta is retrieved, what will be returned from DB and how it is returned back, check the key.
  • WooCommerce, here. Consider how input is protected not being “protected” meta and update_ function call.
  • Wordpress Importer, here. Can you spot unserialize from contributor vulnerability?

There are many another plugins, themes, WP setups and if we add the following two exploit samples (this and this) things are getting serious and for serious issues, you need serious fixes / patches. This is only from attacking perspective, making systems not usable or avoiding some system restrictions in order to achieve some another functionality not infosec related is more than common.


Regarding current is_protected_meta bypass and MySQL magic in the background, there is patch that will do the job. Also there is patch for current image related RCE exploits. Any way, don’t forget to inspect your code if you use custom plugin / themes.


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