WordPress Pingbacks Used to Flood Other Websites

A notice from the host

The volunteer who looks after a club's website opens an email from the host. The club's small WordPress site, it says, has been sending thousands of requests to a website nobody there has heard of.

The host has limited the account and wants the problem fixed. Nobody at the club has done anything unusual, and the site looks the same as it did last week.

The likely cause is a feature that has been switched on since the site was built, called pingbacks, and the requests were never the club's idea.

What a pingback is meant to do

When one blog post links to another, WordPress can send the linked site a short automatic notice that it has been mentioned. That notice is a pingback.

The receiving site does not take the notice on trust. It fetches the page said to contain the link, checks that the link is really there, then lists the mention under the post.

Notices arrive through a file every WordPress site has, xmlrpc.php, which also lets phone apps and other tools publish to the site remotely.

How the check becomes an attack

Anyone can send a pingback notice, and it can name any page as the one containing the link. The receiving site then fetches that page, whatever it is.

An attacker sends the same false notice to thousands of WordPress sites, each naming a page on one target. Every site dutifully fetches it to check.

The target receives a wave of requests from ordinary websites, more than its server can answer. Blocking them is hard, because they come from thousands of addresses rather than one.

The sites doing the fetching are not infected with anything. They are working as designed, which is why a site can take part for weeks without anyone noticing.

Signs the site is being used

Most owners first hear about it from the host. The other signs are quiet:

• A complaint forwarded from the target's host to yours.
• Requests for xmlrpc.php in the access log, from many different addresses.
• A slow site with nothing new published and the usual number of visitors.
• Bandwidth or processor warnings in the hosting control panel.
• An empty comments queue, because the false pingbacks fail after the fetch.

The last point surprises people. The fetched page never links back, so WordPress rejects the pingback after the request has been made, and nothing appears for anyone to approve.

Reading the access log

Most hosting control panels offer the raw access log, a plain list of every request the site received. Search it for xmlrpc.php.

A site being used this way shows that file requested over and over, many times a minute, from addresses around the world, at hours when the members are asleep.

A few such lines a day are normal on a site that publishes from a phone app. Hundreds an hour are not, and the host's technicians can usually say which pattern it is.

A worked example

A community dragon boat club on a lake near the city runs a WordPress site with its practice schedule, regatta results and a short news post after each race weekend.

A coach built the site five years ago and has since moved away. Two volunteers post the news from their phones, and nobody had opened the settings since.

When the host's notice arrived, the access log showed requests for xmlrpc.php around the clock, and every post from those five years still had pingbacks switched on.

The club asked a web developer to take over maintenance. Pingbacks were switched off for new posts and, in a bulk edit, for every existing post and page.

Because the volunteers publish from phones, the developer kept xmlrpc.php working and removed only its pingback function, then updated WordPress, the theme and the plugins.

A false notice is now refused before any page is fetched, so the club's site has nothing to send.

Why the fix belongs with the maintainer

Switching off pingbacks looks like one checkbox, and that is the trap. The checkbox under Discussion settings applies only to posts published afterwards.

Every older post keeps the setting it was published with, and those are the posts attackers name. Changing them takes a bulk edit, done carefully.

Blocking xmlrpc.php altogether is the blunt alternative. It stops the abuse, but it also stops the WordPress phone apps and any service that publishes to the site.

Someone who maintains the site knows what depends on that file, makes the change so that it survives updates, and tests the site afterwards.

Answering the host

Reply to the host's notice the same day, even before the fix is done. Say who is handling it and by when, so the host can see that someone responsible has it in hand.

Once the change is made, ask the host to confirm from its own records that the outgoing requests have stopped, and keep the exchange on file.

The counter-case

A few sites genuinely use pingbacks. A busy blog whose writers like seeing who mentioned them may want them on, and some hosts already filter these false requests for every account.

A site like that can keep the feature, provided someone watches the log and the host's notices and keeps WordPress current. The choice should be deliberate, not a default nobody chose.

For most small club and business sites, though, pingbacks do nothing visitors would miss, and closing them properly is a short job for whoever maintains the site.

Closing pingbacks properly

1. Read the host's notice and note the dates it mentions.
2. Search the access log for requests to xmlrpc.php.
3. Name the person who maintains the site, or find one.
4. Switch pingbacks off for new and existing posts.
5. Keep phone publishing working if volunteers rely on it.
6. Update WordPress, the theme and every plugin.
7. Ask the host to confirm the requests have stopped.

Step three decides whether the fix lasts. A site with a named person responsible for it is fixed properly once; a site that belongs to nobody gets a quick checkbox and the same notice next month.

A WordPress site also sends email on its own, and why those messages often arrive from a sender nobody set up is covered in emails from the website signed WordPress.

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.