This blog will contain a host of informations about various vulnerabilities and thoughts related to vulnerability management.
To view older blog posts, please visit the archives section.
2025-01-02
Happy New Year! To kick off 2025, I thought it would be fun to review the very first vulnerability published this year. And the lucky winner is: CVE-2024-56020.
Now, you might be wondering about the mismatch in the CVE number and the year—don’t worry, you’re not alone. According to the NVD APIs, this vulnerability was officially published on 2025-01-01 at 00:15:57 UTC, making it the first documented vulnerability of 2025.
Believe it or not, the first vulnerability of 2025 is a textbook example of a Cross-Site Scripting (XSS) vulnerability. Here’s the official description straight from the source:
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Mario Di Pasquale SvegliaT Buttons allows Stored XSS.This issue affects SvegliaT Buttons: from n/a through 1.3.0. - NIST NVD (external link)
In summary, this vulnerability is a stored Cross-Site Scripting (XSS) issue (as per OWASP) that affects a WordPress plugin. However, this description alone doesn’t provide enough information to fully understand the mechanics of the vulnerability.
In the sections below, I’ll dive into the relevant code, analyze where I believe the vulnerability lies, and share my thoughts on its impact and potential mitigations.
The plugin in question is designed to help WordPress post writers include beautifully styled buttons using WordPress shortcodes. For those unfamiliar, a shortcode is a type of tag that allows content creators to add various elements to a post without needing coding skills or elevated privileges.
WordPress uses square brackets ([]) to denote shortcodes. For example, a post containing a shortcode might look something like this:
This text is part of a wordpress post.
It will be supplemented by a fancy button that will be provided by the following shortcode:
[button-purple text="Download" title="Download plugin" url="http://averyrandomurl.com"]
Is this not beautiful!
The WordPress Shortcode API documentation provides detailed insights into how shortcodes work, but here’s a quick overview:
Shortcodes are parsed during webpage generation.
When a shortcode is parsed, a corresponding shortcode handler function is executed.
The handler function generates the required code—in the case of SvegliaT Buttons, this is an HTML button pointing to a URL.
Once generated, the code is sent to the client’s browser along with the rest of the webpage content.
While WordPress includes a handful of built-in shortcodes, developers can create custom shortcodes to extend functionality. The SvegliaT Buttons plugin does just that, enabling its features by defining custom shortcodes.
Each new shortcode must be registered using the WordPress function add_shortcode($tag, $callback). This function takes two parameters:
$tag: The identifier for the shortcode. In the example above, this would be button-purple.
$callback: The handler function for the shortcode.
The handler function must accept an $atts attribute, which is passed in by the shortcode parser. This $atts attribute contains the parameters specified in the shortcode, allowing the function to dynamically generate the required output.
Now that we’ve covered the basics, let’s dive into the SvegliaT Buttons plugin code to see how it implements its functionality.
The official code for this plugin was previously available on its WordPress page. However, as of December 5, 2024, the plugin has been removed from public download and is currently under review.
In case the plugin’s page becomes unavailable, I also found a copy of its repository on GitHub. All the following code extracts are from the official WordPress repository and are included here to support the reader’s understanding.
We’ll focus on the file named svegliat-buttons.php, where the main code resides and where the vulnerability seems to occur. This file contains multiple shortcode handler functions, all built using a similar pattern. For this analysis, we’ll examine the buttonpurple_func($atts) function, which handles the button-purple shortcode used as an example earlier.
Below is a code extract showing the function and the call to add_shortcode, which registers the shortcode:
221 // PURPLE BUTTON
223 function buttonpurple_func( $atts ) {
224 extract(shortcode_atts(array(
225 'text' => esc_html__('Bottone', 'st-buttons'),
226 'title' => '',
227 'url' => '#',
228 ), $atts));
230 $html = '
231 <div class="st-buttons"><a class="stbutton_purple" href="'.$url.'" title="'.$title.'">'.do_shortcode($text).'</a></div>';
232 return $html;
233 }
234 add_shortcode('button-purple', 'buttonpurple_func');
235
I’ve highlighted three distinct parts of the buttonpurple_func($atts) function, which we’ll now examine in detail:
Yellow Highlight: This section confirms that the shortcode (button-purple) and its handler function (buttonpurple_func) are registered using the add_shortcode function.
Teal Highlight: This part handles parsing the parameters provided in the shortcode. Specifically, it extracts the $text, $title, and $url parameters from the $atts array into the local namespace using the PHP extract() function. These values are supplied directly via the shortcode.
Green Highlight: This section generates the HTML code representing the button. Unfortunately, this is where the vulnerability lies. The code uses user-supplied data directly in generating the HTML without performing any form of validation, encoding, or escaping. This makes the code vulnerable to XSS injection, as an attacker could manipulate the shortcode to inject malicious code into the generated HTML. This malicious code would then run in the browser of any user viewing the compromised content.
For ethical reasons, I won’t provide the specific code to exploit this vulnerability. However, this is a textbook example of an old-school XSS vulnerability, and examples relevant to this case are widely available in security literature.
Exploitability
Based on our analysis and the original report from Patchstack, exploiting this vulnerability requires sufficient privileges to edit posts or pages. This corresponds to a minimum access level of Contributor in WordPress. Therefore, an attacker must already have some level of access—either through exploitation of another vulnerability or by leveraging trust granted to users. Without such access, the vulnerability cannot be exploited.
Spread of Use
The plugin’s WordPress page does not provide information about the number of installations worldwide. However, an archive.org snapshot from October 2024 indicates that the plugin had more than 400 installations globally at that time.
Official Fix
There is currently no official fix for this vulnerability. The plugin’s last update appears to have been eight years ago, making it unlikely that a patch will ever be released.
Mitigation Possibilities
Mitigating this vulnerability effectively requires one of:
Manually modifying the plugin’s code to address the vulnerability.
Discontinuing use of the plugin and replacing it with a maintained alternative.
Unfortunately, no other technical mitigations seem feasible.
General Notes on Shortcode Security
Security issues with shortcodes are a recurring problem in WordPress plugins. A quick search for "shortcode WordPress XSS" yields numerous reports of similar vulnerabilities. To minimize risks:
Ensure that the WordPress plugins you use are actively developed and maintained.
If feasible, have qualified personnel review the shortcode handler functions for potential vulnerabilities, especially if your WordPress installation involves many contributors.
Consider reviewing security if you suspect contributors might exploit the system.
While detailed code reviews might not always be practical for smaller teams or low-contributor environments, they are recommended for high-risk or high-contributor scenarios.
"New year, new me," as they say—but when it comes to vulnerabilities like this one, there’s nothing new. Despite being well-understood by developers, vulnerabilities like stored XSS will continue to surface in our industry for years to come.
In a world increasingly dominated by software, code hygiene is essential for protecting your business and customers from cyber threats. Ensuring secure development practices, conducting regular code reviews, and staying vigilant about outdated or unmaintained dependencies are critical steps toward a safer digital environment.
Here’s to a secure and prosperous New Year!