Four Maximum-Severity Flaws in SAP Just Got Patched — Here's What PROXYGATE and ICM2SHELL Actually Let an Attacker Do

Table of Contents

• What's confirmed, and a discrepancy worth flagging
• A few terms worth defining first
• How ICM2SHELL actually achieves code execution
• How PROXYGATE tricks the gateway into trusting an outsider
• The fourth flaw that didn't make the headlines
• The fix, and what to do if you can't patch today
• Why this is a fundamentals story for hardware and networking students
• What we're not claiming

SAP's November 2026 security updates didn't just include one scary flaw — they included four rated at the absolute maximum of the severity scale, each letting an attacker with no account, no password, and no user interaction take over an SAP system remotely. Two of them got branded names from the research firm that found and analyzed them: PROXYGATE and ICM2SHELL. This piece pulls from two independently reporting outlets that both spoke directly to that research, and flags a count that the two don't actually agree on.

What's confirmed, and a discrepancy worth flagging

SAP shipped the fixes on November 10, 2026, as part of its regular monthly security bulletin. BleepingComputer's Sergiu Gatlan, reporting the same day, says SAP patched 35 vulnerabilities total, with four rated maximum severity, and paraphrases SAP's own position that "unauthenticated attackers can exploit them to fully compromise the targeted systems remotely." SecurityWeek's Ionut Arghire, also reporting November 10, gives a different total — 42 new and updated security notes, with Onapsis Research Labs (the firm behind the technical analysis) counting 43, the extra note covering unrelated issues in SAP's Business AI Platform. Neither figure is wrong exactly; they're likely counting different things (CVE-bearing notes versus all notes issued that day), but it's worth flagging rather than picking one silently — if you need the authoritative count, SAP's own November 2026 Security Notes page on the SAP Support Portal is the place to check it.

A few terms worth defining first

SAP Gateway is the component that lets separate SAP application servers and external programs communicate with each other and with the core system — it's built specifically to be a trusted connection point between systems.

Internet Communication Manager (ICM) and SAP Web Dispatcher both sit at the network-facing edge of an SAP landscape, handling incoming HTTP, HTTPS, and WebSocket traffic before it reaches the actual application logic — meaning a flaw here is reachable by anything that can send the system a request at all.

WebSocket is a protocol that keeps a connection open for back-and-forth messages, rather than the client asking once and getting one reply the way ordinary HTTP works. Large WebSocket messages often get split into smaller fragments in transit and reassembled on the receiving end — and that reassembly step is exactly where this story's memory-corruption bug lives.

<sid>adm is the operating-system account that owns an SAP instance on its host server — getting command execution as this account is close to the worst outcome a flaw in SAP's own software can produce, short of root on the underlying OS itself.

How ICM2SHELL actually achieves code execution

ICM2SHELL is Onapsis's name for a single underlying weakness that shows up as two CVEs — CVE-2026-76964 in NetWeaver's ICM and CVE-2026-89126 in SAP Web Dispatcher — because both components share the same vulnerable kernel code for handling connections. In Onapsis's own words, quoted by SecurityWeek: "A specially crafted sequence of WebSocket messages makes the ICM or the WD write attacker-controlled data past the end of the memory it reserved for the connection." That's a classic memory-overflow bug, triggered through ordinary-looking WebSocket traffic rather than any authentication step. Onapsis says it built a working exploit and gave it to SAP privately, demonstrating full unauthenticated remote code execution running as <sid>adm — not just a crash. Both outlets confirm WebSocket support is commonly left on by default even on systems that don't actively use it, which is part of what makes this reachable on more deployments than its name might suggest.

How PROXYGATE tricks the gateway into trusting an outsider

PROXYGATE (CVE-2026-89103) works on a completely different principle: it doesn't corrupt memory, it abuses trust. SAP Gateway is supposed to check an access-control list — a file commonly called prxyinfo — before deciding whether a request relayed through it is coming from a genuinely internal application server or from somewhere external. Per SecurityWeek's account, if that list is left open or misconfigured, an attacker can send a request that simply claims to be an internal application server, and the gateway accepts it at face value. Onapsis describes the result plainly: "full control of the SAP system as the account that owns the installation." Because the flaw sits in the SAP kernel itself rather than in any one application, Onapsis says it affects a broad range of releases — including kernel versions that are already out of maintenance and no longer receiving general support.

The fourth flaw that didn't make the headlines

Most of the coverage of this patch day — including the earliest reporting — focused on PROXYGATE and ICM2SHELL by name, because those are the two with branded identities from Onapsis's research. But SecurityWeek's reporting lists a fourth flaw at the same maximum severity: CVE-2026-120017, described as a missing-authentication issue in NetWeaver that, in certain configurations, lets an unauthenticated attacker submit crafted data and impersonate arbitrary users — a path to full system compromise through a completely different mechanism than the other two. The article's own phrasing leaves the exact affected component a little ambiguous between ICM and the SAML2 Service Provider; treat that specific mapping as inferred rather than stated outright. Either way, if you've only seen this story described as "two SAP flaws," that undercounts what actually shipped on this patch day by one maximum-severity bug.

The fix, and what to do if you can't patch today

All four flaws were addressed in SAP's November 10, 2026 security notes, and a standard application of that month's patches closes each of them. Neither BleepingComputer nor SecurityWeek lists the specific SAP Note numbers in the text reviewed for this piece, so for the exact note to apply to your kernel release, SAP's own November 2026 Security Notes page is the source to check directly rather than relying on a number repeated secondhand.

If you can't patch immediately, the practical levers worth knowing about, based on how each flaw works: for PROXYGATE, auditing and tightening whatever access-control list governs gateway-relayed connections (the prxyinfo file and its related configuration) removes the specific trust gap the flaw depends on, even before the kernel update is applied. For ICM2SHELL, since the flaw triggers through WebSocket message handling, temporarily disabling WebSocket upgrade support on the affected component closes that path — though both outlets' sourcing on this specific workaround is thin, it would need a restart, and it may break legitimate integrations that genuinely rely on WebSocket connections. Neither workaround replaces applying the actual patch; they're stopgaps for the gap between disclosure and your next maintenance window.

Why this is a fundamentals story for hardware and networking students

Pull back from SAP specifically, and both PROXYGATE and ICM2SHELL are really lessons in how enterprise server infrastructure decides what to trust. PROXYGATE fails because a system meant to distinguish "internal" from "external" traffic took an attacker's word for it instead of actually verifying position on the network. ICM2SHELL fails because a protocol feature most administrators never think about — WebSocket message reassembly — was reachable by anyone who could talk to the server at all, patched or not, authenticated or not.

Innovative Academy doesn't run a dedicated SAP administration or ERP security program, but its Hardware & Networking training in Bangalore covers exactly the layer underneath a story like this one: configuring network access controls correctly, understanding how a server decides what traffic to trust and from where, hardening exposed services rather than leaving default settings in place, and building the patch-management discipline that closes a gap like this one before it's ever found by someone outside the organization. The specific software on top changes from one enterprise to the next; the access-control and hardening fundamentals underneath it don't. Contact for course details: 8447712333.

What we're not claiming

Neither BleepingComputer nor SecurityWeek reports active, in-the-wild exploitation of any of these four flaws as of the coverage reviewed for this piece — that's a meaningfully different situation from older, unrelated SAP vulnerabilities that CISA has previously confirmed under active attack, and the two shouldn't be conflated. The total patch count for this SAP security bulletin is reported differently between the two outlets (35 versus 42 or 43), and this piece hasn't attempted to reconcile that discrepancy independently — check SAP's own notes page if the exact figure matters to you. PROXYGATE's technical analysis is clearly attributed to Onapsis in both sources, but neither outlet explicitly states that Onapsis was the original discoverer of that specific flaw, as distinct from ICM2SHELL, where Onapsis's discovery and private disclosure to SAP is stated directly — that's a real distinction, not a technicality. CVE-2026-120017's exact affected component is inferred from one article's sentence structure rather than stated plainly, and shouldn't be repeated as a confirmed fact. And the specific SAP Note numbers and configuration parameter names circulating in some other coverage of this story aren't independently verified here — check SAP's own portal before acting on them operationally.