On November 10, 2026, SAP fixed four critical vulnerabilities, all rated CVSS 10.0 and all exploitable without a login. They sit in the ICM, the Web Dispatcher, the SAP Gateway and the SAML2 service provider, the components closest to the network. None had been reported as exploited at publication.I wouldn’t expect that to hold for long. In August, attackers started going after a critical SAP Commerce Cloud flaw three days after the fix shipped, before anyone had published an exploit for it. RISE with SAP customers have an extra wrinkle, because SAP’s maintenance schedule determines when these fixes reach their landscape. Until they do, the thing you can actually manage is how exposed those systems are, and that’s what the rest of this post covers. What SAP fixed in November 2026All four critical findings hit the parts of SAP that face the network: the HTTP stack, the reverse proxy in front of it, the gateway that application servers use to talk to each other, and single sign-on.ComponentCVEWhat goes wrongWorkaroundICM (NetWeaver AS ABAP)CVE-2026-76964Malformed WebSocket frames corrupt heap memory before login; possible code executionReach ICM only through a patched Web Dispatcher, and keep ICM ports unreachableSAP Web DispatcherCVE-2026-89126Same root cause in the reverse proxy, including embedded and HANA XS dispatchersDisable WebSocket support, which breaks ABAP Push Channels and some Fiori featuresSAP GatewayCVE-2026-89103With no explicit secinfo/reginfo rules, the gateway trusts the attacker as one of its own app serversNone in the noteSAML2 service provider (AS ABAP)CVE-2026-120017Some configurations skip the signature check on incoming assertions, so anyone can log in as any userNone; patch onlyOf the four, the gateway flaw says the most about where SAP risk comes from. The gateway decides trust based on network position, so traffic that looks like it came from inside the landscape gets treated as a peer. Zero trust architectures are built to get rid of exactly that assumption, and it’s the thread running through everything below. How fast do attackers exploit SAP vulnerabilities?Critical SAP flaws are now getting weaponized within days of a patch, and occasionally before one exists. The table below covers the last eighteen months.WhenFlawPatch to exploitationAug 2026Commerce Cloud RCE (CVE-2026-58231, CVSS 10.0)3 days; attempts hit honeypots Aug 14 with no public PoCApr 2026SAP CAP and MTA npm packages (Mini Shai-Hulud)Not a vulnerability: four packages trojaned through a hijacked release pipeline, live for 2 to 4 hoursSep 2025S/4HANA ABAP code injection (CVE-2025-42957, CVSS 9.9)About 24 days; patched Aug 11, exploitation confirmed Sep 4Mar to Apr 2025NetWeaver Visual Composer (CVE-2025-31324, CVSS 10.0)Negative; exploited in the wild before SAP’s Apr 24 emergency patchThe broader industry data points the same way. Mandiant’s M-Trends 2026 puts the average time to exploit at an estimated minus 7 days, which means exploitation routinely starts before a fix ships.AI is shortening what’s left of that timeline. In June, Anthropic showed a model turning freshly published patches into working exploits within an hour, at roughly $2,000 per Windows privilege-escalation exploit. A month earlier, Google’s threat intelligence group reported the first zero-day it believes attackers built with AI help, which had been prepared for a mass exploitation campaign.Two caveats are worth stating plainly. VulnCheck’s data shows exploitation in 2026 is fast but holding steady rather than accelerating, and nobody has documented an AI-built exploit against SAP yet. What has changed is the cost of reading an SAP patch and working backward to an exploit. That cost keeps falling, and patch windows were already too slow before it started. RISE with SAP: who patches, and what you still controlSAP’s Roles and Responsibilities documents for RISE are the contract-level reference for who does what, and they split patching more finely than most customers assume. Kernel patches and Basis security notes are standard SAP services, so fixes like this month’s ICM and Web Dispatcher notes land on SAP’s maintenance schedule rather than yours. Application-level security notes are a packaged service bought separately, and testing implemented notes stays with the customer either way.The same document makes exposure largely your decision. SAP will provide an external IP and configure a web application firewall for internet-facing scenarios when you ask for them. Whether the Web Dispatcher should face the internet at all is yours to decide, along with which users, partners and networks can reach the gateway and the SAML endpoint, and how application identity and authorization are configured.For a RISE customer, then, the most useful question this week is what an attacker could reach while the fix is still in flight. Patch speed is largely out of your hands. What SAP teams should check this weekYou can answer all five of these with tools you already have. I’d get your SAP Basis and security teams in a room for an hour this week and work through them together, since each team usually holds half of the answer.Is any Web Dispatcher or ICM port reachable from the internet? Scan from outside your network, not from your asset inventory. If one is, it’s exposed to CVE-2026-89126 or CVE-2026-76964 until patched.Can user networks reach the SAP Gateway on port 33xx? They shouldn’t be able to. Following RedRays’ guidance, confirm gw/acl_mode is 1 and that secinfo and reginfo have explicit rules rather than relying on the internal host keyword.Which identity providers does each system trust for SAML? Review the list in transaction SAML2, remove anything stale, and audit privileged SAML logons from unexpected sources.If you’re on RISE, when is SAP applying the November notes to your landscape? Ask your SAP contact for a date, and plan your exposure around that date rather than Patch Day.Can your SAP systems call out to the internet freely? Web shells and credential theft both need an outbound path. The npm attack on SAP’s developer packages sent stolen secrets straight to GitHub. Making those answers stick with zero trustThe checklist gets you through this week, but December’s Patch Day will raise the same questions, and so will the one after that. A zero trust architecture keeps the answers to checks 1, 2 and 5 from drifting as your landscape changes. You still need SAP’s fixes, since nothing in the architecture repairs a heap overflow or a skipped signature check, but it narrows who can reach the system while you wait for them.For user and partner access, Zscaler Private Access for RISE with SAP runs App Connectors inside the RISE private cloud. SAP manages them, and they only make outbound connections, so the Web Dispatcher and gateway are never published to the internet and a scanner looking for exposed SAP has nothing to find. Access is granted per user and per application. A contractor who needs Fiori never gets a network route to port 33xx, and neither does a compromised laptop sitting on the corporate network.ZPA also appears by name in SAP’s own RISE Roles and Responsibilities as an optional service. SAP installs and configures the ZPA connector inside your landscape and allowlists it in the load balancer, and your team owns the access policy, the connection to your identity provider and the client rollout. Security and SAP Basis teams each keep the part they already run.Inbound access is half the picture. Most of the attacks in the table above also needed a way back out, whether that was a web shell calling home or stolen credentials heading to an attacker’s GitHub repository. Zscaler Zero Trust Cloud inspects that egress traffic before it reaches the internet. Today, RISE customers can ask SAP to route their landscape’s internet-bound traffic through their own Zscaler inspection, and some already do. That arrangement depends on SAP agreeing to it and isn’t guaranteed to stay on the menu, so if outbound inspection matters to you, raise it with SAP now and get it written into your setup.Zero Trust Cloud also covers the traffic between workloads. A RISE landscape rarely stands alone: integration servers, middleware, partner systems and the applications in your own cloud accounts all exchange data with it. Zero Trust Cloud connects those workloads to SAP by policy instead of by network route, so a compromised integration server doesn’t come with a network path into the SAP landscape. Where to startIf you own the RISE migration itself, this month’s patches matter to you for a different reason. In the RISE programs we work on, the biggest source of delay is often keeping a zero trust architecture intact through the move: getting security to sign off on how users, partners and workloads will connect to the new landscape. Flaws like these are why that sign-off is hard to get, because no security team wants to put a Web Dispatcher on the internet or open the gateway to a flat network. Designing that access in at the start takes it off the migration’s critical path.Whether you’re planning the move or already on RISE, start by mapping what in your SAP landscape is reachable today: from the internet, from user networks and from partners. Zscaler’s SAP team can work through that map with your application, Basis and security teams and show what a zero trust design would look like for your landscape. Talk to us about securing RISE with SAP.
[#item_full_content] On November 10, 2026, SAP fixed four critical vulnerabilities, all rated CVSS 10.0 and all exploitable without a login. They sit in the ICM, the Web Dispatcher, the SAP Gateway and the SAML2 service provider, the components closest to the network. None had been reported as exploited at publication.I wouldn’t expect that to hold for long. In August, attackers started going after a critical SAP Commerce Cloud flaw three days after the fix shipped, before anyone had published an exploit for it. RISE with SAP customers have an extra wrinkle, because SAP’s maintenance schedule determines when these fixes reach their landscape. Until they do, the thing you can actually manage is how exposed those systems are, and that’s what the rest of this post covers. What SAP fixed in November 2026All four critical findings hit the parts of SAP that face the network: the HTTP stack, the reverse proxy in front of it, the gateway that application servers use to talk to each other, and single sign-on.ComponentCVEWhat goes wrongWorkaroundICM (NetWeaver AS ABAP)CVE-2026-76964Malformed WebSocket frames corrupt heap memory before login; possible code executionReach ICM only through a patched Web Dispatcher, and keep ICM ports unreachableSAP Web DispatcherCVE-2026-89126Same root cause in the reverse proxy, including embedded and HANA XS dispatchersDisable WebSocket support, which breaks ABAP Push Channels and some Fiori featuresSAP GatewayCVE-2026-89103With no explicit secinfo/reginfo rules, the gateway trusts the attacker as one of its own app serversNone in the noteSAML2 service provider (AS ABAP)CVE-2026-120017Some configurations skip the signature check on incoming assertions, so anyone can log in as any userNone; patch onlyOf the four, the gateway flaw says the most about where SAP risk comes from. The gateway decides trust based on network position, so traffic that looks like it came from inside the landscape gets treated as a peer. Zero trust architectures are built to get rid of exactly that assumption, and it’s the thread running through everything below. How fast do attackers exploit SAP vulnerabilities?Critical SAP flaws are now getting weaponized within days of a patch, and occasionally before one exists. The table below covers the last eighteen months.WhenFlawPatch to exploitationAug 2026Commerce Cloud RCE (CVE-2026-58231, CVSS 10.0)3 days; attempts hit honeypots Aug 14 with no public PoCApr 2026SAP CAP and MTA npm packages (Mini Shai-Hulud)Not a vulnerability: four packages trojaned through a hijacked release pipeline, live for 2 to 4 hoursSep 2025S/4HANA ABAP code injection (CVE-2025-42957, CVSS 9.9)About 24 days; patched Aug 11, exploitation confirmed Sep 4Mar to Apr 2025NetWeaver Visual Composer (CVE-2025-31324, CVSS 10.0)Negative; exploited in the wild before SAP’s Apr 24 emergency patchThe broader industry data points the same way. Mandiant’s M-Trends 2026 puts the average time to exploit at an estimated minus 7 days, which means exploitation routinely starts before a fix ships.AI is shortening what’s left of that timeline. In June, Anthropic showed a model turning freshly published patches into working exploits within an hour, at roughly $2,000 per Windows privilege-escalation exploit. A month earlier, Google’s threat intelligence group reported the first zero-day it believes attackers built with AI help, which had been prepared for a mass exploitation campaign.Two caveats are worth stating plainly. VulnCheck’s data shows exploitation in 2026 is fast but holding steady rather than accelerating, and nobody has documented an AI-built exploit against SAP yet. What has changed is the cost of reading an SAP patch and working backward to an exploit. That cost keeps falling, and patch windows were already too slow before it started. RISE with SAP: who patches, and what you still controlSAP’s Roles and Responsibilities documents for RISE are the contract-level reference for who does what, and they split patching more finely than most customers assume. Kernel patches and Basis security notes are standard SAP services, so fixes like this month’s ICM and Web Dispatcher notes land on SAP’s maintenance schedule rather than yours. Application-level security notes are a packaged service bought separately, and testing implemented notes stays with the customer either way.The same document makes exposure largely your decision. SAP will provide an external IP and configure a web application firewall for internet-facing scenarios when you ask for them. Whether the Web Dispatcher should face the internet at all is yours to decide, along with which users, partners and networks can reach the gateway and the SAML endpoint, and how application identity and authorization are configured.For a RISE customer, then, the most useful question this week is what an attacker could reach while the fix is still in flight. Patch speed is largely out of your hands. What SAP teams should check this weekYou can answer all five of these with tools you already have. I’d get your SAP Basis and security teams in a room for an hour this week and work through them together, since each team usually holds half of the answer.Is any Web Dispatcher or ICM port reachable from the internet? Scan from outside your network, not from your asset inventory. If one is, it’s exposed to CVE-2026-89126 or CVE-2026-76964 until patched.Can user networks reach the SAP Gateway on port 33xx? They shouldn’t be able to. Following RedRays’ guidance, confirm gw/acl_mode is 1 and that secinfo and reginfo have explicit rules rather than relying on the internal host keyword.Which identity providers does each system trust for SAML? Review the list in transaction SAML2, remove anything stale, and audit privileged SAML logons from unexpected sources.If you’re on RISE, when is SAP applying the November notes to your landscape? Ask your SAP contact for a date, and plan your exposure around that date rather than Patch Day.Can your SAP systems call out to the internet freely? Web shells and credential theft both need an outbound path. The npm attack on SAP’s developer packages sent stolen secrets straight to GitHub. Making those answers stick with zero trustThe checklist gets you through this week, but December’s Patch Day will raise the same questions, and so will the one after that. A zero trust architecture keeps the answers to checks 1, 2 and 5 from drifting as your landscape changes. You still need SAP’s fixes, since nothing in the architecture repairs a heap overflow or a skipped signature check, but it narrows who can reach the system while you wait for them.For user and partner access, Zscaler Private Access for RISE with SAP runs App Connectors inside the RISE private cloud. SAP manages them, and they only make outbound connections, so the Web Dispatcher and gateway are never published to the internet and a scanner looking for exposed SAP has nothing to find. Access is granted per user and per application. A contractor who needs Fiori never gets a network route to port 33xx, and neither does a compromised laptop sitting on the corporate network.ZPA also appears by name in SAP’s own RISE Roles and Responsibilities as an optional service. SAP installs and configures the ZPA connector inside your landscape and allowlists it in the load balancer, and your team owns the access policy, the connection to your identity provider and the client rollout. Security and SAP Basis teams each keep the part they already run.Inbound access is half the picture. Most of the attacks in the table above also needed a way back out, whether that was a web shell calling home or stolen credentials heading to an attacker’s GitHub repository. Zscaler Zero Trust Cloud inspects that egress traffic before it reaches the internet. Today, RISE customers can ask SAP to route their landscape’s internet-bound traffic through their own Zscaler inspection, and some already do. That arrangement depends on SAP agreeing to it and isn’t guaranteed to stay on the menu, so if outbound inspection matters to you, raise it with SAP now and get it written into your setup.Zero Trust Cloud also covers the traffic between workloads. A RISE landscape rarely stands alone: integration servers, middleware, partner systems and the applications in your own cloud accounts all exchange data with it. Zero Trust Cloud connects those workloads to SAP by policy instead of by network route, so a compromised integration server doesn’t come with a network path into the SAP landscape. Where to startIf you own the RISE migration itself, this month’s patches matter to you for a different reason. In the RISE programs we work on, the biggest source of delay is often keeping a zero trust architecture intact through the move: getting security to sign off on how users, partners and workloads will connect to the new landscape. Flaws like these are why that sign-off is hard to get, because no security team wants to put a Web Dispatcher on the internet or open the gateway to a flat network. Designing that access in at the start takes it off the migration’s critical path.Whether you’re planning the move or already on RISE, start by mapping what in your SAP landscape is reachable today: from the internet, from user networks and from partners. Zscaler’s SAP team can work through that map with your application, Basis and security teams and show what a zero trust design would look like for your landscape. Talk to us about securing RISE with SAP.
