Are WordPress Pingbacks a Security Risk? How to Disable Them

In 2014, attackers didn’t need a botnet. They used 162,000 ordinary WordPress sites as weapons. Each one sent a flood of HTTP requests to a single target, and the site owners had no idea it was happening. The feature that made it possible was pingbacks, enabled by default on every WordPress install. Wordfence reported blocking 9.1 billion exploit attempts and 13.8 billion brute-force attacks during Q4 2025 alone.

This post explains how to disable wordpress pingbacks, why XML-RPC makes the problem worse, and four methods to disable the feature completely. Whether you run one blog or fifty client sites, these steps take under ten minutes.

Key Takeaways: WordPress powers 42.2% of all websites, making it the largest single attack surface on the web. Pingbacks allow attackers to use your site as a DDoS reflector without ever touching your admin panel. Disabling pingbacks takes less than two minutes in Settings > Discussion. XML-RPC amplifies the risk further: one request can carry 1,000 login attempts. Trackbacks carry the same risks and should be disabled at the same time.

What Are WordPress Pingbacks, and How Do They Work?

Pingbacks are an automated notification system. When Site A links to Site B, WordPress sends a request to Site B saying, “We linked to you.” Site B then displays that link in its comments section. The system was built to build community among bloggers. WordPress powers 42.2% of all websites, which means hundreds of millions of sites have this feature switched on by default.

The mechanism runs through XML-RPC, a remote procedure call protocol that WordPress uses to handle programmatic requests. When a pingback is triggered, WordPress sends an HTTP POST to the xmlrpc.php endpoint of the target site. The target site then fetches the source URL to verify the link exists. That outbound fetch is the core of the problem.

Pingbacks vs. Trackbacks

These two features are often confused. Trackbacks are older and require the publisher to send a notification URL manually. Pingbacks are fully automatic. WordPress handles the entire exchange without any human input. Both appear in your comments queue, and both are abused in the same ways.

The WordPress dashboard treats them identically under Settings > Discussion. When you disable one, you should disable both.

The verification step is the attack surface. When your site receives a pingback, it doesn’t just accept the notification. It reaches out to the claimed source URL to verify that the link is genuine. An attacker can forge that source URL to point at any target they choose. Your server makes the request. Your server’s IP is logged at the target. You become the unwitting middleman.

How Do Attackers Use Pingbacks to Launch DDoS Attacks?

The reflection attack is simple, cheap, and hard to trace. Here’s the exact sequence an attacker follows.

How a pingback DDoS attack works:

1. The attacker identifies thousands of WordPress sites with pingbacks enabled.
2. They send each site a crafted XML-RPC request claiming that a URL on the victim’s site links back to the target.
3. Each WordPress site’s pingback handler verifies the claim by fetching the target URL.
4. The target receives thousands of simultaneous HTTP requests from thousands of different IPs.
5. The target’s server or network collapses under the load.
6. Every WordPress site involved looks like a legitimate visitor from the target’s perspective.

The scale is not theoretical. In one documented campaign, attackers used 162,000 WordPress sites as reflectors against a single target. A separate Conetix analysis from 2016 found a single attack that used 9,984 reflector sites across 109 countries, peaking at 4,500 requests per second. The same host logged 2.5 million malicious pingback requests in a single month.

The reflection technique is particularly effective because the attack traffic originates from real WordPress sites with real IP reputations. Standard IP blocklists don’t help the target. Rate limiting doesn’t help either, because the requests come from too many different sources. The only way to stop this attack is to prevent WordPress sites from participating, which means disabling pingbacks at the source.

Why Is XML-RPC So Dangerous for Brute-Force Attacks?

XML-RPC amplifies brute-force attacks in a way most security tools can’t catch. The system.multicall method lets an attacker bundle up to 1,000 credential pairs into a single HTTP request. One request, one entry in your logs, 1,000 login attempts processed. Rate limiters that watch for repeated requests see one hit and wave it through.

This isn’t a minor edge case. Wordfence blocked 100 billion credential-stuffing attacks from 74 million unique IP addresses in 2023 alone. Many of those attempts passed through XML-RPC endpoints.

Pingbacks and brute-force attacks share the same door: xmlrpc.php. When you leave pingbacks enabled, you keep that file accessible. An attacker scanning for open XML-RPC endpoints will find yours. From there, they can run brute-force amplification attacks alongside pingback-based DDoS campaigns from the same endpoint.

Disabling pingbacks alone reduces your exposure. Blocking XML-RPC eliminates it.

How Big Is the Pingback Spam Problem?

Beyond DDoS, pingbacks create a constant stream of spam. WP Engine’s 2025 traffic analysis found that 76% of bot activity on WordPress sites came from unverified bots, and only 38% of customers had any bot mitigation in place. Pingback bots are a significant contributor to that unverified traffic.

The WPBeginner editorial team, which has managed WordPress sites for over a decade, states plainly that the vast majority of trackbacks and pingbacks they see are spam. That matches what most site owners report when they dig into their comment queues.

Website audits frequently turn up pingback queues holding hundreds of spam notifications that have never been reviewed. The feature is generating moderation work with zero editorial benefit. Legitimate publishers who want to notify you of a backlink have better options, including Google Search Console link reports and social mention tools.

So, is there any legitimate use case worth keeping pingbacks for? Honestly, no. The feature made sense when blog comments were a primary discovery channel. That era is gone.

How to Disable WordPress Pingbacks (4 Methods)

Disabling pingbacks takes less than two minutes using the WordPress dashboard. The four methods below go from simplest to most thorough. Most site owners need only Method 1. If you’re running a site under active attack or want the strongest possible protection, use Method 4.

Method 1: WordPress Settings (Recommended for Most Sites)

This turns off incoming and outgoing pingbacks for all new posts.

• Log in to your WordPress admin panel.
• Go to Settings > Discussion
• Uncheck “Attempt to notify any blogs linked to from the post’
• Uncheck “Allow link notifications from other blogs (pingbacks and trackbacks) on new posts.”
• Click Save Changes.

Done. New posts won’t send or receive pingbacks from this point on.

Method 2: Bulk-Edit Existing Posts

The settings change only affects new content. Your existing posts still have pingbacks enabled in their individual post settings. Fix them with a bulk edit.

• Go to Posts > All Posts.
• Select all posts using the checkbox at the top of the list.
• If you have more than one page, click “Select All” when WordPress prompts you.
• Open the Bulk Actions dropdown and choose Edit.
• Click Apply.
• In the bulk edit panel, find the Pings dropdown.
• Select Do Not Allow.
• Click Update.

Repeat for Pages and any custom post types your theme uses.

Method 3: functions.php Code Block

For developers who want to remove the X-Pingback header and prevent XML-RPC from advertising the pingback method, add this to your child theme’s functions.php file.

// Remove X-Pingback HTTP header
add_filter( 'wp_headers', function( $headers ) {
    unset( $headers['X-Pingback'] );
    return $headers;
} );

// Remove pingback from XML-RPC method list
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

This stops WordPress from advertising pingback support to any scanner checking your headers. It doesn’t break other XML-RPC features.

Method 4: Block xmlrpc.php at the Server Level

For the most thorough protection, block xmlrpc.php before requests reach PHP. This eliminates the attack surface.

Apache (.htaccess):

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

Nginx (server block config):

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Warning:If you use the Jetpack plugin, the WordPress mobile app, or any third-party service that connects via XML-RPC, blocking this file will break those integrations. Check your plugin list before applying Method 4.

If disabling XML-RPC causes plugin conflicts or unexpected site behavior, use the WordPress Safe Mode guide to isolate themes and plugins safely before restoring functionality.

[Expert Insight] The Nginx configuration is worth noting separately. It includes access_log off and log_not_found off. Under an active pingback flood, thousands of blocked requests per second generate a log file that can grow to gigabytes within hours. Silencing the log for that one endpoint protects your disk from being filled by attack traffic. This is a small detail that matters a lot during an actual incident.

How to Check If Your Site Is Being Used as a Reflector

Most site owners only discover they’ve been used as a reflector when the hosting provider sends an abuse notice. You can check proactively with four targeted inspections.

1. Review server access logs for outbound pingback requests. Look for clusters of POST requests to xmlrpc.php from unusual IP addresses, particularly if they all arrived within a short time window. A normal site gets a handful of pingbacks per week at most.
2. Watch for unexplained CPU spikes. Pingback floods consume PHP execution threads. A server that spikes to 100% CPU without corresponding page view increases is processing something in the background. Your hosting panel’s resource usage graphs are the fastest place to spot this.
3. Search your PHP error logs for xmlrpc.php entries. Failed or malformed pingback requests often generate PHP warnings. If you see hundreds of errors from that file in a single day, your site is being probed or used as a reflector.
4. Check your security plugin log. Wordfence, Sucuri, and similar plugins log blocked XML-RPC requests. A healthy site shows very few. A site being abused shows hundreds or thousands.

If you find evidence of abuse, apply Method 4 from the previous section immediately and contact your hosting provider with the log timestamps.

Frequently Asked Questions

Conclusion

Pingbacks are enabled by default, and traditional security defenses block only 12% of WordPress-specific attacks. The gap between what’s turned on and what’s actually protected is where attacks happen.

The fix is quick. Go to Settings > Discussion right now and uncheck both pingback options. Then bulk-edit your existing posts. If you don’t use Jetpack or the mobile app, block xmlrpc.php at the server level with Method 4.

Pingbacks were a feature of a different era. They’ve been a liability for over a decade. Turning them off is the lowest-effort security improvement most WordPress sites can make today.