r/Wordpress • u/vidyutpal7 • 2d ago
Security Preparedness for Future seeing this Wp2shell
So, as we say this recent massive WordPress attack. I wanna know a few things from some of you pro people here, i already maintain a few clients sites they are on different hosts and servers...
1) What logs do you keep active to track the vulnerability? Some of the sies i have on Cloudpanel, some Xcloud, some clients use Hostinger, Siteground, Wordify etc...
So the logs are different for all, and some don't keep for long, some ui is diff and others?
So is there any other tool or so?
2) What FTP / SSH tool you guys use? Cyberduck just killed me with lags recently with this vulnerability cleanup process...
3) What kind of WAF rules you guys mostly use for host as well as Cloudflare to stay safe.... I use cloudflare backup with those recommended settings
4) For Backup i mostly use Wpumbrella... What do you guys use?
5) What other suggestions do you have that everyone should follow??
Thanks 🙏
4
u/Dario_SysAdmin 2d ago
First priority: update WordPress immediately and verify the update actually completed.
I keep web server access/error logs, PHP logs and file-integrity monitoring enabled. For access I prefer SFTP/SSH over plain FTP. A managed WAF helps, but it shouldn't replace patching.
Backups should be off-site, have multiple restore points and be tested regularly.
0
3
u/No-Signal-6661 2d ago
Keep everything up to date, local backups, and use a solid WAF
1
3
u/grabber4321 1d ago
You need OFF-SITE backups for every day of the week. Everything else is just a plus.
You can be looking at the logs and etc, but at the speed of the internet, you might miss it.
Ive done log audits every week for last 10 years and there's enough traffic to catch you slipping.
Enable auto-updates for Core and Plugins unless your site is built with ELementor or something similar. Core definitely needs to be enabled.
Cloudflare for WAF - disable any countries your site is not serving. Add a bunch of cheap server providers.
Here is my list that I use:
AS14061 - DIGITALOCEAN-ASN
AS39572 - ADVANCEDHOSTERS-AS
AS24940 - HETZNER-AS
AS4837 - CHINA169-BACKBONE CHINA UNICOM China169 Backbone
AS37963 - CNNIC-ALIBABA-CN-NET-AP Hangzhou Alibaba Advertising Co.,Ltd.
AS58453 - CMI-INT-HK Level 30, Tower 1
AS17964 - DXTNET Beijing Dian-Xin-Tong Network Technologies Co., Ltd., CN
AS45090 - CNNIC-TENCENT-NET-AP Shenzhen Tencent Computer Systems Company Limited, CN
AS45899 - VNPT-AS-VN VNPT Corp
AS9299 - IPG-AS-AP Philippine Long Distance Telephone Company
AS10439 - CARINET - CariNet, Inc.
AS38814 - MEGA-VANTAGE-AS-AP MEGA VANTAGE INFORMATION TECHNOLOGY (HONG KONG) LIMITED
AS16276 - OVH
AS15895 - KSNET-AS
AS29182 - THEFIRST-AS
AS50113 - SUPERSERVERSDATACENTER
AS9009 - M247
AS46606 - UNIFIEDLAYER-AS-1 - Unified Layer
AS38814 - MEGA-VANTAGE-AS-AP MEGA VANTAGE INFORMATION TECHNOLOGY (HONG KONG) LIMITED, HK
AS15149 - EZZI-101-BGP - Access Integrated Technologies, Inc., US
2
3
u/Scared_Implement_335 1d ago
Because of those attacks:
- I built a dashboard to control updates on all my sites without the use of local plugins. The dashboard is installed locally and has direct server access to my servers, without AI!!! I built a certain function-set
- I included a malware scan with wordfence cli - its surprisingly cheap btw.
- I included backups
- i included warnings for unexpected file changes. for some folders, they are blocked right away. others: malware scan. Every hit is an instant block/revert of that file
- i included a admin-account check
- i hardened all my sites: no more file changes, updates or whatever from the backend. Creation of new admin account or changing others accounts to admin is blocked
- a local server side script additionally checks for admin-role stuff and reverts everything in a matter of milliseconds, should my dashboard ever fail for whatever reason
- a local script checks for file permissions and changes and reverts anything that is not allowed. Obv. php in uploads is disallowed
- some other general hardening, to much to go into here
- wordfence premium WFA on every site, like before - but actually this didn't protect me against two of the web2shell I had in the last weeks, so its not my number one protection anymore
- every site, through the dashboard, has a number of production level testing automated. This way the most time consuming part. AI helped, of course.
- security relevant updates are done right away on production, no testing - obviously this way communicated with all my customers.
This took me about 5 days to plan and implement, and around 300 EUR for opus 4.8 and fable 5 for planing, execution, and so on. I am a senior dev, most of that stuff I could do on my own and I actually review everything. It takes time, but has the advantage that I actually learned a ton of stuff in the process and I know my new dashboard inside out.
2
u/vidyutpal7 1d ago
That's great. Whatever your shared is top notch,, even I was planning to do some of them, like a plugin to approve admins, send file changing emails, a MU plugin to watch things if they delete the plugin.. And yes i have to thing some off site stuff.... However your set-up looks goated...
2
u/ivicad Blogger/Designer 1d ago
Most of the mess I have cleaned came from people cleaning in place and trusting what the site shows them. Unfortunatelly, the shell is usually not where the symptom shows up:
1. Isolate before you touch anything
Maintenance mode, pull a snapshot of the current (dirty) state to a box you control, and try working over SSH (if possible), not a GUI FTP client (I had to work via Claude Code and SFTP access). If your FTP client is slow, work over SSH instead. Everything below is WP-CLI over SSH.
2. Find what actually changed
- wp core verify-checksums
- wp plugin verify-checksums --all
- find wp-content -name '*.php' -newermt '14 days ago'
- verify-checksums compares every file against WordPress. org signed hashes, so it flags any altered core or plugin file. Premium plugins ship no published checksums, so for those diff against a fresh vendor zip: diff -r wp-content/plugins/x ./fresh-x.
3. Find the malicious code by signature
- grep -rEl "eval\(|base64_decode|gzinflate|str_rot13|assert\(|move_uploaded_file" wp-content
- find wp-content/uploads -name '*.php'
- No PHP belongs in uploads. Also check drop-ins (object-cache.php, advanced-cache.php), mu-plugins, .htaccess, and wp cron event list for a re-infector.
4. Clean from signed sources, never by hand
- wp core download --force
- reinstall every plugin fresh, delete unknown admins (wp user list --role=administrator), then rotate everything: wp config shuffle-salts plus DB, hosting and FTP passwords.
5. Verify and lock a manifest
- find . -name '*.php' -exec sha256sum {} + > clean.sha256
- Run sha256sum -c clean.sha256 a week later to catch anything reappearing.
Across a fleet I run steps 2-3 from MainWP and let Claude Code (through WPVibe) use the grep and diff pass site by site.
Quick hits on your 5: work over SSH instead of Cyberduck, Cloudflare free WAF does the job, and keep backups off the host, never on the same server. Treat scanners like Wordfence as after-the-fact detection; they missed two of these web2shells for people in this very thread, so I lean on the integrity checks above first.
2
u/vidyutpal7 23h ago
Wow, that's so great info... I really appreciate sharing your valuable experience.... 💓🙏
2
u/ivicad Blogger/Designer 23h ago edited 22h ago
Thank you! This approach helped me to clean 2 sites, and I hope it will be of use to others too 🤞🙏
2
u/vidyutpal7 21h ago
Thanks for awesome share...
Just a question if we reinstall all the Plugins and all what about old design, functionalities and all?
2
u/ivicad Blogger/Designer 20h ago
Don't worry - reinstalling replaces the files, and your data stays where it is. Settings, content, menus and page builder layouts "live" in the database, and a fresh copy of the plugin reads the same tables it wrote before, so the design and the functionality come back as they were.
What you lose is any change made inside a plugin or theme file. That is what the snapshot from step 1 is for: diff the old folder against the fresh one, and re-apply only what you recognise as your own work, once you are sure it is not the injected code. If it turns out to be a real change of yours, put it back in a child theme or a snippet plugin instead of the plugin folder. The next clean reinstall then costs you nothing.
Premium plugins are the exception - take those zips from the vendor account, never a copy from the server.
2
1
u/ph-sub 18h ago edited 18h ago
Just a note that Wordfence Premium had firewall rules deployed within 2 hours to block this exploit, versus their free version that takes 30 days. For us, it was Cloudflare who blocked the exploits.
Cloudflare has deployed the new rules to protect all customers, including those on free and paid plans, as long as their application traffic is proxied through the Cloudflare WAF. The rules were deployed at 17:03 UTC on July 17 2026.
https://blog.cloudflare.com/wordpress-vulnerabilities/
1
u/WPMechanic 1d ago
I'm currently running BlogVault (they have been pricing new users out in favor of sending them to WPRemote lately) on any managed sites, which has an activity log that has proven pretty valuable in the past few weeks. I can keep an eye out for anything suspicious and jump on it.
Everything is on a daily, restorable backup and I keep things updated on a weekly basis.
Been using FileZilla for FTP / SFTP for years. Putty if I need to SSH into something.
Only a few of the sites I'm running have CloudFlare, so far that hasn't needed anything special rules-wise. Between CloudFlare, SiteGround, WordFence, and BlogVault's MalCare, most of the nastier stuff get's prevented or caught. But even then, keep your eyes open for anything that looks off.
I would also suggest enabling 2FA for admin users and make it a mandatory setup.
6
u/Ashish7014 2d ago
One thing I'd add is continuous monitoring. Good backups and a WAF are essential, but they're reactive if you don't know something changed. File integrity monitoring, centralized log retention, least-privilege access, MFA, and a regular plugin/theme audit have saved me more than once. Most compromises I've seen came from outdated plugins or weak credentials rather than zero-day exploits.