WordPress Importer — Arbitrary Post Creation
The official WordPress Importer accepts a structured file and creates content from it. WPDeeply’s 2021 disclosure examined what happens when the file is not trustworthy.
This page preserves a historical WPDeeply disclosure at its original URL. The research is credited to its author; remediation information has been kept current by the site’s present operators, who did not discover the vulnerability.
The WordPress Importer is the plugin almost every site installs once and then forgets. It reads a WXR file — the XML export format WordPress produces — and recreates the posts, pages, terms, users and attachments described inside it. That is a legitimately powerful job: an importer is, by definition, a tool for creating content on your behalf from a file you did not write.
The issue
- Component: WordPress Importer
- Type: Arbitrary post creation via import handling
- CVE: none identified for this disclosure.
WPDeeply’s original research examined how much of an import file the importer trusts, and what an attacker who could influence that file — or the import request — could cause to be created. The interesting cases are not the obvious ones. An import file can describe post types and statuses, authorship, terms and attachment URLs. Each of those is an opportunity to create something the site owner did not intend, in a form that looks like ordinary content afterwards.
Because this concerns a tool bundled into the standard WordPress workflow rather than a third-party plugin, and because import routines in other plugins reproduce the same assumptions, the write-up stayed at the level of the pattern rather than shipping a weaponised file. That decision holds on this page too.
Why importers are a recurring weak point
Import features across the plugin ecosystem share a set of assumptions that are wrong often enough to matter:
- That whoever triggered the import intended to.
- That the file came from a WordPress site the operator controls.
- That the values inside the file are already validated because WordPress produced them.
- That an importer only ever runs behind an administrator screen.
Break any one of those — through a missing capability check, a missing origin check, or an endpoint reachable without the admin UI — and the importer becomes a content-creation service for someone else. This is the same structural weakness as the Ninja Forms CSRF issue: a powerful action whose safety depends entirely on a check somewhere upstream.
Any feature that turns a file into database records deserves the scrutiny of an upload form, not the trust of a settings page.
Impact
- Creation of posts, pages or other content the site owner did not author.
- Content attributed to existing users, including administrators.
- Injected links and markup published under a legitimate site — the mechanism behind a great deal of WordPress SEO spam.
- Attachment records pointing at remote resources.
Content-level compromise gets less attention than code execution, but it is what most WordPress owners actually experience: pages they did not write, ranking for terms they never targeted, discovered weeks later through a search-console warning.
What to do now
- Keep the WordPress Importer updated, and deactivate or delete it when you are not migrating. It is the definition of a plugin that only needs to exist for an afternoon.
- Treat WXR files like executables. Only import files you produced or received from a party you trust.
- After any import, review the post list, the user list and the media library for records you do not recognise.
- Audit which of your plugins expose import features, and who can reach them.
Related reading
- Should you delete inactive WordPress plugins? — the importer is the canonical example.
- CSRF in WordPress, explained
- How to detect WordPress malware — including injected content.
Research and original disclosure by Slavco Mihajloski (mslavco), published on WPDeeply.