131,000 Attacks Target WordPress Sites via Sneeit RCE Flaw

A critical remote code execution flaw in the Sneeit Framework WordPress plugin has triggered over 131,000 attack attempts since late November 2025. Wordfence logged 15,381 attacks in a single 24-hour period on 10th December, and the numbers are still climbing.

The vulnerability, CVE-2025-6389, scores 9.8 out of 10 on the CVSS scale. That's about as bad as it gets. It lets unauthenticated attackers upload malicious PHP files and create admin accounts on your WordPress site without needing any credentials at all.

The patch has been available since August. But patches don't install themselves, and Sneeit Framework isn't the kind of plugin most site owners think about regularly.

How the Vulnerability Works

The flaw sits inside a function called sneeit_articles_pagination_callback(). This function handles AJAX pagination requests, and it accepts a type parameter from the user. That parameter gets passed directly to PHP's call_user_func() without any validation.

If you're not a developer, here's what that means in plain terms: the plugin takes whatever instruction a visitor sends it and executes it as PHP code. No checks. No filters. No asking "should this person be allowed to do this?"

It's like leaving your front door unlocked, removing the hinges, and putting a sign outside that says "come in and help yourself." Attackers can upload files, read your database credentials, create admin accounts, and install backdoors that survive future updates.

What Attackers Are Actually Doing

The attacks follow a predictable pattern. Two things happen almost immediately after a successful exploit:

First, a new administrator account appears. The most commonly observed username is "arudikadis," though variations exist. This gives the attacker persistent access even if you patch the vulnerability later.

Second, malicious PHP files get uploaded. Wordfence has identified several variants: tijtewmg.php, xL.php, Canonical.php, .a.php, and simple.php. These function as backdoors, letting the attacker return whenever they like to scan directories, modify files, extract database credentials, and do whatever else they fancy.

The attack traffic comes from a distributed set of IP addresses, so simple IP blocking won't help. Most of the sources trace back to hosting providers and VPN services, which is typical of attacks launched through compromised infrastructure.

"WordPress plugin vulnerabilities accounted for 97% of new security vulnerabilities in the WordPress ecosystem, with themes accounting for the remaining 3%."

- Wordfence 2024 Annual WordPress Security Report

That statistic hit me hard when I first read it. We've been hosting WordPress sites since the platform's early days, and the plugin ecosystem has always been a double-edged sword. You get incredible flexibility, but you're also depending on thousands of independent developers to write secure code. And as this report shows, that dependency is the single biggest source of risk for every WordPress site.

Who's Actually at Risk

Any WordPress site running Sneeit Framework version 8.3 or earlier is vulnerable. The vendor released a patch in version 8.4 back on 5th August 2025. That fix has been sitting there for four months.

But plugin updates don't happen automatically unless you've specifically configured them. And the Sneeit Framework isn't one of those plugins you think about regularly. It's a backend toolkit that theme developers use to manage options and layouts. Most site owners don't even know it's installed.

If you're running themes from ThemeForest that bundle Sneeit, custom themes built with Sneeit's option panels, or legacy sites where the plugin was installed years ago and forgotten, you likely have it on your server right now.

The 1,700+ active installations figure only counts sites that report usage statistics. The actual number is almost certainly higher.

And before you assume your shared hosting would protect you: it won't. Most shared hosting environments don't have application-layer firewalls that can detect and block these specific exploit patterns. As we saw with the King Addons vulnerability earlier this month, updates aren't always happening quickly enough.

How to Check If You've Been Hit

If you're running a vulnerable version, check for signs of compromise right now. Here's what to look for:

Indicator Type	What to Look For
Rogue Admin Accounts	Username "arudikadis" or similar variations with administrator privileges
Malicious PHP Files	tijtewmg.php, xL.php, Canonical.php, .a.php, simple.php in WordPress directories
Suspicious Requests	POST requests to /wp-admin/admin-ajax.php with unusual parameters
File Modifications	PHP files modified after 24th November 2025
Server Logs	Repeated access attempts from unknown IP addresses targeting admin-ajax.php

Check Your User Accounts. Log into your WordPress admin panel and navigate to Users. Look for any accounts you don't recognise, particularly ones with administrator privileges.

Scan Your WordPress Directory. Connect via FTP or SSH and check your WordPress root directory and /wp-content/ for recently modified PHP files with the names listed above.

If you find any of this, you've been compromised. Don't just delete the files. The attacker may have modified core WordPress files or installed additional backdoors you haven't found yet.

At that point, you need a proper cleanup: full malware scan, database audit, and credential rotation. We handle this regularly for our managed WordPress hosting customers, and it's never as simple as deleting a couple of files.

What You Need to Do Right Now

Update Immediately. If you're running Sneeit Framework, update to version 8.4 or later. This should be your first action, before anything else.

Audit Your Site. Even if you've patched, check for signs of compromise. Look for unknown admin accounts, suspicious PHP files, and unusual database activity.

Rotate Your Credentials. Change your WordPress admin password, database password, and FTP/SSH credentials. If an attacker gained access before you patched, they may have extracted these already.

Enable a Web Application Firewall. A proper WAF would have blocked these attacks before they reached your WordPress installation. Our WordPress Turbo Hosting includes enterprise-grade firewall protection that targets WordPress vulnerabilities specifically.

Set Up Monitoring. You need to know immediately if someone creates an admin account or modifies critical files. File integrity monitoring should be standard on every WordPress site. Our secure hosting platform includes this out of the box.

This vulnerability is being actively exploited right now. The 15,000+ attacks yesterday came in waves, suggesting coordinated campaigns or automated scanning tools adding this exploit to their repertoire.

"Security is not a product, but a process. It's more than designing strong cryptography into a system; it's designing the entire system such that all security measures, including cryptography, work together."

- Bruce Schneier, Secrets and Lies: Digital Security in a Networked World

Schneier wrote that over two decades ago, and it's still the most useful framing I've found for thinking about WordPress security. A patched plugin doesn't make a site secure. Secure hosting, monitoring, backups, WAF rules, properly configured security headers, and credential hygiene all have to work together. The sites that get hacked are almost always the ones where one of those layers was missing or out of date.

Why This Keeps Happening to WordPress

This is the third major WordPress plugin vulnerability under active exploitation in December 2025 alone. We covered critical WordPress plugin vulnerabilities earlier this month, and the pattern is becoming depressingly familiar.

Plugin developers often lack the security expertise to write code that withstands determined attackers. Functions that accept user input and pass it to dangerous PHP functions like call_user_func() should have multiple layers of validation. But they don't, because the developer was focused on functionality, not security.

The fix for CVE-2025-6389 was released in August. We're in December now, and attacks are accelerating. That four-month gap between patch and widespread exploitation is typical. Attackers know that most WordPress sites don't update plugins promptly.

If you're managing multiple WordPress sites without proper security infrastructure, you're taking on real risk. A recent study found 661 WordPress vulnerabilities in a single week, with 164 still unpatched. The volume is staggering, and it's only getting worse.

This is exactly why we push security-first hosting at 365i. Automated plugin updates, daily malware scans, and application-layer firewall protection aren't optional extras. Our agency hosting customers don't have to worry about these vulnerabilities because we're monitoring for them constantly.

The cost of a breach vastly exceeds the cost of proper managed hosting. We've seen businesses lose weeks of revenue to a single compromised plugin. Others had their Google rankings tank after malware injection because Google flagged their site as dangerous. Once that happens, recovery takes months. The Modular DS vulnerability that hit 40,000 sites is another recent example of how quickly these things escalate.

For more on keeping WordPress secure through proper updates, our look at the WordPress 6.9 caching bug explains why even routine updates need testing and monitoring.

Frequently Asked Questions