Hackers Are Exploiting Vulnerabilities 8 Hours Before They’re Publicly Disclosed, Security VP Warns

Anybody over 40 probably remembers when cybersecurity had a simpler tempo: A software company announced a vulnerability and then, hopefully, everybody patched before attackers were able to exploit it. Well, that window has officially gone from weeks to negative time.

A new H1 2026 report by Radware says the average time between a vulnerability’s public disclosure and its first observed exploitation fell from 53 days in 2024 to 21.5 days in 2025. By July this year, it dropped to negative eight hours. That’s a whole night’s sleep before providers and end-users even know there’s a problem.

“For hosting providers, this creates a major operational issue,” Pascal Geenens, VP of Cyber Threat Intelligence at Radware, told HostingAdvice. “You are running multi-tenant infrastructure with many different applications, software versions, and custom configurations.”

Patching is still critical, Geenens says, but there’s always a chance that something providers push out as a fix can break something in a customer’s setup. “Even if you can deploy a patch or change a default setting quickly, you often cannot push a breaking change without warning your customers first.” And that, friends, takes time.

That need for speedier security is happening in DDoS protection, where a firewall is no longer enough. Radware found that nearly 3 out of every 4 DDoS attacks Radware mitigated in the first half of 2026 involved direct-path UDP floods. Include fragmented UDP attacks and that goes above 80%.

The average customer faced 110 DDoS attacks per day, which is a 36.6% increase from 2025.

The instinctive response is obvious: just block them all! On shared infrastructure, though, that can be a big mistake, Geenens said: “If a provider blocks entire IPs or subnets, they risk causing collateral damage to legitimate customers sharing that infrastructure."

Attackers can also spoof source IP addresses, making malicious traffic look like it came from a legitimate customer or service. Block that IP, and the provider could end up doing the attacker’s job for them: cutting off its own customer.

A year or two ago, it was easier to tell which traffic was automated and which was an actual user. But now, customers are using AI agents to create, build, and do the busywork they used to do themselves. Attackers are putting those same agents to work, too, which means providers need to learn how to spot this very specific kind of malicious behavior.

“As a hosting or infrastructure provider, you can no longer rely on binary human versus bot detection,” Geenens explains. “Defenses must understand the normal baseline of application workflows so they can detect when an entity, human or machine, deviates into abnormal behavior or starts manipulating business logic."

AI coding agents can also make decisions about which software gets pulled into a customer's environment, like what happened with the Mini Shai-Hulud campaign, where compromised packages stole build secrets and CI/CD credentials, helping attackers compromise more packages.

His solution is to put a checkpoint between customer build environments and public package registries, giving providers a chance to screen packages before they make it into a build.

“Hosting providers should manage private artifact registries or caching proxies and route all package manager traffic through them, rather than letting build containers pull directly from public registries like npm or PyPI," Geenens said. "Platforms can automatically quarantine or block packages published within the last 24 to 72 hours, as well as brand-new packages with very low download counts.”

Attackers aren’t waiting for a patch, and customers aren't behaving like humans, either. Keep that in mind, and you can spend less time blocking first and sorting it out later.