Why You Shouldn’t Install WordPress Plugins Without Speaking to Your Web Team
Key Takeaway: Even the most well-intentioned plugin install can open the door to persistent security threats, reputational damage, and months of cleanup. A simple plugin request process with your web dev team protects your site, your brand, and your peace of mind.
Why You Shouldn’t Install WordPress Plugins Without Speaking to Your Web Team
You’ve found a plugin that looks perfect. It promises exactly the feature your website is missing, and it takes less than a minute to install. Your web team is busy and you don’t fancy the bill if it isn’t covered in your plan. The plugin has a four-star rating, so what’s the harm?
We understand this impulse completely. And maybe it’s not you, but a trusted member of your team who says they know what they’re doing. WordPress is designed to feel accessible, and that accessibility is genuinely one of its strengths, but that same openness is also the reason your website needs a carefully managed approach. A website is closer to a managed IT environment than it is to a blank canvas, and plugins are the single biggest variable in whether it stays secure.
This post isn’t about creating hoops to jump through or trying to scare you. It’s about explaining what can go wrong, so that the process your web team follows makes sense.
A Real Example: From a Helpful Plugin to a Hidden Casino
Recently, one of our clients found themselves in exactly this situation. Looking to add functionality quickly, a staff member downloaded a plugin that looked credible enough.
The plugin appeared to work, and nothing broke on the website. So far, so good! However, when the site’s speed was much slower than expected during our routine maintenance, the performance issues prompted a deeper look and the picture changed considerably.
Our security software flagged a particular plugin that we had made redundant during updates anyway. We attempted to uninstall it through the standard WordPress dashboard, but it wouldn’t budge. It had embedded itself in a way that the normal removal process simply couldn’t reach.
A technical examination of the code uncovered two alarming things:
- Backdoor credentials. Hidden administrator login details baked directly into the plugin’s code, giving an unknown third-party ongoing access to the site regardless of what passwords were changed. This login doesn’t show up as a user, so there was nothing to remove, and no visible sign that someone had logged in this way.
- An illegitimate Indonesian casino website piggybacking off one of the client’s subdomains. This site was hosted quietly in the background, invisible to the client, but very visible to Google and responsible for the considerable slowdown of the site.
Cleaning up required a full manual audit of the site’s file system and database. It was time-consuming, and the knock-on effects took time to resolve. None of it was irreversible, but all of it was avoidable.
We:
- Removed the code (twice – it reinstalled itself!)
- Recreated and deleted profiles that had been targeted and made using the old ones instant lockout offences
- Strengthened the firewall
- Blocked a string of IP addresses that were being used repeatedly
- Ensured 2FA was enabled for all logins
- Added additional security measures to make the website too much hassle for someone to try again!
Plugins Are the #1 Attack Vector for WordPress Sites
WordPress itself (the core software) is maintained by a large, dedicated security team and is updated regularly (if your web team doesn’t keep your site updated, please make sure you update WordPress to help your site stay secure!). The vulnerabilities that affect WordPress sites overwhelmingly don’t come from the core. More than 95% of WordPress security issues originate from third-party plugins.
That’s not a criticism of plugins as a concept, as they are incredible tools, many of which are free. Most plugins in the official WordPress repository are perfectly safe and go through a review process. The risk increases significantly when plugins are downloaded from unofficial or unverified sources, particularly “nulled” plugins, which are paid plugins distributed for free on third-party sites. These often contain hidden malware as part of the package.
It’s also worth noting that even reputable plugins can be compromised if their ownership changes and the new developers push a malicious update. It happens, and it’s why ongoing monitoring matters as much as the initial vetting.
Even a plugin that is downloaded from the WordPress repository can be problematic. As a general rule, the smaller the number of people who have installed it, the riskier it is as a proposition.
Why “Just Uninstall It” Doesn’t Always Work
This is perhaps the most important technical point to understand, explained as plainly as possible.
When you uninstall a plugin through the WordPress dashboard, WordPress removes the plugin’s main folder. A sophisticated malicious plugin will have already written code to other locations, such as your site’s configuration files, your theme files, or a special directory that WordPress loads automatically and cannot be switched off via the admin panel.
Backdoor code in these locations can silently recreate hidden administrator accounts even after you’ve deleted them. Changing your password doesn’t help if the attacker’s own login credentials are hardcoded separately into the site’s files. Full removal requires finding and manually deleting every trace, which requires direct access to the site’s server environment, not just the WordPress admin panel.
Sometimes, these code fragments can be surprisingly sticky, reinstalling themselves and requiring further hardening of security measures.
The Subdomain Issue: What “Piggybacking” Actually Costs You
The casino site discovered on our client’s subdomain is an example of what’s known as parasite SEO. Here’s what that means in practice.
Your domain builds authority with search engines over time with every page you publish, every link you earn, every blog adding to that trust (there’s a lot more to it than that, but for purposes of this article, it will suffice). Attackers exploit this by hosting their own content on a subdomain of your site. Their gambling pages inherit some of your domain’s authority, helping them rank for casino-related search terms. Meanwhile, Google may begin to associate your entire domain with that content.
The consequences aren’t limited to a rankings dip. Clients, partners, or prospective customers who stumble across those pages will find a casino site sitting inside your web address. Depending on your sector, there can also be legal and regulatory implications for inadvertently hosting gambling content, or sex industry content, which is also a common sector for this practice. Recovering your domain’s SEO credibility after an incident like this can be a slow process, and one that could have been prevented entirely.
Shadow IT: When Good Intentions Create Hidden Risk
There’s a term for what happens when software gets installed on a business system without the knowledge or approval of the team responsible for managing it: shadow IT. It happens in companies of every size, and it almost always comes from a good place, i.e., someone trying to solve a problem quickly, independently, without creating extra work for anyone else.
The difficulty is that every plugin installed without your web team’s knowledge is a piece of code running on your site that your web team cannot see, cannot vouch for, and cannot properly maintain. It removes their ability to keep a complete picture of what’s on the site and that visibility is the foundation of everything they do to keep it secure and running smoothly.
Think of your website the way you’d think of any other managed business system. You wouldn’t ask someone to add a new electrical circuit to your office without involving a qualified electrician, even if the job looked straightforward. The same logic applies here.
What to Do Instead: The Simple Request Process
The alternative to installing a plugin yourself isn’t a lengthy approvals process. It’s a short conversation.
When you come across a plugin you think would be useful, do this:
- Note down the problem you’re trying to solve, not just the plugin name. (“We need clients to be able to book appointments online” is more useful than “I found this plugin called BookNow.”)
- Send that context to your web team and ask whether there’s a suitable solution. They may already have one, or know of a better-vetted option. Often, there are features in your current plugins that may not have been utilized yet.
- Let them run through their checks. A proper vetting process covers the plugin’s source, its update history, the developer’s reputation, its active install count, known vulnerabilities, compatibility with your existing setup, and a test run in a staging environment before anything touches your live site.
That process takes far less time than recovering from a compromised site. And it means that whatever gets installed is something your team can support, update, and monitor going forward.
A Note Before You Go
Your web team is a safeguard for your digital storefront. We didn’t write this blog to scare anyone (it really was a worst-case scenario!), but having experienced it, we felt it needed saying.
If you have a plugin you’ve been meaning to request, or if something about your site isn’t behaving as it should, we’re always happy to take a look. No obligation, just a straightforward conversation. If you’d like to chat, you can book in here.
