Defaced WordPress Sites and the Update That Was Already Out

What happened this week

In the days since a WordPress flaw was made public last Wednesday, pages on a very large number of sites have been replaced with messages from attackers. Automated tools find vulnerable sites and rewrite their posts and pages.

The flaw was in the REST API, the part of WordPress that lets other programs read and change content. Its content features arrived with version 4.7 in December, and a mistake in them let anyone edit posts without logging in.

WordPress 4.7.2, released on January 26, fixed it. The fix was announced only on February 1, almost a week later, to give automatic updates time to reach sites before attackers knew what to look for.

Why the announcement was held back

Holding back the details was deliberate. Announcing a flaw tells attackers where to look, so the WordPress team let the update spread quietly first.

That worked for sites that update themselves. For sites that depend on someone reading the news, it means the warning always arrives after the fix, and attackers read the same news.

Who was protected and who was not

• Sites already on 4.7.2 before the announcement were safe.
• Sites with automatic updates on mostly updated themselves unnoticed.
• Sites with updates switched off stayed on 4.7 or 4.7.1.
• Sites waiting for someone to click update were exposed meanwhile.
• Sites older than 4.7 lacked this flaw but miss other fixes.

The third is the one this week is really about. Those sites had the fix available for days, and a setting chosen years ago, often for a sensible reason, kept it out.

Why automatic updates get switched off

Usually a developer turned them off after an update broke something once, and promised to update by hand instead.

Sometimes it is a line in the site's configuration file, a plugin that manages updates, or a host's setting. Sometimes updates fail silently because the server will not let WordPress write its own files.

Each choice was reasonable when it was made. The trouble is that nobody took on the job the automatic update had been doing.

What to check today

Log in and look at the At a Glance box on the dashboard, which names the version the site is running. Anything below 4.7.2 needs updating now, from the Updates screen.

Then look at the site as a visitor would, and go through the list of posts and pages. Defaced content usually has a replaced title or a short message, often signed by the attacker.

Check every post and page, not just the home page. The attacks were automated and changed many pages at once.

Updating does not undo the damage

Version 4.7.2 closes the door. It does not put back what came through it.

WordPress keeps earlier versions of each post as revisions, and the original text can usually be restored from the editor in a few clicks. Where revisions are switched off, the backup is the way back.

Once pages are restored, use Fetch as Google in Search Console on the most important ones, so the attackers' titles do not linger in search results.

A worked example

A singing teacher who runs a studio from home had a WordPress site with lesson details, a recital calendar and short news posts about students' exams.

The designer who built it switched off automatic updates after one broke the calendar plugin, and agreed to update by hand every few months. The last round was in December, to 4.7.

On Saturday a parent sent a message: the lessons page said something strange. Nine pages and posts had been rewritten with the same message.

The designer updated to 4.7.2, restored each page from its revisions, and checked the user accounts. Then the two of them agreed something new.

Automatic minor updates are back on, the designer gets an alert when a security release appears, and the teacher has it in writing who checks within two days.

Minor releases should install themselves

Minor releases such as 4.7.1 and 4.7.2 contain security and bug fixes, not new features. They rarely break anything, which is why WordPress installs them by default without asking.

Major versions such as 4.7 are different. Testing those first, on a copy of the site, is reasonable.

Switching off minor updates to avoid a rare breakage trades a small risk for a large one, as this week showed.

Firewalls helped, updates fixed it

Some hosts and security services blocked the attack before it was announced, and their customers were spared even before updating.

That is welcome, but a block covers one known attack. The update removes the flaw itself, along with the other fixes in the same release.

Repairs depend on what was kept

This week's repairs were quick where revisions were on or a recent backup existed, and slow everywhere else.

Check that the site is backed up daily to somewhere other than the same server, and that someone has tried restoring from it. Until someone has, nobody knows it works.

Updates need an owner

Someone has to be named: a person with access, who hears about security releases, checks the version afterwards and has a backup to restore from.

Updates to WordPress itself are only part of it. Plugins and themes have their own releases, and the automatic minor updates do not cover them.

For most small businesses that person is their web company, under a maintenance arrangement. Get it in writing: what is covered, and how fast a security release is applied.

The counter-case

Some sites have good reason to hold updates back: a shop with custom code, or a site where a broken page costs real money. Testing first is sensible there.

But held-back updates need a person who applies security releases within a day or two, on a copy first if necessary. Waiting for a quiet month is what this week punished.

Keep minor updates automatic unless someone is plainly responsible for applying them quickly.

Today

1. Check the version in the At a Glance box.
2. Update to 4.7.2 if the site is older.
3. Look through every post and page for changes.
4. Restore damaged pages from revisions or a backup.
5. Turn automatic minor updates back on.
6. Name the person who checks each security release.
7. Ask Google to recrawl the restored pages.

Step five is what keeps this from happening again. The fix was available a week before anyone knew it mattered, and the sites that took it without being asked were the ones that never had to find out.

Why security releases cannot wait for a convenient moment is covered in security releases and the sites that wait for a quiet week.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.