You spend significant time and resources building a well-managed, secure internal network for your clients. Firewalls are properly configured. Endpoints are patched and monitored. Access controls are enforced. The internal environment is professional, layered, and defensible. Then the client’s website gets compromised through an outdated WordPress plugin, and your phone starts ringing.
The website was never part of your scope. The hosting is on a cheap shared server that the client’s original marketing agency set up six years ago. Nobody has updated the theme or plugins in months. The WordPress core is two major versions behind. A vulnerability scanner would flag it in seconds. A threat actor may already have.
Now the client’s homepage is redirecting visitors to a pharmacy spam site. Google has flagged the domain as dangerous. The client’s email domain reputation is degrading because the compromised server is being used to send phishing emails at scale. None of this is your fault. All of it is generating support tickets that your engineers are spending unbillable hours cleaning up.
The Attack Surface You Did Not Create
A compromised website on a shared hosting environment creates attack surface that extends well beyond the website itself. Understanding the threat model helps you explain the situation to your client and justify the infrastructure changes that need to happen.
Shared hosting means the client’s website files live on the same physical server as dozens or hundreds of other websites managed by other clients of the same hosting provider. When one site on a shared server is compromised, weak separation can increase the blast radius, potentially exposing other sites on the same server. A client who chose cheap shared hosting to save a modest monthly amount has placed their website in an environment where their neighbors’ security failures can become their problem.
An outdated WordPress installation is one of the most common entry points for web-based attacks. WordPress powers a substantial percentage of all websites on the internet, which makes it a high-value target for automated scanning and exploitation. Attackers run continuous automated sweeps of the internet looking for specific vulnerable plugin versions, outdated themes, and unpatched WordPress core installations. When they find one, exploitation is frequently automated. The attacker does not necessarily know or care whose website it is. They are looking for compromised environments they can use to distribute malware, send spam, host phishing pages, or mine cryptocurrency.
The lateral movement risk is the part that most directly concerns your managed infrastructure. If the compromised website is hosted on the same server as any database or portal the client uses for internal operations, that compromise can become a pathway into more sensitive systems. Client portals that live on the same hosting account as the marketing website are a particularly common problem. These portals may handle customer account data, internal forms, or scheduling systems. A developer who set them up years ago thought it was convenient to put everything in one place. Convenience is the enemy of security.
Proactive External Monitoring
Add client domains to your external monitoring routine. This does not require access to their hosting environment and it costs you nothing beyond a small operational investment.
Several free and low-cost services will notify you when a domain appears on Google’s Safe Browsing blocklist or other major threat intelligence feeds. Google Search Console sends security issue notifications when Google detects malware or hacked content on an indexed site, but the client must be enrolled and you must have access to their Search Console account to receive these alerts. Setting this up takes fifteen minutes and should be standard practice for any client whose reputation depends on their domain.
Vulnerability scanners targeted at web applications can run against a client’s public domain without any access to the hosting environment. Tools like Sucuri SiteCheck or similar services can identify outdated CMS versions, blacklist status, and known malware signatures from the outside. Running these scans on a regular schedule, monthly at minimum, gives you early warning of deteriorating website security before a breach occurs.
The client’s WordPress version and major plugin versions can often be inferred from the publicly accessible readme.html file and the generator meta tag in the HTML source. Both disclose version information by default in older installations. An installation running several major versions behind the current release is a liability. The same applies to popular plugins like WooCommerce, Elementor, or Contact Form 7. In practice, large version gaps often indicate a higher likelihood of known weaknesses, unsupported components, or missed security patches that should be reviewed promptly.
Isolating the Web Environment
The most important architectural change you can recommend is strong isolation of the web hosting environment from any internal system or database the client uses for business operations.
The web server should generally host only the public website. Customer portals, internal tools, employee scheduling applications, and administrative dashboards should not share hosting infrastructure with the public marketing website. These are separate concerns with different security requirements and they should live in separate environments.
If the client needs their website to interact with internal data, that interaction should happen through a defined, authenticated API endpoint, not through shared file system access or a shared database on the same server. This architectural boundary is the line that prevents a website compromise from becoming a breach of the client’s operational systems.
A Web Application Firewall deployed in front of the client’s public domains provides an additional layer of protection that does not require access to the hosting environment. A WAF inspects incoming traffic before it reaches the web server and blocks requests that match known attack patterns. Common WAF services operate as a DNS-level proxy, meaning you update the DNS configuration to route traffic through the WAF provider before it reaches the origin server. In many client setups, this change sits comfortably within the DNS management you already control.
Rate limiting on login pages and form submission endpoints reduces the effectiveness of brute force attacks and automated spam. Many WAF services include these controls as part of their standard configuration.
The Offloading Conversation
The business conversation with your client is straightforward. Website security maintenance is a recurring operational responsibility that their current arrangement is not meeting. Applying plugin updates, monitoring for vulnerabilities, maintaining current WordPress versions, and responding to security events requires ongoing attention from someone who knows what they are looking at. The cheap shared hosting environment they are paying for does not include any of that.
This is not a criticism of the client. It reflects the gap between what hosting providers sell and what website security actually requires. A client paying fifteen dollars a month for hosting is not getting managed security. They are getting disk space.
You are not the right team to fill this gap. Routine website maintenance and security patching is a different discipline from infrastructure management and it does not fit your service model. Every hour your engineers spend cleaning up a malware infection or applying WordPress updates is an hour they are not spending on the infrastructure work you actually get paid to do.
Boston Web Group provides routine website maintenance under a clear service agreement that covers monthly plugin and theme updates, WordPress core updates, security monitoring, proactive patching, and malware remediation if an incident occurs. We operate under a strict partnership agreement with MSP partners that defines our scope precisely and protects your client relationship. We do not compete for your infrastructure work. We handle the web layer through structured support plans so you can stop fielding those calls.
The outcome for your client is a website that is more likely to stay current, stay clean, and stop generating avoidable security incidents. The outcome for your helpdesk is that your engineers spend more of their time on work that fits your scope and your margins. The client gets a more complete security posture instead of a gap between two vendors pointing fingers at each other.
Your network is locked down. The website should be too.
Related reading: How MSPs Can Deliver Custom Client Portals Without Taking on the Development Work, How to Prevent Website Migrations from Breaking Client Email Systems, and The Security Risk of Bundling Your Domain, Hosting, and Email.