The flood wave is here: how AI is changing SAP vulnerability research, and your patch backlog

November Patch Day in numbers

SAP’s November Patch Day brings 47 security notes: 39 new ones and 8 in between updates or updates to earlier notes. The average over the previous 12 months was 19.

The previous record was 30 notes, in July 2025. The 12-month average fell below 12 in mid-2024 and has climbed since, to almost 21 today. November is the sharpest step in a rise that was already under way.

Three things stand out beyond the total.

• Severity is up, not only volume. 29 of the 47 notes are High or HotNews.
• The kernel carries most of it. 20+ notes need a kernel-level fix, covering the Web Dispatcher, ICM, Gateway, Message Server, RFC layer, Host Agent and IGS. Nine more are ABAP corrections, eight are Java, two are BusinessObjects and one is a cloud service.
• Nearly all of it came from outside SAP. At least 35 of the 47 notes address externally reported issues. The research community is driving this month’s volume.

What changed in our own research

A patched vulnerability is rarely alone. The same coding mistake usually exists elsewhere in the codebase, written by another team or copied years ago. Finding those siblings is called variant analysis, and it has always been limited by human reading time. SAP’s ABAP codebase runs to hundreds of millions of lines.

We removed that limit. Our team built an indexer that makes large ABAP codebases searchable by structure and meaning, and connected it to a large language model. Starting from a known, already patched vulnerability, the pipeline searches for code with the same flaw. A researcher then validates each candidate by hand before anything goes to SAP.

The result was more than 40 confirmed findings in a single month. Before, we reported one to three a month, so that is roughly 20 times our normal output. The AI did not replace the researcher. It took over the reading, and left the judgment, the validation and the reporting to people who have done this for over a decade.

Why we expect the volume to stay high

Nothing in our approach is exclusive to us. The models are commercially available, and every published security note is a starting point for a new search. If a team of our size can do this, so can other research groups, SAP’s own product security teams, and attackers.

That last group matters most. The same technique that finds a variant for responsible disclosure finds one for exploitation. It also shortens the path from a published patch to a working exploit, because comparing old and new code is exactly the kind of reading these models do well. The window between Patch Day and the first exploitation attempt will keep getting shorter.

Today’s release points the same way. Twenty of the 47 notes fix the kernel, many of them memory corruption in network-facing components. Our own pipeline targets ABAP, but we expect most of these were found with similar AI-assisted techniques.

One month does not make a trend, and we cannot attribute all of today’s 40 notes to AI with certainty. But we know what is still in the queue. SAP is working on the more than 40 vulnerabilities we reported, and we expect the first of those fixes from December.

SAP’s public researcher acknowledgements show we are not alone. From January to June 2026, SAP credited between 5 and 11 reporting parties a month. From July to November it credited between 12 and 18. October alone brought 12 parties that had not been credited earlier this year. The October and November lists also include XBOW, a company that builds autonomous AI security testing.

The rise did not start today. SAP’s monthly average has climbed since 2025, and we believe early AI-assisted research played a part. The models of 2025 were limited. Those of 2026 read code far better, and that is when our own output jumped.

Other vendors are already further along. Microsoft’s July 2026 Patch Tuesday addressed 570 flaws, almost three times its June count, and Google shipped 1,442 security fixes across three Chrome releases, according to the Cloud Security Alliance. FIRST expects about 66,000 CVEs in 2026 and attributes most of the rise to AI tools (Help Net Security).

We therefore expect a structural uptick in the number of SAP security notes, not a return to 15 to 20 a month.

What this means for patch management

Most SAP patch processes were sized for 15 to 20 notes a month. Double the input with the same team and the backlog grows every month, with the highest-risk notes sitting in the same queue as the trivial ones.

The mix makes it harder. A kernel patch means a restart and a maintenance window, and today’s release has 20 of them. They can be bundled into one kernel update per system, but that update now has to be scheduled within days, not held for the next quarterly window.

Three assumptions stop holding:

• “We review every note manually.” At 40 notes across a landscape of dozens of systems, relevance assessment alone takes days. It has to be automated per system.
• “We patch quarterly.” At this month’s rate, a quarter means over 100 open notes, including a double-digit number of HotNews.
• “CVSS decides the order.” With eleven notes above 9.0 in one month, the score no longer separates them. Exposure, exploitability and what the system runs have to.

What to do now

1. Measure your current patch lead time. Know how many days pass between Patch Day and production for a HotNews note. Most teams have never measured it.
2. Automate relevance. For each note, each system needs an answer: affected or not, already implemented or not. Nobody should work that out in a spreadsheet.
3. Prioritise by risk, not by list order. Internet-facing components such as the Web Dispatcher, ICM and Gateway, and anything exploitable without authentication, come first.
4. Agree a fast lane for kernel updates. Settle the approval path and the test scope now, before the next 10.0 arrives.
5. Monitor what you cannot patch yet. Detection and compensating controls cover the gap between release and implementation.

This is where SecurityBridge supports customers. Patch Management shows which notes apply to which system and tracks implementation. Where a vulnerability can be detected, our Research Lab adds detection signatures to Threat Detection, so customers have visibility while the patch is still in the queue.

A note on disclosure

All our findings were reported to SAP under responsible disclosure. We do not publish technical details until at least three months after SAP releases the corresponding patch, so customers have time to implement it. That is why this post contains numbers and no specifics. Details will follow once it is safe to share them.

More patches are, in the end, good news: each one is a weakness closed before someone used it. The work is making sure they get implemented at the speed they now arrive.