DBIR 2026: exploited vulnerabilities become the number one way in
by detektd team
Verizon's Data Breach Investigations Report (DBIR) is the annual reference on how intrusions actually happen. The 2026 edition, published in May, covers incidents between November 1, 2024 and October 31, 2025: more than 22,000 confirmed data breaches across 145 countries. For the first time since the report has tracked this, the most frequent way in is neither phishing nor credential theft: it's the exploitation of a vulnerability.
of analyzed breaches started with the exploitation of a vulnerability, up from 20% a year earlier (Verizon DBIR 2026)
The ranking flips
Exploitation's share grows from 20% to 31% of initial access, a 55% increase in one year. Phishing falls to 16% and credential abuse to 13%. The most exploited targets remain those exposed to the Internet by design: web applications, VPNs and remote access devices. The latter were moved into a separate "network" category, which rose from 1.5% to 5% of breaches.
The rest of the report confirms the trend. Ransomware is present in 48% of breaches (up from 44%), even though 69% of victims refused to pay and the median ransom paid fell to $139,875. And a third party (provider, vendor, host) is involved in 48% of cases, a share up about 60% year over year.
The real problem: how fast fixes land
Verizon cross-referenced its data with that of more than 13,000 organizations, 527 million vulnerability instances (versus 68.7 million in 2022). The finding is clear: among flaws listed in CISA's KEV catalog, meaning those with confirmed active exploitation, only 26% were fully fixed over the period, down from 38% the year before. The median time to fix rises from 32 to 43 days, and seven days after publication, 60 to 70% of those flaws are still open.
The mechanics are well known. As soon as a fix ships, diffing the code before and after is enough to locate the flaw, then attackers sweep the Internet for servers still exposing the old version. The recent React2Shell case shows it: disclosed on December 3, 2025, this React Server Components flaw had a public proof of concept the next day, and entered the KEV catalog on December 5. The report adds a useful detail for prioritizing: the probability of a flaw being re-exploited roughly halves at 30 days, again at 90 days, and again around nine months. The first weeks are therefore decisive.
of actively exploited flaws were fully fixed over the year, down from 38% a year earlier (Verizon DBIR 2026)
What it changes for a web application
A web application combines both factors from the report: it's permanently exposed, and it relies on a stack of third-party components (framework, CMS, libraries, server), each with its own flaw calendar. The first difficulty isn't fixing, but knowing what actually runs in production. A version pinned in a lockfile, a Docker image that wasn't rebuilt or a forgotten staging subdomain is enough to keep a flaw open long after the fix.
# JavaScript: known advisories for the installed tree npm audit --omit=dev # Any ecosystem: OSV database (npm, PyPI, Go, Maven, Composer...) osv-scanner scan source -r . # Which of those are actively exploited? CISA's KEV feed curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \ | jq -r '.vulnerabilities[] | select(.dateAdded >= "2026-09-01") | .cveID + " " + .product'
- Keep an inventory of what's exposed: domains, subdomains, framework and CMS versions actually served.
- Prioritize by real-world exploitation (KEV, EPSS score) rather than CVSS alone: an exploited "medium" flaw comes before a theoretical "critical" one.
- Set a target delay for exploited flaws, on the order of a few days, and automate security updates (Dependabot, Renovate) to meet it.
- Reduce what gives your versions away (X-Powered-By and Server headers, meta generator tag, public build files): it fixes nothing, but takes you off the easy list for mass scans.
What detektd checks
detektd sees your application the way an attacker sees it from the Internet. It identifies the frameworks and CMS being served and their version when visible, compares them with known flaws (including React2Shell and CVEs in Next.js, Angular or WordPress), and spots surfaces that shouldn't be public: admin consoles, dashboards, exposed build or config files. With weekly monitoring, those checks rerun every week, including flaws added between two scans.
TLS certificates: from 398 to 47 days, manual renewal is over
Since March 15, 2026, a public certificate can no longer exceed 200 days. It will be 100 days in 2027 and 47 days in 2029, and Let's Encrypt drops to 45 days as early as 2028. The schedule, the reasons, and what to automate so an expired certificate never takes your site down again.
When a prompt becomes a shell: what Microsoft found in agent frameworks
In May, Microsoft's Defender research team published two critical CVEs in Semantic Kernel where prompt injection could end in code execution on the host machine. The problem isn't confined to one framework.