Security teams keep sending vulnerability notifications, and the same pattern keeps repeating. Many alerts land, few lead to fixes. A new qualitative study digs into what happens after those reports arrive and explains why remediation so often stops short.
The research comes from the Center for Information Security Saarbrücken and is based on in depth interviews with 24 hosting provider organizations across shared hosting, VPS services, and web agencies. The researchers focused on how providers receive, process, and act on vulnerability notifications, rather than testing new notification formats or channels.
Providers are reachable and aware
Most hosting providers in the study knew what vulnerability notifications were and said they receive them regularly. Only three of the 24 interviewees were unfamiliar with the concept. WHOIS records, abuse mailboxes, and provider portals remain the main entry points for these reports.
Providers reported that notifications usually make it to the right inbox, even when infrastructure layers add complexity. Messages with technical evidence, such as logs or proof of concept details, were taken seriously regardless of who sent them.
Remediation rates still hover between 20 and 30 percent, consistent with earlier studies cited by the researchers. The interviews suggest the reason lies deeper inside provider operations.
Notification handling workflow. Incoming reports are analyzed by abuse teams and abusive content taken down, with further actions depending on the HPO. Reports are otherwise forwarded to customers, and escalation to customer support depend on user action and contract terms.
Responsibility lines stop remediation
The strongest theme across interviews was a strict boundary around responsibility. Hosting providers see infrastructure security as their job and application security as the customer’s job. That line applies across managed and unmanaged services.
Providers reported quick action when a notification involved phishing, malware delivery, or illegal content. Those cases threaten other customers or create legal risk. In contrast, reports about outdated CMS versions, vulnerable plugins, or insecure code were usually forwarded to customers without further action.
Interviewees described this boundary as non negotiable. Low cost hosting plans leave little room for staff to investigate application flaws. Several providers cited high ticket volumes and thin margins as reasons they cannot spend time fixing customer code.
Informal handling dominates
Formal playbooks for vulnerability notifications were rare. Most providers rely on individual judgment rather than standardized procedures. Larger organizations tended to route reports through abuse teams, while smaller providers handled everything through one or two staff members.
Certifications such as ISO standards did not meaningfully change this process. Interviewees said those certifications focus on datacenter controls, backups, or disaster recovery. They do not require providers to patch customer applications.
Decisions about whether to act often depend on who reads the message and how busy they are that day. This variability helps explain why similar notifications can receive different responses across providers.
Customers slow the process further
Customer behavior plays a major role in what happens next. Providers described website owners as slow to respond, confused by technical language, or unwilling to pay for cleanup services. Several interviewees said customer follow up consumes more time than the original report.
Unmanaged hosting contracts limit providers to sending notifications and documentation links. Managed services offer more help, but only when customers request it. Proactive patching without customer approval was widely viewed as risky, both technically and legally.
Some providers take limited proactive steps, such as disabling compromised sites, when abuse threatens shared infrastructure. Those cases are exceptions rather than standard practice.
Abuse is common but tolerated
Interviewees across shared hosting and VPS services said compromises are routine. WordPress infections, outdated plugins, and weak passwords appear daily. Most providers believe their isolation controls keep these issues from spreading.
Monitoring focuses on uptime and resource usage, not application security. If a compromised site does not strain CPU, memory, or network limits, it often goes unnoticed. Vulnerability notifications can surface issues providers were not tracking, but awareness alone rarely changes outcomes.
Providers serving enterprises or public sector clients showed more interest in deeper remediation. Those organizations operate under different pricing and risk models. For low cost shared hosting, interviewees viewed application layer security as an optional service rather than a baseline expectation.
Misaligned incentives
The study points to a structural gap between researchers, hosting providers, and website owners. Researchers identify risks. Providers host the systems but deny ownership of the flaws. Website owners hold responsibility but often lack skills or motivation.
Improving email wording or sender reputation will not solve that gap. The researchers suggest that future efforts should focus on lowering the cost of remediation for providers and making fixes easier to pass along to customers.