The WordPress 4.7 REST API vulnerability: what happened and what to learn

What the vulnerability was

WordPress 4.7 and 4.7.1 contained a critical flaw in the REST API: an unauthenticated user could modify the content of any WordPress post or page. The vulnerability required no login, no special permissions, and no interaction from the site owner. Anyone who knew the URL pattern could overwrite any post's content via an HTTP request.

The technical cause was a type handling error in how the REST API processed post IDs. Under normal circumstances, only authenticated users with edit permissions can modify posts. The flaw allowed this check to be bypassed.

The deliberate disclosure delay

WordPress's security team discovered the vulnerability and patched it in WordPress 4.7.2, released January 26, 2017. Crucially, they did not announce the nature of the vulnerability at release time — they described the release as containing "security fixes" without specifying what those fixes addressed.

The reason was deliberate and calculated: they wanted to give sites time to update before attackers knew what to look for. On February 1 — six days after the patch release — they disclosed the full details publicly, by which point a large percentage of WordPress sites had auto-updated to 4.7.2.

The strategy was controversial. Site owners who prefer to evaluate updates before applying them were updating to a release whose significance they didn't know. But the Wordfence team, which was informed under embargo and helped track the situation, supported the approach — the window between disclosure and mass exploitation is very short.

What happened after disclosure

Within hours of the February 1 public disclosure, mass exploitation began. Security researchers documented over 1.5 million pages defaced across hundreds of thousands of sites in the days following. Attackers replaced page content with their own messages — typically political statements, hacker group tags, or simple proof-of-exploitation messages.

Sites running WordPress 4.7 or 4.7.1 that hadn't updated to 4.7.2 were trivially defaced with automated tools. The attack required no skill — just a script and a list of WordPress sites to target.

Who was protected, and why

Sites that had automatic minor updates enabled — the feature introduced in WordPress 3.7 — updated to 4.7.2 automatically on or shortly after January 26. They were protected before the vulnerability was even publicly known.

Sites where auto-updates were disabled, or sites that updated manually and hadn't gotten around to it, remained vulnerable through the disclosure period and were the primary targets of the defacement campaigns.

What this teaches us

Several lessons from this incident remain relevant:

• Auto-updates for minor releases are worth it. The sites protected by this vulnerability were protected without any human action. The sites that weren't protected were the ones where someone had disabled auto-updates or simply hadn't logged in for a while.
• The window between patch and exploitation is very short. Six days is not very long. For any site without auto-updates, the manual update process needs to be fast when security patches are released.
• Attack tools are developed quickly. Within hours of a vulnerability being publicly described, working exploit tools are in active use. "I'll get around to updating it" isn't a viable security posture.
• Even low-value sites are targeted. The defacement campaign was indiscriminate — automated tools ran against every discoverable WordPress site regardless of size or importance.

At DownUnder WP, you can manage WordPress core and plugin updates from your dashboard. The update mechanism works within your site's isolated environment — changes don't affect other sites and can be tested before going live.