A Learning Journey: Attempting to Turn a WordPress Theme CVE into a PoC

One evening, while participating in a public bug bounty program, I encountered an outdated WordPress website within scope. I decided to run a scan using WPScan (https://github.com/wpscanteam/wpscan) on the target and identified several potential vulnerabilities. Most required an authenticated user, which wasn’t feasible in this context, but one stood out as not requiring any authentication at all.

The specific CVE in question was CVE-2024–2848. This vulnerability, described as follows, states: “The Responsive theme for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the save_footer_text_callback function in all versions up to, and including, 5.0.2. This allows unauthenticated attackers to inject arbitrary HTML content into the site’s footer.” Essentially, this bug enables an unauthenticated user to permanently modify the website’s footer with arbitrary text, compromising the site’s credibility and endangering visitor safety.

My immediate reaction was to search for a Proof of Concept (PoC), but I soon discovered that none had been publicly released. A year ago, I might have given up, but this time I felt confident in my ability to reverse engineer this CVE with assistance from ChatGPT.

First, I created a local WordPress environment to install the vulnerable theme version and conduct my tests without risking any real website damage. For this, I used a docker-compose.yaml file provided by Rhynorater, who co-hosts the excellent Critical Thinking Podcast. The next step was to obtain the vulnerable theme. Since it was patched in version 5.0.3, I opted for version 5.0.2. Although downloading old theme versions isn’t straightforward, observing the network tab in Chrome DevTools while downloading the current version revealed the URL pattern: https://downloads.wordpress.org/theme/responsive.5.0.7.zip. By changing the version number in the URL, I successfully downloaded an older package.

With WordPress and the vulnerable theme installed, I began examining the code. Fortunately, WordPress maintains a record of code changes, so I reviewed the differences to identify anything suspicious. The changelogs indicated that only two files were relevant and that the patch addressed this vulnerability along with a few minor UI changes.

Next, I analyzed the class-responsive-customizer-tinymce-control.php file. Given its brevity, I fed it into ChatGPT, requesting it to locate the CVE and create a PoC based on the description. It quickly identified the section of code making a POST request via Ajax to the /wp-admin/admin-ajax.php endpoint.

Developing a PoC was straightforward. The following CURL request modifies the website’s footer to display the word “hacked”:

Upon successfully inserting text, I considered the possibility of injecting JavaScript to elevate the severity of this exploit. While examining the second file, functions.php, I discovered the section of code responsible for sanitizing the “footer_text” before it is processed in the POST request. The “wp_kses_post” function, a built-in WordPress function, is employed to prevent XSS by allowing only a specific set of HTML tags and attributes deemed safe for use in posts. These tags include common ones such as <a>, <b>, <i>, <p>, <strong>, <em>, <ul>, <ol>, <li>, <blockquote>, among others. It became evident that escalating the exploit would not be feasible.

With the PoC validated, I contacted the website’s support team to discuss the potential vulnerability and received permission to make a minor change to their footer. It is crucial never to make live changes to a website without authorization. Ultimately, I failed to reproduce the bug on their site, likely due to WPScan reporting a false positive on the theme version, which can occasionally occur. Despite this, I was pleased with the outcome as I gained valuable experience and successfully reverse-engineered a CVE for the first time.