On July 7, Hostinger switched on Patchstack’s vulnerability intelligence for Node.js applications hosted on its Business and Cloud plans, scanning npm package dependencies for known flaws by default. One month later, the first numbers are in. The feature has detected vulnerable dependencies on more than 10,000 customer websites, and thousands of the flagged issues have already been resolved through automatic fixes or manual updates, according to Arnas Donauskas, web hosting product manager at Hostinger.
Just as interesting is what the scanning does not do. Patchstack’s Lana Rafaela draws the boundary herself: the service matches packages against disclosed vulnerabilities, and it does not catch malicious packages, typosquatting or dependency confusion, which she calls supply-chain integrity problems rather than vulnerability problems. Automatic mitigation for npm, she adds, is still on the way; today the integration is detection and guided remediation. A developer who reads “scanned” as “safe” is, in her words, getting comfortable at exactly the wrong moment.
What follows comes directly from both companies. Our team put the questions in writing; the answers came back from Lana Rafaela, senior product marketing manager at Patchstack, and Arnas Donauskas, web hosting product manager at Hostinger.
The Q&A with Patchstack
For Patchstack:
webhosting.today: Patchstack made its name in WordPress vulnerability intelligence. How different is securing the npm and Node.js dependency supply chain from securing WordPress plugins, and what did you have to build or rethink to do it?
Lana: WordPress vulnerability intelligence works because there’s a single, bounded ecosystem: one repository, plugins and themes with predictable structures, and a community that’s been disclosing and patching in public for two decades. npm is a different beast entirely – hundreds of thousands of packages, deep and often unreviewed transitive dependency trees, and a publish model with far less central curation than WordPress.org ever had.
That difference in shape is exactly what forced the rethink – technically and otherwise. The harder constraint wasn’t code; it was density of real-world Node.js vulnerability data. WordPress benefits from twenty years of public disclosure inside one repository; npm’s disclosure landscape is far more fragmented and distributed. Hostinger becoming a partner mattered as much for that as for the integration itself – it gave us access to a meaningfully larger, real-world dataset of Node.js vulnerabilities to validate and expand against, which is what took us from early-stage scanning to something we could stand behind at production hosting scale.
webhosting.today: The npm ecosystem is a favorite target for supply-chain attacks: malicious packages, typosquatting, dependency confusion. Which of these does the scanning actually catch, which does it not, and what do you say to a developer who assumes “scanned means safe”?
Lana: Today, this is vulnerability intelligence: we match a package and version against disclosed CVEs and GitHub Security Advisories and tell you which dependency is affected and what to update to – including whether exploitation has already been observed in the wild, so it’s not just theoretical risk.
What it doesn’t catch are malicious packages that were never vulnerable but written to do harm, typosquatting, dependency confusion. Those are supply-chain integrity problems, not vulnerability problems – they need reputation and publish-behavior signals, not a disclosure database, and they are something we are keeping on our radar.
To a developer who assumes “scanned means safe”: scanned means we’ll flag something you’re using the moment it’s known to be vulnerable. It doesn’t mean nothing malicious got in to begin with, or that there won’t be an issue in the future. Conflating the two is how people get comfortable at exactly the wrong moment.
webhosting.today: What’s on the roadmap beyond Node.js, should hosts and developers expect the same default scanning for Composer/PHP, PyPI/Python, or other ecosystems, and on what timeline?
Lana: We built the npm expansion to expand detection beyond WordPress, and it’s proven to be able to help with that. Making protection as effortless as it is with our WordPress offering is the next frontier.
In terms of which ecosystem comes next – this isn’t a roadmap slide we’re ready to publish just yet, but it’s worth mentioning where we see the same security issues repeating: AI-assisted development driving adoption faster than security literacy or tooling can keep up. That pattern isn’t unique to Node.js. We’re not committing to a specific ecosystem or date yet, but the direction is clear enough that “which one’s next” is a “when,” not an “if.”
webhosting.today: With default scanning now running through both Hostinger and GoDaddy, if vulnerability management becomes bundled into hosting by default, what does that mean for standalone security tools?
Lana: Those two aren’t quite the same thing yet. GoDaddy’s Managed WordPress integration includes our full RapidMitigate stack – automatic protection rules, not just detection. Hostinger’s Node.js integration is vulnerability intelligence today – detection and guided remediation, with automatic mitigation for npm still on the way. So “default scanning” is real in both, but “default protection” isn’t there yet everywhere.
To the actual question: once detection is bundled into hosting by default, a standalone tool that only tells you something’s wrong has a shrinking reason to exist as a separate purchase – that layer becomes table stakes, like an SSL certificate today.
Where standalone tools keep a real role is depth: proprietary data that allows for faster protection and incident response, penetration testing, compliance reporting, anything that needs a human judgment call rather than a database match. The distribution layer moves into the host. The detection and judgment layers stay separate.
The Q&A with Hostinger
To open (either side):
webhosting.today: Since it went live on July 7, what has it shown in numbers: how many vulnerable dependencies has it flagged, how many were auto-fixed, and what share of eligible sites are actually using it?
Arnas: The early results show that the feature is doing exactly what it was designed to do: uncover risks customers might otherwise miss and give them a clear way to address them. So far, it has detected vulnerable dependencies on more than 10,000 customer websites, with thousands of issues resolved through automatic fixes or manual updates within just a few weeks. That’s a strong sign that customers are acting on the alerts quickly.
For Hostinger:
webhosting.today: You enabled this by default (opt-out) on your Business and Cloud plans. Why default-on, and was there internal debate about doing that without asking users first?
Arnas: We chose to enable it by default because security works best when protection is active from the start. Many Node.js developers, especially those focused on building their applications, don’t continuously monitor dependency vulnerabilities. Our solution reduces the burden on users while still keeping them in control of whether to apply updates.
webhosting.today: Beyond the raw numbers, what has the developer reaction been: false-positive rates, friction, any pushback?
Arnas: So far, the response has been positive. Users appreciate being notified quickly when critical security vulnerabilities are discovered, allowing them to patch the issue before it becomes a bigger problem.
webhosting.today: How much does a feature like this actually move purchase decisions, and are customers starting to choose a host based on built-in supply-chain security?
Arnas: We don’t disclose commercial metrics, but we do see built-in security becoming increasingly important for customers. As developers look for ways to reduce operational overhead, features like automated vulnerability detection and patching add meaningful value, especially in managed Node.js hosting.
webhosting.today: If a scanned app is still breached through a dependency, where does the platform’s responsibility end and the developer’s begin?
Arnas: Security is a shared responsibility. Our role is to identify known vulnerabilities, alert developers, and provide tools to fix them quickly. Developers remain responsible for the applications they build, the dependencies they choose, and validating that updates work correctly within their projects.
webhosting.today: For a non-developer running a store or app on Node.js, who doesn’t know what a dependency is, what does this actually change for them day to day?
Arnas: It removes a lot of complexity. Customers don’t need to understand dependencies or keep track of security updates themselves. When we detect a known vulnerability, we notify them and offer an automatic or one-click fix where possible. This lets them spend less time on security maintenance and more time running their business.
Five Years Out: Both Answers
To close (both):
webhosting.today: Five years out, does “your host scans and patches your dependencies for you” become the industry norm, or stay a differentiator for a few? What has to happen for it to become standard?
Lana: I’d bet on industry norm, not a differentiator for a few – but with a condition attached. It becomes standard the way SSL did: once it’s free, invisible, and doesn’t require the host to build or maintain the underlying intelligence themselves. Hosts don’t want to become vulnerability researchers; they want a layer they can plug in.
However, in order for that to happen, we need broader ecosystem coverage, mitigation – not just detection – across all of them, and enough hosts doing it that “we don’t monitor your dependencies” starts reading as a gap rather than a neutral default. We’re further along that curve for WordPress, where the model’s already proven out, and users are no longer content with hosts offering server protection. They’re actively looking for hosts who can protect their application layer, and they refuse to pay for generic “this isn’t in our wheelhouse” answers from hosts.
Arnas: I believe that in five years, auto-fixes will likely become standard. The process should go even further: the host prepares a secure, updated version of the site, and once the user confirms that everything is working properly, it goes live automatically. The goal is to make the process as simple as possible while keeping the final decision with the user.
