Mar 15 · 2 min read
It happens. Image taken from here.

WordPress faces can put any make up they want, can say anything they want, but always make up is temporary and if you say anything except the truth you must remember it forever… Their behavior while they ride on the “community” wave, referring as “we” is reflected in the way how they care about “community” effort called WordPress.

Beside the fact wordpress-importer is considered as threat because WP core, there are many traces in its code bringing the incompetence of “rock stars” in day light. Bonus: they steal from researchers/contributors and another from close companies cover them up! Lovely eco system.

We all learned how protected meta are dangerous in WP and we saw how there were “efforts” in the past to do something (here and here), but that not happened. Signals of incompetence are more than noticeable in this plugin too. Let we check :)

wordpress-importer “protected” attachments

In the import function the first line is “protective” one

add_filter( 'import_post_meta_key', array( $this, 'is_valid_meta_key' ) );

All fine and this function is about preventing users to tamper the export file and to add extra towards blog posts.

'_wp_attached_file', '_wp_attachment_metadata', '_edit_lock'

Is this enough? Probably yes, but not for WordPress, because if you put code in mission critical plugin, then you should know a bit about WordPress itself. It seems the criteria for getting those permissions (to submit the code) is the metric that present number of kissed asses per interaction.

Later, down in the code we have

$key = apply_filters( 'import_post_meta_key', $meta['key'], $post_id, $post );

e.g. making sure meta_key isn’t critical and after that we have a call towards add_post_meta API function. Which is in fact add_metadata and in this function we have:

$meta_key   = wp_unslash( $meta_key );

which is in fact stripslashes call for the meta_key e.g. any slash will be stripped off.

That guides us towards conclusion that meta data in import file constructed in following way will result with entrance of “protected” and “prevented” mission critical meta.


Having on mind that contributor role can insert any meta value which is not protected => we have remote contributor attack towards any WP instance out there.

More to come in the next days, but if you run multi site WP or managed WP with enabled wordpress-importer then try/ask for patch ;) :)


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