As of today, almost a billion sites have been built using WordPress, powering businesses and organizations of all sizes. That makes any newly discovered vulnerability especially concerning—like the one recently found and reported by Imperva researchers, which could affect any WordPress site. In this blog post, we’ll explain the attack itself, the conditions that made this attack possible, and provide a demonstration.
We responsibly disclosed this vulnerability to WordPress and released our report after 90 days.
To immediately understand how you can check if your site is vulnerable and how to mitigate this threat, please jump directly to the section Vulnerability Test & Mitigation.
Executive Summary
Imperva discovered and reported a vulnerability potentially affecting all WordPress sites, enabling a threat actor to potentially exfiltrate sensitive private and draft post titles. To protect your site, you’re strongly encouraged to update your WordPress site with the latest version and disable the XMLRPC endpoint if you don’t use it.
More information is provided in the last section.
Leaked Titles Equals Real Threats
Leaking draft or private titles from WordPress blog posts can significantly harm a company by prematurely exposing sensitive information. Let’s review a few examples to demonstrate the potential impact.
The accidental early release of Google’s earnings report in 2012 led to a 9% drop in stock price, erasing about $22 billion in market value within minutes1. Similarly, in 2019, news of Google’s intended acquisition of Fitbit leaked before the official announcement, causing stock volatility and complicating negotiations due to increased market speculation and regulatory scrutiny2. Unauthorized disclosures like these can result in insider trading, legal liabilities, and damage to a company’s reputation. Such breaches erode trust among stakeholders and can lead to substantial financial losses.
Fig 1: Illustration of the potential consequences of takeover early leaks
Description of the Attack
We discovered that an attacker could leak the titles of all private or draft posts via a specifically crafted XMLRPC payloads. The attack consists of a series of POST requests sent to the XMLRPC endpoint of the victim’s site. According to the way the server responds to the request, the attacker can progressively exfiltrate the titles of private and draft posts.
Demonstration in Video
Deep Dive Into the Attack Flow
The attack relies on the XMLRPC feature. This feature is enabled by default in all new installations since WordPress 3.5 (released in December 2012). This feature enables standard communication between different systems—for example, sites developed with blogging platforms other than WordPress.
One of the capabilities provided by XMLRPC is `pingback`.
The pingback feature in WordPress automatically notifies another blog when you link to it in a post, creating a comment-like backlink on the linked blog’s post if it supports pingbacks. The flow is the following:
- An end user publishes, in blog 1, a post or a comment including a link to blog 2.
- Blog 1 automatically sends a pingback message to blog 2.
- Blog 2 verifies if the link is indeed a link to one of its blog posts.
- Blog 2 navigates to Blog 1 to make sure the link exists in the post.
Fig 2: Illustration of PingBack feature in WordPress
The issue arises during step 3.
Blog 2 tries to verify if indeed a blogpost corresponding to the incoming request data exists in the MySQL database.%
Fig 3: WordPress Core section responsible for Pingback functionality
The pingback request contains two crucial pieces of information: the URL of the page that supposedly contains the link (pagelinkedfrom) also called source url, and the URL of the post on Blog 2 that was linked to (pagelinkedto), also called target url.
As soon as the request arrives, Blog 2 triggers the xmlrpc_call action, allowing any plugins or additional functions to interact with this event. It then sanitizes the input arguments to prevent any malicious data from causing harm. Then, it normalizes the URLs by replacing HTML entities. It ensures that any & in pagelinkedfrom is converted back to &, and in pagelinkedto, it does the reverse to maintain proper URL encoding.
Before proceeding, Blog 2 checks whether the source URL is valid. If it’s empty or malformed, it returns an error indicating that a valid URL wasn’t provided. It also verifies that the target URL actually points to its own site.
Afterwards, it tries to parse and identify the target URL pattern among the following:
- Path-Based ID: It checks if the URL path contains a pattern like p/123, which might represent the post ID.
- Query String ID: It looks for a query parameter like ?p=123 in the URL.
- Fragment ID: If there’s a fragment (anchor) in the URL, it might indicate the post ID.
If none of the above methods work, Blog 2 cannot determine the post ID and returns an error stating the target URL cannot be used.
The issue arises when a fragment is present in the target URL.
In this case, a regular expression removes any character outside a-z or 0-9 and searches a match in any post title present in the database. But the query doesn’t only search public posts, but instead matches and returns any existing blogpost, including private or draft posts.
If there is a match, Blog 2 reaches the source URL to verify it indeed includes the target URL.
Therefore, an attacker can hijack this workflow and search for any string pattern in all post titles present in the database including private or draft posts. Later in the blogpost, we call this mechanism `Oracle`. The next section describes in detail how an attacker could exploit it.
Exploitation
The exploitation of this vulnerability consists of two parts:
- Interrogation of the Oracle.
- Determination of the right substrings to send to the Oracle to leak sensitive information, while minimizing the number of requests to send to the victim’s server.
There are 2 ways an attacker could determine if a given string exists in the list of private or draft titles.
Interrogation of the Oracle
Scenario 1: The attacker sets an external server. Then, he submits a pingback request with the following payload:
Fig 4: Example format of a malicious payload
The attacker server would log, from the `pattern` parameter of the URL, the list of substrings matching an existing post in the WordPress SQL database.
Scenario 2: A simpler way to achieve the same result is by exploiting the delay introduced in the pingback function in case of a match (sleep(1) is used the code). However, in this case, the attacker would need to define a baseline depending on the network response time. If the response to the request exceeds the baseline, a match is likely for the given substring.
Determination of the Right Requests to Send to the Oracle
We believe that the most efficient way for a threat actor to exploit the Oracle is by defining a prefix corresponding to the keywords he expects the private or draft titles of interest, to start with. For example, `Acquisition of `, `Acquired `, `Merger with ` …
Then, the threat actor scans the Oracle for each possible next character following the prefix. For each match of the Oracle, the threat actor creates a new branch to scan, where the prefix is prefix + match[i].
Fig 5: Illustration of the exploitation of the Oracle
The threat actor lets the algorithm run until a configured maximum title size is reached, configurable by a threat actor. The number of branches nbranch is bounded by the number of titles starting with the given prefix.
Therefore, the number of requests needed by the threat actor to achieve the attack is bounded by nbranch x alphabet_size x max_title_size, which is easily achievable by a threat actor.
Vulnerability Test & Mitigation
If you are an Imperva customer, you are already protected against this attack. Both CWAF and WAF-GW customers have dedicated protection against this threat.
Otherwise, we created a script that you can use to determine if your site is vulnerable to this attack. You can find it here. If your site is vulnerable, it should print “Your site is not protected against XML-RPC title leak attacks”. You’re then recommended to either protect your site with WAF technology, or disable the pingback functionality of your WordPress site.
1 https://www.wired.com/2012/10/google-shares-plunge-as-earnings-results-leak-early/
2 https://www.reuters.com/article/technology/exclusive-google-owner-alphabet-in-bid-to-buy-fitbit-sources-idUSKBN1X71NY/?utm_source=chatgpt.com
The post Beware! A threat actor could steal the titles of your private (and draft) WordPress posts! appeared first on Blog.
