Every hosting provider deals with abuse reports. They’re part of the job. But some of the reports we receive—and the situations that cause them—are genuinely preventable. Often embarrassingly so.
We’ve anonymised these examples, but they’re all real. Consider this a guide to what not to do, learned from people who did exactly that.
The Phishing Kit They Didn’t Know About
What happened: Customer’s site got flagged for hosting a PayPal phishing page. They were genuinely confused—they’d never created any such page.
What we found: A complete phishing kit buried in /wp-content/uploads/2019/fake-folder/. The site was running WordPress 4.9 with plugins that hadn’t been updated in three years. Someone had exploited a known vulnerability, uploaded the phishing pages, and been harvesting credentials for months.
The lesson: Update your software. Check your sites periodically. If you haven’t logged into a PBN site in six months, you have no idea what’s actually on it. This customer lost the domain—the phishing had been active long enough that the domain itself was blacklisted beyond recovery.
The Accidental Crypto Miner
What happened: We noticed unusual CPU usage on a customer’s account. Investigation revealed JavaScript cryptomining code injected into every page.
What we found: The customer had installed a nulled theme—a premium theme downloaded free from a dodgy website. The theme included obfuscated JavaScript that loaded a crypto miner on every page view. Visitors’ browsers were mining cryptocurrency for someone in Eastern Europe.
The lesson: Nulled themes and plugins are never free. You pay in other ways—malware, backdoors, SEO spam, or in this case, turning your visitors into unwitting crypto miners. The customer saved maybe £50 on a theme and lost far more in cleanup time and reputation damage.
The Copyright Strike Avalanche
What happened: Customer received seven DMCA takedown notices in one week. All for different images on the same site.
What we found: They’d rebuilt an expired domain using Wayback Machine content, including all the original images. Those images were stock photos the original site had licensed. A stock photo agency’s crawler found them, and their automated system fired off takedown notices.
The lesson: When restoring from Wayback, never assume you can use the images. We’ve written about this extensively—images are often more problematic than text because stock agencies actively hunt for unlicensed use. Replace all images with ones you’ve actually licensed or created.
The Brand Impersonation Fiasco
What happened: Received an angry legal letter from a well-known software company. Customer’s site was allegedly impersonating their brand.
What we found: The customer had bought an expired domain that previously belonged to an authorised reseller of this software. They’d restored the old content, including the company’s partner logos, certification badges, and product descriptions. To anyone visiting, it looked like an official partner site—except it wasn’t, and the content was three years out of date.
The lesson: Restoring business sites is risky precisely because of branding and partnership claims. The original owner had legitimate rights to display those logos. You don’t. This is why we keep banging on about not using brand logos you haven’t earned the right to use.
The Spam Cannon
What happened: Customer’s entire account got suspended. They were furious, insisting they’d done nothing wrong.
What we found: One of their WordPress sites had a compromised contact form plugin. Attackers were using it to send tens of thousands of spam emails per day. The sending IP got blacklisted, which affected other customers, which meant immediate suspension.
The lesson: Contact forms are a common attack vector. If you have forms on your PBN sites, make sure they have proper spam protection. Better yet, ask yourself if you actually need a contact form on a PBN site. Usually you don’t. Remove functionality you’re not using—every feature is a potential vulnerability.
The Gambling Content Surprise
What happened: Customer complained their site was showing casino ads they hadn’t placed.
What we found: An old advertising script in the theme was still active. The original ad network had been sold, and the new owners were serving gambling content. The customer’s wholesome recipe blog was now displaying ads for online casinos, which violated the terms of the ad network they’d actually signed up with, resulting in their account being banned.
The lesson: Audit external scripts periodically. That analytics code from 2019 might now be serving something completely different. Third-party scripts can change without notice, and you’re responsible for what appears on your site.
The SEO Spam Injection
What happened: Customer noticed their site had dropped from search results entirely. Asked us to investigate server issues.
What we found: No server issues. Their site had been hacked and was serving hidden pages full of pharmaceutical spam to search engine crawlers—thousands of pages about Viagra, Cialis, and various other medications. The pages were invisible to normal visitors but perfectly visible to Googlebot. Google had removed the entire site from their index.
The lesson: Check what Google actually sees. Use Search Console. Use “site:yourdomain.com” searches. Cloaked spam pages are designed to be invisible to you while being very visible to search engines. By the time you notice the ranking drop, the damage is done.
The Innocent Redirect Chain
What happened: Received an abuse report claiming the customer’s site was redirecting to malware.
What we found: The site itself was clean. But it had an outbound link to another site, which had been compromised, which redirected to a third site serving malware. The customer’s site was being flagged because it was part of the redirect chain, even though their site wasn’t directly compromised.
The lesson: Monitor your outbound links. Sites you link to can become compromised. If you’re linking out to external resources, check periodically that those resources are still legitimate. Our dashboard includes tools to track outbound links across your network for exactly this reason.
The Template Malware
What happened: New customer migrated sites to our hosting. Within days, multiple sites were flagged for malware.
What we found: They were using the same compromised theme across their entire network. Every site had the same backdoor. The theme had been infected before they ever installed it—probably from the source they downloaded it from. They’d efficiently distributed malware across their own network.
The lesson: When you use the same theme across multiple sites, you’re replicating any problems that theme has. Scan themes before deployment. Get them from legitimate sources. And consider varying your themes across the network anyway—using identical themes is a footprint.
The Competitor Report Bomb
What happened: Customer received multiple abuse reports in quick succession, all vague, all from similar-sounding email addresses.
What we found: Nothing actually wrong with the sites. The reports were fabricated—likely by a competitor trying to get sites taken down. The “evidence” provided was either doctored or completely unrelated to the actual sites.
The lesson: Not all abuse reports are legitimate. We investigate before acting. But this is a reminder that competitors can and do try to weaponise abuse reporting systems. Keep your sites clean so that when frivolous reports do come in, there’s nothing for anyone to find. We’ve written about this reality at https://pbn.ltd/can-my-pbn-networks-be-reported-by-my-competitors-to-google/.
Common Threads
Looking across these examples, patterns emerge.
Neglect is the biggest risk factor. Sites that get checked regularly rarely end up hosting malware for months. Sites that are set up and forgotten are sitting ducks.
Free stuff has hidden costs. Nulled themes, cracked plugins, pirated templates—they come with malware more often than not. Pay for legitimate software or use genuinely free alternatives.
Updates matter. Outdated WordPress installations with outdated plugins are the primary entry point for most compromises. Automatic updates exist for a reason.
Less is more. Every plugin, every form, every external script is potential attack surface. If you’re not using it, remove it.
None of the customers in these examples set out to host phishing pages or mine cryptocurrency. They made small mistakes that compounded into serious problems. Learn from their experiences so you don’t have to learn from your own.
If you’re concerned about any of your sites, our support team can help with security audits. And if you want sites built properly from the start, our PBN building service handles security considerations as part of the standard setup process.