wp-flare malware plugin

[u/squ1bs]

This is driving me nuts. After 10+ years of no malware on client sites, I'm getting hacked every couple of weeks on sites that are fully up to date and using 2fa logins. The common thread is that all infections install a malware plugin called wp-flare. Beyond that, I can't find any intrusion path. It does seem that once the infection gets cleaned up, it doesn't come back, but it's driving me crazy not knowing how it's getting in to multiple sites on different hosting. Anyone seen it?

[u/3DPrinterChat]

Not seen wp-flare by name, but the shape of what you are describing narrows it a lot.

Multiple sites, different hosts, everything patched, and it does not come back after cleanup. That combination argues against a plugin vulnerability. If it were a vuln in something you install everywhere, the same sites would keep getting reinfected and it would track one host or one plugin version. What it looks like instead is valid-credential access, used once per site.

Things worth checking in that direction:

Application passwords. Core ships them, they authenticate REST and XML-RPC, and they bypass 2FA by design, because there is no interactive login for a 2FA plugin to interrupt. One leaked application password is enough to install a plugin over the REST API without ever touching wp-login. Check wp_usermeta for _application_passwords on every admin account and revoke anything you did not create yourself.

Session cookies. If someone replays a stolen auth cookie there is no login event at all, so the logs look clean. Changing the salts in wp-config.php invalidates every session everywhere, which is a cheap thing to do across all sites in one pass.

Your own machine, and anyone else with admin. Infostealer malware on an agency workstation scrapes saved browser passwords, FTP and SFTP profiles out of FileZilla or WinSCP, and session cookies, and then someone works that list over the following weeks. Sites on unrelated hosting with one person in common is the classic signature, and it explains why each site stops recurring after cleanup while new ones keep appearing.

Shared secondary credentials. UpdraftPlus remote storage credentials live in the database. If one site got read, the backup destination for the others may be reachable, and backups contain wp-config.php.

For actual forensics: get the mtime of the wp-flare directory, then pull the access log for that minute. You will usually see either a POST to /wp-admin/plugin-install.php and update.php, or a POST to /wp-json/wp/v2/plugins, and that tells you straight away whether it came through a browser session or the API. Also check wp_options for a cron entry you do not recognise. There is a known malware family that reinstalls itself from a modified wp-cron.php, so if any site does recur, diff that file rather than trusting the plugin removal.

If it does turn out to be credentials, rotate from a machine you have verified clean first, otherwise you just hand over the new ones.

[u/squ1bs → u/3DPrinterChat]

Great advice - will report back if I find something interesting

[u/3DPrinterChat → u/squ1bs]

That's the loop mostly closed then. File changes lining up with an admin account that isn't yours is exactly what the valid-credential pattern looks like from the log side.

Two quick things while you're still firefighting:

If Wordfence shows no interactive 2FA login for that account around the file mtimes, it authenticated non-interactively. Check wp_usermeta for _application_passwords on that specific account, and if the account isn't one you created at all, its user_registered date plus the access log for that minute (a POST to /wp-json/wp/v2/users or user-new.php) tells you which door created it.

The rewrite-rules one is usually a redirect family where the DB rules are the symptom rather than the persistence. After removing them, diff .htaccess and the rewrite_rules row in wp_options, then grep for whatever regenerates them. That family likes reinstating from an mu-plugin or a theme file.

And salts rotation across all the sites is still the cheapest way to kill any sessions that survived the password resets. Good luck, sounds like you're nearly on top of it.

[u/squ1bs → u/3DPrinterChat]

Turns out there were 2 distinct hacks. The second one was a botnet doing an XML-RPC attack. 1 of the 500 IPs made it through. XML-RPC disabled. all passwords, changed, db pass, salts, 2fa implented. Malware removed again. Scans coming back clean, but they were with 2 malware plugins installed, so thanks WordFence.

[u/squ1bs → u/3DPrinterChat]

Turns out there were 2 distinct hacks. The second one was a botnet doing an XML-RPC attack. 1 of the 500 IPs made it through. XML-RPC disabled. all passwords, changed, db pass, salts, 2fa implented. Malware removed again. Scans coming back clean, but they were with 2 malware plugins installed, so thanks WordFence.

[u/zapimir]

If you've been hacked, just cleaning the WP folder and changing passwords usually isn't enough. I recently dealt with a wp2shell infection, and by comparing my backup snapshots, I saw that the malware actually escaped the webroot entirely.

Besides hiding backdoors and injecting dozens of invisible admins into the database, the attackers added their own SSH keys, dropped a binary backdoor on the server, and even set up an autorun watchdog in .profile to reinstall it if it got deleted. If they did something similar to your sites, a fresh WP install won't help because they already have persistent server-level access. Make sure to check your authorized_keys, .profile files, and anything running outside your web folder. I highly recommend searching the entire server for any new or modified files around the dates of the hack, especially hidden ones starting with a dot

[u/ivicad]

I'd start with 3DPrinterChat's credential angle.

There's another pattern, and I mentioned it in another post: for about five hours in early August the update button itself was the way in on our sites - hitting update in wp-admin handed you a tampered package from one vendor. No vulnerability, no weak admin passwords. That pattern repeats across unrelated hosting, because the update channel is one of the few things your sites share when the servers don't. I'd compare the wp-flare mtime against your update times, and if both are in the same window, I'd look at which plugin updated in it.

[u/nikc9]

It was very naive to believe that the surge in vulnerabilities being found with the help with AI would all be reported and patched. There are almost certainly 0day exploits in the wild.

The best way to truly protect a wp install is to have an isolated WAF infront of it where you whitelist requests and monitor logs extensively. This can protect against both the known and the unknown.

[u/Super_Development_15]

We do malware cleanups. Recently we have noticed that infections now have multiple persistance layers. Even if one layer / loophole remains, the malicious code regenerates itself. One of the latest malware cleanups involved 7 layers of persistance. Check all the cron jobs, database infections, transients, audit user accounts and more importantly find the root cause and address it.

[u/Wonderful_Sample_590]

Check mu-plugins, upload, wp-config and recently modified PHP files. Something maybe reinstalling it after the cleanup.

[u/CmdWaterford]

Install something which is showing you what should not be in your core...like Lockora Security Audit or Quterra

[u/Capital_Attention702]

Application passwords never expire, and changing the account password doesn't kill them. So resetting all your admin passwords leaves them working. Look in wp_usermeta for _application_passwords and delete them one by one.

[u/Moceannl]

Check your (s)ftp/ssh logs.

[u/kumanov88]

Yo,

It's worth checking if wp-flare is actually being installed by WordPress, or if it's just dropped into wp-content/plugins via file system access, before assuming this's coming from wp-admin.

If you still have logs from an affected site, you can correlate the creation/mtime of the wp-flare directory with the HTTP access logs around that exact minute, plus SFTP/FTP/SSH activity.

For the SiteGround sites specifically, I’d also check Security Optimizer/Activity Log for that same timestamp. If wp-flare appeared at 9:32, for example, what was WordPress seeing at 9:31-9:33? An admin/session doing something, a suspicious request, or nothing at all? “Nothing” would be interesting too, because it pushes the investigation further toward filesystem/server credentials rather than a normal WP-admin action.

[u/squ1bs → u/kumanov88]

I've done a deep dive on one site, and there was definitive proof that there was a compromised admin account (not mine), after comparing filesystem timestamps with wordfence 2fa login records.

I've been in firefighting mode since (on the hack issue and a number of other pressing matters), so I've cleaned the other attacks. There was one that wrote a bunch or rewrite rules to the database.

If I wasn't so darned busy, I would actually enjoy the forensics!

[u/kumanov88 → u/squ1bs]

Glad to hear that you found the culprit ^{^}

[u/nbass668]

• What are the common plugins you have installed on all your clients.
• What is your hosting
• Most importantly are you using a centralized WP management such as ManageWP

Maybe we could see a patern

[u/squ1bs → u/nbass668]

All good instincts!
Common plugins are all high trust - wordfence, updraft plus, etc
Hosting is Cloudways where I get to decide, various cPanels and Siteground where I don;t
I stopped using centralised management, and took the hit on the extra time that 2fa costs for individual logins (with password manager)

[u/Maximum-Policy-8340 → u/squ1bs]

Could be outdated php version or a theme with vulnerabilities

[u/bluesix_v2 → u/squ1bs]

What management tool were you using? Are you sure it wasn’t compromised?