In August 2026 SAP released Security Note 3714806 for CVE-2026-34265. It fixes an SAP DIAG memory corruption vulnerability in SAP NetWeaver Application Server ABAP. The bug sits in the code that parses the protocol of SAP GUI, and it carries a CVSS score of 9.8. We have reversed the patch to understand what SAP changed. Customers have now had three months to patch, so we can share what this vulnerability means for SAP landscapes and how you can protect your systems.
Why DIAG matters
DIAG is the protocol that SAP GUI uses to talk to the ABAP application server. Every dialog work process listens for it on the dispatcher port, normally 32NN, where NN is the instance number. In most companies the whole internal network can reach this port, because every SAP GUI user needs it. Some organisations also open it to partners, to remote offices through SAProuter, or by mistake to the internet.
The important detail is timing. The application server reads DIAG data from a client before that client logs on, because DIAG also carries the logon screen. As a result, anyone who can open a TCP connection to the dispatcher port can reach a parsing flaw in that early stage, and SAP DIAG memory corruption in particular. The attacker needs no user account, no password and no prior foothold in the system.
What the patch fixes
We compared the DIAG parser in a vulnerable and a fixed SAP kernel. In several places the old parser did not check length and count fields from the client against the real size of the data and the buffers they describe. SAP calls the root cause improper validation of boundary conditions, and that is an accurate summary. A crafted DIAG message, sent before logon, can make the kernel read or write memory outside the intended buffer inside a work process.
In our lab on an unpatched kernel this led to work process crashes. Depending on the code path, it also leaked memory content that belonged to the server rather than to the attacker. SAP rates the impact as high for confidentiality, integrity and availability. The note also lists memory corruption, buffer overflow and remote code execution among its terms. In practice an unauthenticated attacker on the network could at minimum disrupt the system and could potentially go much further.
Inside the bug class
Binary protocols like DIAG describe their own structure. A message is a stream of items. Each item carries a type, a length and often a count of the elements inside it. The server uses these numbers to decide how much to read and where to store it. The client controls every one of those numbers. So the server has to check each of them against the real amount of data and the real size of the target buffer.
Signed counts and unchecked offsets
The flaws behind this SAP DIAG memory corruption follow one pattern. A 16 bit count field arrives in big endian order. The parser swaps the bytes and then loads the value as a signed number. For normal input this makes no difference. A value with the top bit set, however, silently turns negative. A value that is simply too large stays positive, but the code never reduces it to the real table size.
The server does compare the count against a limit. That check only controls how many times a loop runs, though. The code then calculates the memory offset from the original, unchecked value. The client therefore chooses where the write or read lands relative to the buffer. At the same time the loop looks perfectly bounded to anyone who reads the code.
count = (int16_t) be16(field);
limit = min(count, table_len);
for (i = 0; i < limit; i++)
table[i - count] = value;
The snippet above illustrates the pattern in a simplified form and is not SAP code. The bound on the loop is correct, but the index is not. A related problem affects 32 bit length fields. A length with the highest bit set turns negative after sign extension. It then passes a comparison that should keep the parser inside the message. Developers make both mistakes easily and reviewers rarely spot them. Fuzzing alone also struggles to find them, because DIAG is a very stateful protocol.
How we reversed the patch
SAP ships the kernel with symbols, which makes it a good target for patch comparison. We extracted disp+work from a vulnerable kernel and from a fixed one. Then we built a fingerprint of every DIAG related function from its instructions, calls, comparisons and memory writes. A plain diff between releases a year apart is noisy, because SAP refactors large parts of the dynpro and DIAG code over time.
The useful signal was a new group of functions that trace DIAG traffic before authentication. Next to them we saw a new length check in the inbound message handler. From there we reversed the parser path by hand. We followed each item type from the main dispatcher down to the handlers that copy client data into internal tables, and we checked every length and count field on the way.
Technical walkthrough
%hided%Detecting exploitation attempts
Attempts to exploit SAP DIAG memory corruption leave traces even when they fail. A malformed item usually ends the dialog step with an error such as invalid gui data in the work process trace. A successful corruption typically leaves a signal entry and a crash dump in the dev_w file. The dispatcher then restarts the work process. Many such entries in a short time, from connections that never complete a logon, strongly suggest probing.
On the network side, look for clients that open a DIAG connection to port 32NN and send unusual or very large items before any logon data. Also watch for clients that reconnect again and again from the same address. SAP GUI clients in your company behave in a very regular way, so these sessions stand out once you look for them.
Affected systems and the fix
The vulnerability sits in the SAP kernel. It therefore affects ABAP based systems regardless of the business application on top, including SAP ECC, SAP S/4HANA and other NetWeaver ABAP products. SAP delivers the correction as a kernel patch. You can install it as a hotfix (DW.SAR) or as part of an SP Stack Kernel (SAPEXE.SAR and SAPEXEDB.SAR). For kernel 9.16 the fix starts with patch level 89. The note lists the patch levels for other kernel releases in its Support Package Patches section. SAP states that there is no workaround.
There is one more thing to consider. In November 2026 SAP released Security Note 3792915 (CVE-2026-76970), another memory corruption issue in the AS ABAP kernel. SAP grouped it with 3714806 under the same FAQ note 3746868. Our advice is therefore not to stop at the patch level from the August note. Install the latest available kernel patch level, which contains both corrections. Read FAQ note 3746868 before you plan the update.
What to do now
First, check the kernel patch level of every ABAP instance in your landscape. Include sandboxes and rarely used systems, because attackers look for the forgotten ones. Transaction SM51 or the command disp+work -V shows the current level. Compare it with the patch levels in notes 3714806 and 3792915, and plan the kernel update with high priority.
Until you finish the update, limit who can reach the dispatcher port. SAP GUI users need it, but servers, printers, guest networks and the internet usually do not. Use network segmentation and allow port 32NN only from user networks and jump hosts. Keep SAProuter route permission tables as narrow as possible. These measures do not fix the bug, but they shrink the attack surface considerably.
Advisory details
| SAP Security Note | 3714806 |
| CVE | CVE-2026-34265 |
| CVSS v3.1 | 9.8 (Critical) |
| Component | SAP Kernel, SAP NetWeaver AS ABAP, DIAG protocol |
| Attack vector | Network, no authentication, no user interaction |
| Released | SAP Security Patch Day, 11 August 2026 |
| Related notes | 3746868 (FAQ), 3792915 (CVE-2026-76970, November 2026) |
Source: SAP Security Note 3714806 and FAQ note 3746868. See also our overview of the SAP Security Patch Day August 2026.
