SAP WebSocket Vulnerability: Snort Rules and Firewall Steps Before You Patch

The SAP WebSocket vulnerability that SAP fixed on 10 November 2026 is about as serious as SAP security gets. It scores CVSS 10.0 and needs no login. It also sits in the ICM and the SAP Web Dispatcher, which handle every HTTP request your SAP systems receive.

The fix is a kernel update, and that is where the trouble starts. After all, kernel updates mean restarts, regression tests and a change window. As a result, in many companies that adds up to weeks. So this guide is for that gap. It gives your security team tested Snort rules to spot attacks, and it shows what your network, proxy and SAP Basis teams can block this week.

Why the SAP WebSocket vulnerability matters to the business

The SAP FAQ note 3778788 (version 7, 12 November 2026) rules out most of the usual reasons to wait. Many teams assume they are safe because they do not use WebSocket. However, WebSocket support is on by default, so every system stays open until you switch it off or patch. Older kernels are not safer either, since every release from 7.40 on is affected, including those out of maintenance. A login page does not help, because some WebSocket services are open and on others the bug triggers before authentication. HTTPS gives no cover as well, because both HTTP and HTTPS are affected.

Above all, the Web Dispatcher is the biggest concern. It usually sits in the DMZ and is the first SAP component that internet traffic reaches. If an attacker takes it over, they have a foothold in front of S/4HANA, Fiori and your portals. Similarly, on an application server, a compromised ICM puts business data within reach.

Map your exposure first

Start with three questions about your exposure to the SAP WebSocket vulnerability. First, where are all your ICMs and Web Dispatchers? The small Web Dispatchers in front of HANA or third-party systems are the ones that get missed, since they often have no clear owner. The same goes for HANA XS instances.

Second, which ICM ports can people reach directly? Check it with a scan from user networks and from the internet, because diagrams are often out of date. For instance, ICM ports are usually 80NN and 443NN, where NN is the instance number.

Third, do you actually use WebSocket? Look for status code 101 in the HTTP log of each ICM and Web Dispatcher, as SAP recommends. Release 7.73 and later write this log by default. However, older releases and HANA XS need it switched on first. If there are no 101 entries, you can turn WebSocket off without breaking anything. Otherwise, the log shows exactly which URLs use it.

Detect attacks with Snort rules

Snort has no WebSocket parser, so standard rule sets will not see attacks on the SAP WebSocket vulnerability. That is why we wrote the rules below for SAP ICM and Web Dispatcher traffic. We then tested them on Snort 2.9.20 against crafted attack traffic and about 160 MB of normal WebSocket sessions.

First, the rules follow each connection from the upgrade request to the 101 response. After that, they look at the frames the client sends. Rule 1778522 fires on a close, ping or pong frame sent in fragments, and rule 1778523 on a control frame longer than 125 bytes. RFC 6455 forbids both, so normal clients never send them. Finally, rule 1778524 fires when one source sends several control frames of 63 to 125 bytes. That is legal on its own, but rare in real traffic, where keepalive pings are only a few bytes.

Deploying the Snort rules

Snort has to see decrypted traffic. So place the sensor behind the point where TLS ends, for example between your load balancer and the Web Dispatcher. Alternatively, use the hop between the Web Dispatcher and the ICM, if it runs plain HTTP. On encrypted links, by contrast, these rules see nothing.

Next, add your SAP web servers and ports to snort.conf:

ipvar SAP_WEB_SERVERS [10.20.0.0/16]
portvar SAP_WEB_PORTS [80,443,8000:8099,44300:44399]

Then load the rules. The SIDs are in the local range, so change them if they clash with your own. For Snort 3, convert the rules with snort2lua.

alert tcp any any -> $SAP_WEB_SERVERS $SAP_WEB_PORTS (msg:"SAP WebSocket upgrade request"; flow:established,to_server; pcre:"/^Upgrade:\s*websocket/smi"; flowbits:set,sap.ws.req; flowbits:noalert; sid:1778520; rev:1;)
alert tcp $SAP_WEB_SERVERS $SAP_WEB_PORTS -> any any (msg:"SAP WebSocket 101 Switching Protocols"; flow:established,to_client; flowbits:isset,sap.ws.req; content:"101 Switching Protocols"; pcre:"/^HTTP\/1\.1 101/"; flowbits:set,sap.ws.open; flowbits:noalert; sid:1778521; rev:1;)

alert tcp any any -> $SAP_WEB_SERVERS $SAP_WEB_PORTS (msg:"SAP WebSocket fragmented control frame (CVE-2026-76964, CVE-2026-89126)"; flow:established,to_server,no_stream; flowbits:isset,sap.ws.open; pcre:"/^[\x08-\x0a][\x80-\xfd]/"; byte_jump:1,1,bitmask 0x7f,post_offset 4; isdataat:!1,relative; classtype:attempted-admin; sid:1778522; rev:1;)

alert tcp any any -> $SAP_WEB_SERVERS $SAP_WEB_PORTS (msg:"SAP WebSocket oversized control frame (CVE-2026-76964, CVE-2026-89126)"; flow:established,to_server,no_stream; flowbits:isset,sap.ws.open; pcre:"/^[\x88-\x8a]\xfe/"; byte_jump:2,2,post_offset 4; isdataat:!1,relative; classtype:attempted-admin; sid:1778523; rev:1;)

alert tcp any any -> $SAP_WEB_SERVERS $SAP_WEB_PORTS (msg:"SAP WebSocket repeated large control frames (CVE-2026-76964, CVE-2026-89126)"; flow:established,to_server,no_stream; flowbits:isset,sap.ws.open; pcre:"/^[\x88-\x8a][\xbf-\xfd]/"; byte_jump:1,1,bitmask 0x7f,post_offset 4; isdataat:!1,relative; detection_filter:track by_src,count 1,seconds 300; classtype:attempted-admin; sid:1778524; rev:1;)

Test results and limits

In our tests, all three attack patterns raised alerts. Meanwhile, the normal traffic produced one false positive in about 160 MB, from rule 1778522. So start in alert mode and watch the results for a week. If you run Snort inline, you can then switch 1778522 and 1778523 to drop.

However, there is one limit to keep in mind. Snort checks frames at the start of each TCP segment, and an attacker who packs several frames into one segment can slip past. That is why these rules work best as an early warning next to the blocking steps below.

It also pays to watch the SAP side. New status 101 entries in the HTTP logs deserve an alert, especially from external addresses or on URLs that never used WebSocket before. In addition, failed memory corruption attempts often crash the process. So alert on unexpected ICM or Web Dispatcher restarts and on new crash entries in dev_icm or dev_webdisp.

Close the side doors to the ICM

According to SAP, an up-to-date Web Dispatcher shields the systems behind it. But that only works if nobody can go around it. So the firewall should let only your Web Dispatcher hosts and admin jump hosts reach ICM HTTP and HTTPS ports, and block everyone else, user networks included.

At the same time, move the Web Dispatcher to 7.53 PL 1629, 7.54 PL 723, 7.93 PL 430, 9.16 PL 200 or later. These levels include extra corrections for this workaround, so they are not the same as the levels in Note 3778530. Note that the workaround does not apply if the Web Dispatcher runs with PROT=ROUTER in icm/server_port_<x>.

Patching one Web Dispatcher is, in fact, a much smaller job than patching every ABAP kernel behind it. That is why it comes early: it protects the backends while the kernel rollout runs. We would also keep the firewall rule after patching, since it limits the damage from future ICM bugs too.

Turn SAP WebSocket off where nobody uses it

If your logs show no status 101, the simplest protection is to switch WebSocket off. There are two ways to do it, and they work well together.

In SAP. Set the parameter below and restart the component. In AS ABAP, use the default or instance profile. HANA XS Classic needs it in webdispatcher.ini, in the profile section. On XS Advanced, it goes into sapwebdisp.template. Either way, it covers HTTP and HTTPS.

icm/HTTP/support_websocket_upgrade = FALSE

At the edge. If a reverse proxy, load balancer or WAF terminates TLS in front of SAP, it can reject WebSocket upgrade requests. Unlike the SAP parameter, this needs no restart and takes effect right away. We tested the nginx and HAProxy examples below. Each one answers a WebSocket handshake with 403 and lets normal traffic through.

In nginx, add this to the server block that proxies to SAP:

if ($http_upgrade ~* "websocket") {
    return 403;
}

In HAProxy, add this line to the frontend that receives SAP traffic:

http-request deny deny_status 403 if { req.hdr(upgrade) -m sub -i websocket }

Keep in mind, though, that an edge rule only covers traffic that goes through that device. So pair it with the firewall rule above. Otherwise, someone can simply go around the proxy.

Limit SAP WebSocket access where the business needs it

SAP warns that turning WebSocket off breaks some interactive and integration scenarios, SAP GUI for HTML among them. If your logs show status 101, do not switch it off blindly. Instead, allow it only for the URL paths you found in the logs, and only from the networks that use those apps. Unless there is a clear business case, keep WebSocket closed to the internet. For example, in HAProxy you would replace the path and network below with your own:

acl ws_upgrade req.hdr(upgrade) -m sub -i websocket
acl ws_path    path_beg /sap/bc/apc/
acl ws_source  src 10.0.0.0/8
http-request deny deny_status 403 if ws_upgrade !ws_path
http-request deny deny_status 403 if ws_upgrade !ws_source

Of course, this will not remove the SAP WebSocket vulnerability. The allowed paths stay open, and SAP says some services can be attacked before login. Still, it shrinks your exposure from anyone on the internet to a short, known list of users and URLs.

Plan the fix in the right order

Only a patch closes the SAP WebSocket vulnerability for good. Start with the Web Dispatchers that face the internet, including exposed HANA XS instances. Then move to any ICM that people can still reach directly, and finish with the rest. In each case, install the latest patch level of your kernel line rather than the minimum in the note. Also make sure nobody downgrades a Web Dispatcher you already patched.

Kernels that are out of maintenance (7.40 to 7.49 and 7.73 to 7.89) need a move to a supported downward-compatible kernel. Meanwhile, it makes sense to bundle this with the other November kernel notes, so each system restarts only once. When the rollout is done, check the patch level of every instance, for example in transaction SM51. Then remove the temporary WebSocket blocks where the business needs them, but keep the firewall rule and the Snort rules.

What to do about this risk this week

Everything above the last row fits into this week and removes most of the risk. The patch is still the only permanent fix, though. So plan it now, even if the change window is weeks away.

How RedRays can help

The RedRays Security Platform shows which SAP systems are missing security notes and where settings put you at risk. Our team can also review your exposure to the SAP WebSocket vulnerability, tune the Snort rules for your traffic and help roll out the steps above. Contact us to book a short exposure review.

Sources: SAP Security Notes 3778530 and 3778556, and FAQ note 3778788 (SAP for Me, sign-in needed). This guide is based on FAQ version 7 from 12 November 2026. Since SAP sometimes updates its notes, check the current versions before you plan.

Related: SAP Note 3778556: Web Dispatcher WebSocket Memory Corruption, SAP Note 3778530: ICM WebSocket Memory Corruption and the SAP Security Patch Day November 2026 overview.