The Sneeit Framework plugin is an extension for WordPress, the world’s most widely used content management system (CMS). Although it extends WordPress functionality, a critical vulnerability allows it to be exploited to completely compromise the system.

The risk profile of this vulnerability is Critical. It allows for Unauthenticated Remote Code Execution (RCE), meaning an attacker does not require credentials or prior access to gain full control of the web server. This is the most severe class of vulnerability for a web application.

Threat intelligence confirms that this vulnerability is being actively exploited in the wild. This is not a theoretical threat; attackers are actively scanning for and compromising vulnerable sites. Any WordPress instance exposed to the internet running a vulnerable version of the Sneeit Framework plugin must be considered an immediate, high-priority target for patching. The ease of exploitation makes it suitable for widespread, automated attacks.

Technical Summary

The root cause of this vulnerability is classified as CWE-94: Improper Control of Generation of Code (‘Code Injection’). It exists in the sneeit_articles_pagination_callback() function, which is designed to handle AJAX requests for article pagination. The function receives user-controlled input and passes it directly to the sensitive PHP function call_user_func() without proper sanitization or validation.

The attack chain is as follows:

1. An unauthenticated remote attacker sends a specially crafted HTTP request to the AJAX entry point of the vulnerable WordPress site.
2. The request contains parameters that, once processed by the Sneeit Framework plugin, are passed to the vulnerable sneeit_articles_pagination_callback() function.
3. The attacker specifies a dangerous PHP function (e.g., system, exec) and its related arguments within these parameters.
4. The call_user_func() function executes the function specified by the attacker with the provided arguments, resulting in arbitrary code execution with the privileges of the web server process (e.g., www-data).

// Conceptual representation of the vulnerable logic
function sneeit_articles_pagination_callback() {
  // The attacker controls the values of 'callback_func' and 'callback_arg'
  $user_function = $_POST['callback_func'];
  $user_argument = $_POST['callback_arg'];

  // VULNERABLE: No validation is performed before the function call
  // An attacker can set $user_function to 'system' and $user_argument to 'id'
  call_user_func($user_function, $user_argument);
}

An attacker can exploit this to install backdoors, exfiltrate the entire site database, create illegitimate administrator accounts, or use the compromised server to attack other systems.

Vulnerable versions: Sneeit Framework versions 8.3 and earlier.
Patched versions: A patch has been released. All users must update to the latest available version.

Recommendations

• Apply the patch immediately: Update the Sneeit Framework plugin to the latest available version, which resolves this vulnerability. If the plugin is not essential, the safest approach is to disable and delete it entirely.

• Mitigations: If immediate update or removal is not possible, implement a Web Application Firewall (WAF) rule to block requests to WordPress AJAX endpoints that contain suspicious function names (e.g., system, passthru, shell_exec, exec) in the request body. This should be considered a temporary measure.

• Threat hunting and monitoring:

  • Carefully analyze web server access logs (e.g., Apache, Nginx) for POST requests to wp-admin/admin-ajax.php. Look for request bodies containing parameters with values such as system, exec, or other shell command execution functions.
  • Use file integrity monitoring systems to detect the creation of unexpected new files, particularly PHP files or webshells in WordPress directories (wp-content/uploads, wp-includes).
  • Monitor for the creation of new unauthorized administrator accounts within the WordPress control panel.

• Incident response: If a compromise is suspected, take the site offline immediately by serving a static maintenance page. Isolate the server from the network to prevent further malicious activity. Initiate a forensic analysis, focusing on searching for webshells, analyzing web and database logs, and identifying unauthorized user accounts. Restore the site from a reliable backup created before the suspected date of the attack.

• Defense in depth: Ensure the web server process runs with the minimum necessary privileges. Regularly back up all site files and the database to a remote location and test the restoration process. Apply strong, unique passwords and multi-factor authentication for all WordPress administrative accounts.