Your customers will never report a malware infection by name.
Instead, they’ll complain that your site makes their laptop hot, freezes their browser, or drains their phone battery.
These are the classic symptoms of a Coinhive malware WordPress infection, a type of hack that steals visitor resources. If those reports align with strange scripts you’re seeing in your site files, it’s time to investigate for a cryptojacking hack right away.
Run a malware scan now. Coinhive shut down in 2019, but old Coinhive code, copycat miners, and similar malware still show up on hacked WordPress sites. If malware is found, don’t just delete the obvious script. Clean the files, database, users, passwords, backdoors, and cache, or the infection can return.
Before you panic, look for clues. Search your site files and database for unusual strings like Coinhive, Coinhive Anonymous, cnhv, coinhive.min.js, AuthedMine, Crypto-Loot, or fake analytics and CDN scripts. A plain mention of the word in a blog post is not a problem. A script that runs in the browser is.
Here’s the useful way to frame it. Coinhive is usually the symptom. The access that let someone add code to your WordPress site is the part you have to fix. Find the infection, remove it fully, and close that access.
Understand Coinhive malware
Coinhive was a browser-based Monero mining service. Monero is a cryptocurrency, and mining uses computer power to verify transactions and earn coins. Coinhive lets a website use a visitor’s browser for that work.
That became a security problem when attackers added Coinhive scripts to sites they didn’t own. Visitors didn’t agree to it. Site owners often didn’t know it was happening. The only sign might be a slow page, a hot laptop, or a browser tab using far more power than it should.
The original Coinhive service shut down in 2019. That matters. A Coinhive warning in 2026 doesn’t always mean the old service is live on your site. It may mean an old injection was never removed, a security scanner found a Coinhive-era pattern, or a newer miner is using the same trick.
Treat any Coinhive-style finding as a hacked-site warning first and a performance issue second. Some campaigns have mixed miners with keyloggers, which are scripts that can record what someone types into a form.
How Coinhive malware gets into WordPress
WordPress doesn’t install Coinhive by itself. If your WordPress site is hacked, an attacker found an entry point first.
The usual paths are old plugins, neglected themes, weak admin passwords, stolen hosting logins, unsafe uploads, or forgotten WordPress installs in subfolders. Once the attacker gets access, they can add mining code where WordPress stores page output: theme files, plugins, widgets, database settings, or header and footer areas.
That’s why deleting one suspicious line isn’t enough. The line may be only the part your browser can see. The file or database entry that keeps adding it may still be there.
Signs your site may be infected
Coinhive-style malware can be loud or quiet. Some miners push a visitor’s computer hard. Others run slowly so they stay hidden for longer. A quiet inbox doesn’t clear the site. Watch for signs that point to a hack:
- Visitor complaints: hot laptops, loud fans, frozen tabs, slow browsers, fast battery drain, or “your site slows down my computer.”
- Security warnings: host suspension, browser warnings, malware scanner alerts, or search result warnings.
- Site changes: unfamiliar files, new admin users, edited theme files, odd header or footer output, or sudden changes in bounce rate.
- Suspicious code: hidden iframes, fake Google Analytics or jQuery scripts, fake Cloudflare or CDN names, unknown domains, or long scrambled JavaScript that your theme or plugins do not explain.
Don’t rely only on searching for the word Coinhive. A harmless article can contain that word. What matters is whether suspicious code loads as a script or iframe on your live pages.
Damage Coinhive malware can cause
The obvious damage is a bad visitor experience. Browser mining can use CPU, drain batteries, heat devices, freeze tabs, and make your site feel broken.
The business damage can be worse. Visitors leave, complain, or stop trusting the site. Hosts may suspend the account. Browsers or security tools may show warnings. Search engines can reduce trust in hacked pages, which can hurt organic traffic.
There is also cleanup cost. The longer malware sits on a site, the more places it can spread and the harder it gets to know what changed. If you suspect malware, scan immediately.
Scan before changing files
If your site is still online, scan it before making edits. I know the urge is to open the file manager and start deleting anything that looks strange. That can break the site, remove useful evidence, and still miss the malware.
You have three scan options.
Use a deep WordPress scanner
This is the best first move for most site owners. A good malware scanner checks more than the public page that visitors see. That matters because a miner can be stored in a theme file, a plugin file, a database option, or content that WordPress prints into the page later.
MalCare fits this step because it checks the file system and stored site content. If it finds malware, you get a clearer picture of the affected areas instead of guessing from one browser warning.
Run an online scanner
An online scanner can help with quick triage. It may catch an infected public page, a hidden iframe, a known unsafe domain, or a script that loads for visitors.
Use it for a first check. Then keep going if the symptoms still point to malware. Public scanners can miss database injections, hidden backdoors, logged-out-only malware, and code that changes based on the visitor.
Inspect manually only if you know WordPress files
Manual scanning means checking files and database entries yourself. That can work if WordPress structure is familiar to you. It’s risky if every PHP file looks the same. Check these areas once, in this order:
- root files, especially index.php, wp-config.php, .htaccess, wp-settings.php, and wp-load.php
- core folders, mainly wp-admin and wp-includes, against clean WordPress files
- theme output files that add scripts to the page, especially functions.php and header or footer templates
- plugins, uploads, widgets, page builder content, database options, and users
If this list feels too wide, stop there and use a cleanup tool or a specialist. The scary-looking string is rarely the hardest part. The quiet file that puts it back tomorrow is.
Remove Coinhive malware from WordPress
Once a scan confirms malware, clean the whole compromise. A page that looks normal for five minutes isn’t enough. You want a site that stays clean after cache clears, users log in, and visitors return.
Use malware removal
For most WordPress owners who need to remove WordPress malware, this is the route I’d choose. Use a trusted malware removal tool or security service, then complete the post-hack checklist below.
MalCare’s malware removal is useful here because Coinhive-style infections often spread across files and database content. You should not have to decide, under pressure, whether a strange encoded block is safe or malicious.
After cleanup, scan again. Then check a few public pages in a fresh browser session, especially the pages where complaints started.
Hire a security professional
Bring in a specialist if the site handles sensitive data. That includes checkout pages, customer logins, member accounts, and lead forms. Do the same if the infection keeps returning or your host has already suspended the account.
Ask what they checked. A proper cleanup should cover these areas:
- database content and users
- passwords and access accounts
- theme, plugin, and scheduled task changes
- subdomains and nested WordPress installs
- backdoors, which are hidden ways for an attacker to get back in after the visible malware is removed
Clean manually only with a rollback plan
Manual cleanup is possible, but it isn’t a good place to improvise. Work from a backup, use staging if you can, and compare against clean copies of the same WordPress, plugin, and theme versions.
Start by saving evidence and access details: If your host suspended the site, ask for the infected-file list and a safe access method. Save scan results before you change anything.
Create a backup before cleanup: The backup may contain malware, but it gives you a rollback point if cleanup breaks theme files, plugin settings, or custom code.
- Compare against clean WordPress files: Replace clean core directories such as wp-admin and wp-includes. Be careful with root files because some sites have legitimate changes there.
- Review themes and plugins carefully: Look for unknown scripts, recent edits, fake analytics files, and suspicious code in theme output files. Remove software you don’t use, especially abandoned or nulled plugins.
- Clean the database, not just files: Check posts, options, widgets, page builder data, and user accounts for injected scripts or unfamiliar admin users.
- Check uploads and odd PHP files: Upload folders should mostly contain media and documents. PHP files inside uploads deserve close review.
- Remove backdoors with care: Functions such as eval, base64_decode, gzinflate, preg_replace, and str_rot13 can appear in malware, but context matters. Blind deletion can break legitimate code.
- Clear every layer of cache: Purge the cache in WordPress first. Then clear the host, CDN, and browser layers. Old infected HTML can keep reaching visitors after the source has been cleaned.
- Scan again after reuploading: A second scan is not optional. It tells you whether the cleanup worked or only removed the easiest symptom.
Recover and prevent reinfection
Post-hack work is where many cleanups fail. The site looks fine, everyone relaxes, and the attacker still has a password, a hidden user, or an old vulnerable plugin.
Change WordPress admin passwords first. Then rotate credentials for anything that can edit files, change DNS, send password resets, or access the database. Use a different long password for each account. Add a second login check too, so a stolen password isn’t enough to log in.
Remove users who shouldn’t be there. Check WordPress admins, FTP/SFTP users, database users, and old agency or developer accounts. Keep administrator access tight.
Bring WordPress itself up to date, then patch your active plugins and theme. Delete what you don’t use. If you restore from a backup, make sure you’re not restoring the same infected content or the same vulnerable plugin version.
For ecommerce, membership, and lead-generation sites, review the infection window. If a keylogger may have been present, you may need to inspect orders, form entries, and admin activity. Customer notification can become a legal or policy question, so don’t guess.
Prevent another infection
Prevention is less dramatic than cleanup, but it saves you from doing this twice.
- Keep the WordPress install current, including the theme and every active plugin. Remove unused plugins and themes. Avoid nulled software because cracked copies often carry hidden malware.
- Use long, one-of-a-kind passwords on the accounts that matter most. Start with WordPress admin and hosting. Then cover SFTP, database, and email accounts. Add two-factor authentication wherever the service offers it. Limit admin users. Review new users and file changes often enough that surprises stand out.
- Add a firewall and ongoing malware scanning. A firewall filters bad traffic before it reaches WordPress, and regular scans catch file or database changes before customers become your alert system. MalCare is a practical fit here because it combines scanning, cleanup, and firewall protection for WordPress sites.
- Keep backups, but treat them carefully. A backup from the wrong date can contain the same malware. A clean backup restored onto an unpatched site can get hacked again.
If users can upload files to your site, monitor uploads and activity logs closely. A strange file upload or unexpected admin login is easier to handle early than after it becomes a full infection.
FAQs
Conclusion
Coinhive is old, but the problem behind it isn’t. When your WordPress site serves code you didn’t approve, treat the incident as a full-site compromise. Start with a scan. Clean carefully, rotate access, purge cached pages, and test the public site in a fresh browser.
The best outcome isn’t only removing one miner script. It’s knowing how the script got there, closing that path, and putting monitoring in place so the next suspicious change is caught early. That is what turns a cleaned page into a safer WordPress site.
