For eighteen straight years, Verizon's Data Breach Investigations Report told a consistent story: stolen credentials got attackers in the door more often than anything else. This year, that changed.

The 19th edition of the DBIR - built from more than 22,000 confirmed breaches across 145-plus countries, one of the largest datasets the report has ever drawn on - found that exploiting unpatched software has overtaken stolen credentials as the leading way businesses get breached. It's a small shift in ranking with a large implication: the thing most likely to sink an organization this year isn't a careless click. It's an asset nobody was watching.

That's the thread running through this year's report, and it's worth pulling on directly. Below are five findings from the 2026 DBIR that matter most, and what they actually demand from the businesses reading them.

1. Vulnerability exploitation is now the #1 way in - and remediation is losing ground

Exploited vulnerabilities now account for 31% of breaches, enough to displace credential abuse from the top spot for the first time in the report's 19-year history. Verizon attributes much of the shift to AI-assisted attack tooling, which has compressed the time between a vulnerability's public disclosure and its first real-world exploitation from months down to hours.

Defenders, meanwhile, are losing ground on the metric that matters most: how fast they close the gap. The median organization now carries 16 vulnerabilities from CISA's Known Exploited Vulnerabilities catalog at any given time, up from 11 the year before. Of those, only 26% get fully remediated - down sharply from 38% the previous year - and the median time to close one out has stretched from 32 days to 43. Do the arithmetic and the median organization is sitting on roughly a dozen known-exploited vulnerabilities at all times, not as a worst-case scenario, but as the baseline.

None of that is a patching problem in the traditional sense. It's a visibility problem wearing a patching costume. Teams can't prioritize remediation on assets they don't know are internet-facing, and a CVSS score alone doesn't tell you whether a given flaw is actually reachable, actually exploited in the wild, or actually attached to something the business cares about. That's the gap Cyber Oracle's attack surface monitoring is built to close - a continuously updated map of every domain, subdomain, exposed service, and certificate tied to your organization, so "unpatched" stops being a euphemism for "unknown."

2. The credential story is more precise than "phishing" - and more dangerous

It's tempting to lump every identity-related breach into one bucket, but the DBIR's own categorization is more specific, and more useful, than that. Phishing accounts for roughly 16% of breaches as a primary pattern; credential abuse another 13%; pretexting a further 6%. Combined with everything else touching human trust, some measure of the human element shows up in 62% of all breaches.

The part that should concern security leaders more than the raw percentages is what a stolen credential now carries with it. Session cookies and authentication tokens are increasingly harvested alongside passwords, which means multi-factor authentication - long treated as the fix for credential theft - can be sidestepped entirely if an attacker hijacks a live session instead of logging in fresh. A password rarely travels alone anymore.

Most organizations can tell you whether MFA is enabled. Far fewer can tell you which identities hold standing access they no longer need, which service accounts have never been reviewed, or where a compromised session would actually lead once inside. That's the question Cyber Oracle's identity and privilege graph is built to answer - mapping not just who can authenticate, but what each identity can actually reach.

3. The human element didn't go away. It went to your phone.

Security awareness training has spent a decade optimizing for one channel: email. Attackers have noticed, and moved. As employees have gotten sharper at spotting a phishing email, voice calls and text messages have picked up the slack - vishing and SMS-based social engineering now succeed at a rate roughly 40% higher than traditional email lures, according to Verizon's own analysis.

Pretexting - building a convincing scenario over the phone rather than through a link - has become a favored technique among some of the most disciplined attack groups tracked in this year's report, precisely because it's harder to filter and easier to trust. A voice on the phone doesn't get caught by a spam folder.

This is the one weakness on this list that isn't primarily a tooling problem, and it's why Cyber Oracle Academy exists as more than a compliance checkbox: hands-on labs built around real attack patterns - including voice and SMS-based pretexting - rather than another slideshow about suspicious email links.

4. Third parties are now involved in almost half of all breaches

Third-party involvement - a vendor, contractor, or integration whose weak security becomes your incident - jumped 60% year-over-year and now shows up in roughly 48% of all breaches the DBIR analyzed. For smaller and mid-sized businesses, the number is worse: third parties are implicated in over half of SMB breaches specifically.

The uncomfortable part is how slowly this category gets fixed once it's found. Weak passwords and misconfigured permissions inside vendor environments can take the better part of a year to resolve, largely because the organization that's exposed doesn't control the fix. Most businesses can name their biggest vendors. Far fewer maintain a living inventory of every third-party connection, OAuth grant, and integration with standing access to their systems.

This is, at its core, the same visibility problem as vulnerability management, just extended past your own perimeter: you're only ever as exposed as the assets and connections you've mapped, and third parties are assets too.

5. Shadow AI is the newest weakness, and the fastest-growing

The DBIR's authors have called this the quietest finding in the report and the most consequential one. Regular employee use of generative AI tools at work has roughly tripled in a single year, from about 15% to 45%. Source code, internal documents, and customer records are being pasted into tools that sit entirely outside the organization's security stack, on personal accounts nobody in IT approved or can see.

This isn't a future risk. It's a present one that most security programs have no instrumentation for at all - there's no firewall rule for "an employee pasted a customer record into a chatbot," and no awareness training built five years ago anticipated it.

Discovering shadow IT and shadow AI usage before it becomes a breach footnote is exactly what Cyber Oracle's shadow discovery engine is built to do: surface the unsanctioned tools, unmanaged accounts, and unofficial data flows that never show up in an asset inventory because nobody registered them in the first place.

The common thread

Read all five findings together and the pattern isn't subtle. It's rarely a total absence of controls that turns into a breach. It's something the organization didn't know it had: an internet-facing server nobody flagged, a vendor account nobody reviewed, a chatbot extension nobody approved. Firewalls, endpoint tools, and training all still matter, but every one of them only defends what it can see.

That's the premise Cyber Oracle is built on. Attack surface monitoring, identity and privilege mapping, hands-on security training, and shadow discovery aren't five separate products bolted together - they're five answers to the same question, the one every security program should be asking continuously: what do we actually have, who can reach it, and what is it doing right now?

Sources are drawn from Verizon's 2026 Data Breach Investigations Report (19th edition) and supporting research from contributing partners including Tenable, Qualys, and Veracode.

Originally published at https://www.cyoracle.com.

I wasn't at a client site. I wasn't in a meeting. I was sitting at my desk — same desk, same dual monitors I've stared at for more hours than I can count — running a red team simulation against our own platform. Just me, a terminal, and a fresh build of something I'd spent weeks writing.

The scanner ran clean. Every CVE it was supposed to flag, it flagged. Severity scores rendered exactly as designed. The dashboard lit up the way dashboards are supposed to light up when they're working correctly. By every internal metric I'd defined, the system had done its job.

Then I did something a bit stupid, or maybe the most useful thing I'd done in months: I pretended to be the attacker.

Not a theoretical attacker. Not the attacker described in the OWASP documentation or the NIST framework or any of the literature I'd absorbed building this thing. I pretended to be the specific, actual kind of person who would want to get into the kind of organization we were trying to protect — someone who had studied the target, knew its industry, understood what was valuable inside it, and had time.

The path I found into the simulated environment had not triggered a single alert. The vulnerability it passed through had a CVSS score of 4.3 — medium severity, not even in the top fifty findings the scanner had surfaced. On its own, in isolation, scored against a generic rubric, it was unremarkable. In the context of this specific architecture, sitting next to two other unremarkable findings, it was the door.

I stared at that for a long time. Not because I was surprised that the scanner had missed it — I understood the technical reason it had. I was staring because I had written that scanner. I had designed its logic. I had decided what it prioritized and why. And standing on the other side of it, thinking like someone who wanted in rather than someone who wanted to protect, I could see, very clearly, exactly what I had built wrong.

Not the code. The thinking behind the code.

The Assumption Baked Into Everything

Every line of security software I've ever written — and at this point there's quite a lot of it — starts from a set of assumptions about what security is. What matters. What counts as a threat. What a defender needs to know.

Most of those assumptions, I absorbed from the industry. Severity scoring from CVSS. Threat taxonomies from MITRE. Priority frameworks from the major vendors, the compliance bodies, the certification curricula. I didn't question them because they were the foundation. You don't question the foundation while you're trying to build the house.

But that night, sitting with a terminal and a finding with a CVSS score of 4.3 that I had just used to walk through a simulated enterprise like the door was unlocked, I had to confront something uncomfortable: the foundation had been poured for the wrong building.

The industry's scoring systems are designed to evaluate vulnerabilities in the abstract. How severe is this flaw in principle? How exploitable is this weakness in isolation? Those are genuinely useful questions for researchers, for vendors patching their software, for people thinking about the general landscape of risk.

They are almost completely disconnected from the question that matters to the person responsible for a specific network, a specific set of assets, a specific threat model, on a specific morning with a specific team of three people who can actually act on what they're told.

That person doesn't need to know that CVE-2024-XXXX is generically severe. They need to know whether it is, in their environment, today, reachable by someone who would want to reach it. That's a different calculation. It requires context their scanner doesn't have, inference their scoring model wasn't built to make, and judgment that no amount of data volume substitutes for.

I had built a very sophisticated version of the standard answer. What I needed to build was something that could actually think.

Why Attacking Your Own Code Is the Most Honest Thing You Can Do

I've learned more about what to build by trying to break what I've already built than by anything else.

There's a particular discipline in offensive security — the red team mindset, the attacker's perspective — that changes how you write code once you really absorb it. You stop thinking about what your system does and start thinking about what someone else would do with what your system doesn't do. The gaps. The seams. The places where your implementation of the intent diverges from the intent itself.

That gap — between what you meant to build and what you actually built — is where real attacks live. Not in the theoretical vulnerabilities with high CVSS scores that everyone is watching. In the space between your assumptions and reality.

A kid from Agege, a suburb of Lagos, demonstrated this more clearly than any textbook I've read. He found a path through the correspondence banking network that had a perfectly adequate score by every risk metric the affected institutions were using. The controls were implemented correctly. The monitoring was live. The logic was sound — for the attack everyone was looking for. He ran a different attack. The seam was right there.

I think about that case often when I'm writing code. Not because I want to replicate what he did, but because it's a precise illustration of a failure mode that I see everywhere and that I was reproducing in my own product: we are very good at defending against the attacks we have already imagined. We are much worse at defending against the attacks the adversary is currently running.

The only reliable way I've found to close that gap is to constantly shift perspectives. Write the code. Then try to break it like someone who doesn't care how much work you put into it.

Building the Academy Was My Admission That Code Isn't Enough

When we built the academy into Cyber Oracle, the honest reason — the one I didn't put in the pitch deck — was that I had watched smart people misuse good tools for long enough to understand that the problem wasn't entirely the tools.

I've sent security reports to technical teams that didn't result in action. Not because they were wrong reports, and not because the teams were incompetent. Because the framework for understanding what the report meant, and why it should change behavior, wasn't there. A finding is not self-explanatory. An alert is not a decision. Surfacing something true is not the same as helping someone understand what to do about it.

The academy is an attempt to close that gap from the education side while the intelligence platform closes it from the technology side. If someone understands how an attacker reasons — not just the mechanics of the attack but the logic of it, the target selection, the path-finding — they interpret a finding differently. They ask better questions. They make better calls about what to act on first.

That's not something you get from a CVSS score. It's something you build over time, through deliberate exposure to the attacker's perspective, until you can hold both frames simultaneously: defender and attacker, simultaneously, on the same environment.

Getting practitioners to that point is, in my honest assessment, more valuable than any additional feature I could add to the scanner. But it takes longer and it's harder to put in a product demo, so most companies don't try.

The Loneliness of Building Something the Market Didn't Ask For

I want to be direct about something that doesn't come up enough in founder writing: building for a need the customer doesn't yet know they have is genuinely difficult, and not in the way that's usually described.

It's not difficult because you lack conviction. I've had conviction about this since that midnight red team session. It's difficult because the customer has a vocabulary for what they think they need, and that vocabulary was taught to them by the industry that currently serves them. They ask for more alerts, better dashboards, faster scans, broader coverage — because those are the categories that exist. They don't ask for better thinking because nobody has sold them better thinking yet.

When you show them something that operates differently, that surfaces less but means more, that says "these three things matter and everything else can wait," the instinctive response is often discomfort. Did something get missed? Is the coverage actually comprehensive? The noise they've been drowning in was at least familiar.

Earning trust for a different kind of signal takes longer than demonstrating a better version of the existing signal. I think it's worth it. But I want to be honest that it's the hard part — harder than any of the engineering, harder than scaling, harder than hiring.

What I Know Now That I Didn't Know When I Started Writing This Code

The night I broke my own scanner, the lesson I took at first was narrow: I need to build better contextual scoring. Correlation across findings. Environmental weighting. More sophistication in the prioritization layer.

Those were all correct conclusions. We built all of those things. The product is substantially better for them.

But the deeper lesson took longer to land, and I'm not sure I can claim I've fully integrated it even now: the goal is not to build a better scanner. The goal is to build something that can help a person understand their actual risk. Those are related but they are not the same objective, and every design decision reveals which one you're actually optimizing for.

A better scanner surfaces more things more accurately. Something that helps a person understand their risk surfaces fewer things more meaningfully, with the context that makes them actionable, in the order that matches their specific situation. The second thing is harder to build. It requires opinions. It requires being willing to say "this doesn't matter for you right now" when the commercially safe move is to show everything and let the customer worry about all of it.

It also requires, at some point, being willing to point the attacker's perspective at your own product and ask what it's missing.

I try to do that regularly. It's still uncomfortable, every time.

That discomfort is the most honest signal I have that I'm still asking the right question.

Benjamin Sylvester is the Lead Developer and Founder of Cyber Oracle, an autonomous security intelligence platform. He builds in Lagos.