Proxygate Cve 2026 89103 Sap Netweaver Gateway Threat Advisory

Navigating November’s Historic SAP Security Patch Day – LIVE WEBINAR Join Onapsis to talk through November’s Vulnerabilities. November 12th, 10am ET Register here

As part of today’s SAP Security Patch Day, SAP released SAP Security Note # 3798345 (along with FAQ Note # 3810197 ) to fix PROXYGATE (CVE-2026-89103), a vulnerability in the SAP Gateway discovered and reported by the Onapsis Research Labs (ORL). The note is

In summary, PROXYGATE is a pre-authentication remote code execution vulnerability in the SAP Gateway. An unauthenticated attacker with network access runs operating system commands as adm (gaining complete control of the SAP system) with no credentials and no user interaction. It does not depend on a weak secinfo or reginfo , the two access control lists that are the focus of most hardening guidance. Instead, it turns on the gateway’s proxy access control list ( prxyinfo ), and some default configurations could leave that list open. Because the flaw is in the SAP kernel, it affects a broad range of releases, including kernel versions that are already out of maintenance. Further, the gateway runs not only on ABAP but also on AS Java, dual-stack, and standalone-gateway systems. Note that this is a kernel vulnerability, not just an ACL misconfiguration; the gateway’s proxy configuration determines whether it can be exploited. Some configurations make it non-exploitable, but others (many of them defaults) leave the system exposed. As a result, neither a version check nor patching alone tells you whether you are safe: on most kernel releases, SAP’s fix combines a kernel patch with setting the profile parameter gw/acl_mode_proxy = 1.

Onapsis disclosed this vulnerability to SAP as part of their long-standing coordinated-disclosure collaboration. The SAP Product Security Response Team acted quickly and delivered a fix on November’s Security Patch Day, a clear sign of how mature SAP’s vulnerability response process is and how seriously it takes the protection of its customers. This post is meant to help defenders understand the risk, outline the vulnerability at a level that security and SAP Basis teams can act on, and explain the protections already available.

As of the date of this publication, the Onapsis Research Labs have not observed active in-the-wild exploitation of this vulnerability. We continue to monitor our SAP Global Threat Intelligence Network and will deliver in-product updates and threat insights (including indicators of compromise) to our clients if that happens. We will update this blogpost with any observations for public knowledge and consumption as well.

The Onapsis Research Labs adhere to a strict set of responsible disclosure practices. Consequently, this post will intentionally omit technical exploitation details at this time and is solely focused on helping SAP customers assess exposure and support prompt risk remediation actions.

What is the PROXYGATE (CVE-2026-89103) Vulnerability?

The SAP Gateway is the component with which other systems communicate when they make RFC calls, the component where external RFC servers register, and the component that can start helper programs on the host when the SAP system needs one. It runs by default on every SAP NetWeaver ABAP application server, but it is not exclusive to the ABAP stack. The same native gateway component also runs in AS Java and dual-stack systems and can be deployed as a standalone gateway. Because it is part of the SAP kernel, a single flaw in it has the same shape everywhere it runs. A component that can start programs on a server needs a strong idea of who it is acting for, so the gateway relies on access-control lists:

secinfo decides who may start which programs, and where

reginfo decides which external programs may register with the gateway

prxyinfo decides which connections the gateway may relay, or open, on behalf of a client

The first two are the ones nearly every SAP security review checks. However, prxyinfo gets far less attention , and its state varies widely from one system to the . A gateway with a restrictive prxyinfo is not exploitable from untrusted networks. The problem is that several other configurations leave the proxy policy open, and some of them are defaults.

The guidance SAP and the security community have converged on for secinfo and reginfo is simple: trust the SAP system’s own hosts and nothing else . In a hardened configuration, a request is allowed only if the gateway concludes it comes from “local” or “internal”, meaning the gateway’s own server or another server of the same SAP system.

PROXYGATE attacks that conclusion. The flaw lives in the gateway’s CPI-C layer . Where the proxy policy allows it, a specially crafted series of requests lets an outside attacker who has not authenticated to anything make the gateway believe that the attacker’s request originates from an internal application server. From that point on, the access-control lists behave exactly as configured. The rule says “allow internal”, the gateway believes the request is internal, and the request is allowed. The gateway then starts what the attacker asked for, and in the most severe form of the attack, that is an arbitrary operating system command running as adm .

Nothing in the chain requires an SAP user, a password, or a certificate, and secinfo and reginfo play no part in stopping it. The one access-control list that does matter is prxyinfo : a restrictive proxy policy prevents the attack from getting started, and a permissive one leaves the door open. When the file is missing, the outcome depends on the profile parameter gw/acl_mode_proxy, which is precisely the setting SAP’s fix relies on.

The Risk and Impact of PROXYGATE on SAP Landscapes

The adm account owns the SAP installation: its executables, its instance profiles, its secure store, and its connection to the database. Running commands as that user is, in practice, full control of the SAP system. An attacker could, among other things:

Recover database credentials and other secrets from the secure store and profiles and subsequently use them to read or modify any business data directly in the database;

Collect RFC destinations and technical credentials that let them move laterally to both SAP and non-SAP systems connected to the target;

Change configuration or binaries to keep persistent access;

Stop the SAP system or destroy data with immediate impact to the business.

For an ERP system, this means direct exposure of financial, HR, supply chain and customer data, the integrity of the transactions built on it, and the availability of critical business systems – not to mention the regulatory reporting obligations (SOX, NIS2, GDPR and others) that follow a compromise.

Confirming whether a given system is exposed is less obvious than it sounds, and a version check alone will not confirm this here. The vulnerability lives in the SAP kernel (not the application release), so it applies to any system that runs an SAP Gateway – for example, any SAP NetWeaver ABAP-based system (SAP S/4HANA, SAP ERP/ECC, SAP BW, SAP Solution Manager, and others), AS Java and dual-stack systems that run a gateway, or a standalone SAP Gateway installation. Whether it can actually be exploited, however, is decided by the gateway’s proxy access control list (prxyinfo), and by what the gateway does when that list is missing. Because a missing proxy policy could be open by default, a gateway that was never hardened on this setting can be exposed without anyone having changed anything. Work through these checks in order.

Is there a prxyinfo file, and how is it scoped? The prxyinfo file is the gateway’s proxy ACL: a list of rules, each of which names a source (which hosts may open a proxy connection through the gateway) and a destination (where that connection may be forwarded), written as P SOURCE= DEST= . If prxyinfo exists but is permissive (the source allows broad networks where an attacker could sit, or a wildcard such as P SOURCE=* DEST=*), the system is vulnerable , regardless of its kernel patch level or profile parameters. Restricting it should be your first action. If prxyinfo exists and is restrictive (the source limited to fully trusted hosts, or to internal/local only, and the destination to trusted targets), the system is not exploitable from untrusted networks. An attacker could reach the flaw only by first gaining a foothold on one of those trusted hosts or network segments. Apply SAP’s fix anyway (see check 2): if the file is ever removed, the gateway falls back to its default proxy policy. If there is no prxyinfo file at all, continue to check 2.

If prxyinfo exists but is permissive (the source allows broad networks where an attacker could sit, or a wildcard such as P SOURCE=* DEST=*), the system is vulnerable , regardless of its kernel patch level or profile parameters. Restricting it should be your first action.

If prxyinfo exists and is restrictive (the source limited to fully trusted hosts, or to internal/local only, and the destination to trusted targets), the system is not exploitable from untrusted networks. An attacker could reach the flaw only by first gaining a foothold on one of those trusted hosts or network segments. Apply SAP’s fix anyway (see check 2): if the file is ever removed, the gateway falls back to its default proxy policy.

If there is no prxyinfo file at all, continue to check 2.

With no prxyinfo file, is gw/acl_mode_proxy set to 1? When no prxyinfo file exists, the profile parameter gw/acl_mode_proxy (SAP Security Note # 3224889 ) decides the gateway’s default proxy behavior. For backward compatibility, it ships disabled (0), which means allow-all: the system is vulnerable. With gw/acl_mode_proxy = 1, the default policy is restrictive and the system is protected. This is precisely the setting SAP’s secure-configuration guidance (SAP Security Note # 2926224 ) recommends. Not every kernel supports this parameter: Kernels 7.93 and 9.16 already support it, so the fix is setting it to 1, with no new kernel required. Kernels 7.22, 7.53, 7.54, 7.77 and 8.04 gain support for it with the kernel patch delivered in SAP Security Note # 3798345. Until the kernel is at or above the patch level below, the parameter does not exist, the gateway permits every proxy connection, and the system is vulnerable. Kernels 9.20 and 9.21 also receive a kernel patch, and SAP lists no manual activity beyond applying it.

Kernels 7.93 and 9.16 already support it, so the fix is setting it to 1, with no new kernel required.

Kernels 7.22, 7.53, 7.54, 7.77 and 8.04 gain support for it with the kernel patch delivered in SAP Security Note # 3798345. Until the kernel is at or above the patch level below, the parameter does not exist, the gateway permits every proxy connection, and the system is vulnerable.

Kernels 9.20 and 9.21 also receive a kernel patch, and SAP lists no manual activity beyond applying it.

Any patch level higher than the one listed contains the fix; the exact level may no longer be available for download. Kernels that are out of maintenance are also affected (7.20, 7.21, 7.40, 7.41, 7.42, 7.45, 7.49, 7.73, 7.81, 7.85 and 7.89) and must be upgraded to a downward-compatible kernel that is still in maintenance (see SAP Note # 3810197 ). Until a system can be patched, SAP lists no official workaround; until a system can be patched, a restrictive prxyinfo file (check 1) reduces exposure.

Please note that the following will not take a system out of scope:

a hardened secinfo/reginfo configuration;

SAP authorizations and role design;

the application stack on top of the gateway (ABAP, Java, dual-stack, or standalone);

applying the kernel patch alone, without a restrictive prxyinfo file or gw/acl_mode_proxy = 1.

Remediation Plan (Prioritized Actions)

Full remediation has two parts: a proxy policy that does not allow untrusted sources, and SAP’s fix from SAP Security Note # 3798345 (the kernel patch where required, plus gw/acl_mode_proxy = 1). The actions below are ordered to reduce risk as quickly as possible while the rollout is in progress.

Assess and identify. Build the list of systems that run an SAP Gateway, and include the ones that tend to be missed: standalone gateways, non-production systems holding copies of production data, and legacy systems still online. For each, record its prxyinfo state (permissive, restrictive or missing), its gw/acl_mode_proxy value, its kernel release and patch level, which networks can reach the gateway port, and how many application servers it has. Systems with a permissive prxyinfo, or with no prxyinfo and the parameter not set to 1, are your exposed population.

Close permissive proxy policies immediately. A permissive prxyinfo leaves the system vulnerable regardless of its patch level, so restrict it on every system where it is found, starting with any gateway reachable from the Internet. Validate the change in a test system first, since legitimate gateway-to-gateway scenarios may rely on proxy rules.

Secure systems with no prxyinfo file. Set gw/acl_mode_proxy = 1 wherever the kernel supports it (7.93, 9.16, and kernels already at the fixed patch level). On kernels that do not support it yet, create a restrictive prxyinfo file as an interim control until the patch is applied.

Apply the kernel patch . Patch kernels 7.22, 7.53, 7.54, 7.77, 8.04, 9.20 and 9.21, and upgrade out-of-maintenance kernels to a downward-compatible kernel that is still in maintenance. Then set gw/acl_mode_proxy = 1 where SAP requires it. Do this even on systems that already have a restrictive prxyinfo, so they stay protected if the file is ever removed. Prioritize Internet-facing systems first (an SAP Gateway has no reason to be reachable from the Internet; if one is, directly or through a permissive SAProuter route or partner connection, close that exposure at the perimeter in the meantime), then multi-server production systems and those holding your most sensitive data. Apply the patch, the parameter and the prxyinfo changes on every application server, not only the primary instance.

Narrow network access to the gateway. Restrict the gateway ports (33NN/48NN) to the hosts and interfaces that genuinely need RFC access. This does not fix the vulnerability, but it does shrink the population that can attempt its exploitation, now and for future gateway issues.

As one of the most prolific contributors to SAP security research, the Onapsis Research Labs has discovered and helped remediate well over 1,000 zero-day vulnerabilities in SAP business applications, and continues to partner closely with SAP to protect the global SAP customer base. This reflects the strong, long-standing relationship between the Onapsis Research Labs and SAP’s Product Security Response Team, and SAP’s proactive investment in securing its platform.

Protected BEFORE the Patch.

Because the Onapsis Research Labs discovered the vulnerability and helped SAP mitigate it, the intelligence and detection content required to protect against it were developed and delivered as part of the coordinated disclosure process, providing our customers with zero-day coverage prior to the patch being available. Throughout this period, the Onapsis Research Labs have been monitoring the global SAP threat landscape via our Global Threat Intel Network for any early signs of malicious activity. In product, Onapsis Defend has been actively monitoring customer landscapes for PROXYGATE since well before today’s patch release, keeping our customers protected throughout the coordinated-disclosure window.

Supported AFTER the Patch.

Zero-day rules in Defend are now to established production rules, effective immediately. Furthermore, Onapsis customers are able to take action within the Onapsis Platform immediately:

Onapsis Assess has been updated with new checks that identify exactly which systems in your estate are exposed to PROXYGATE , so security and Basis teams can prioritize remediation precisely rather than sweeping the whole landscape.

Onapsis Defend provides continuous detection for the exploitation pattern, giving teams coverage during the window between disclosure and full patch deployment, the period when exposure is highest.

And the Onapsis Research Labs continue to track exploitation activity, indicators, and attacker behavior in the wild, feeding updated intelligence back into detection content and Threat Dispatches for customers, so protection keeps pace with the evolving threat.

Taken all together, the full product coverage by Onapsis transforms a high-pressure critical patching event into a guided, measurable process. This is what it means for a security vendor to inform and keep SAP customers well ahead of the threat: robust protection before the patch is released, expert guidance through remediation when a patch is released, and continuous monitoring of the threat long after Patch Tuesday has come and gone to ensure customers remain protected.

PROXYGATE works by convincing the SAP Gateway that an unauthenticated, external attacker is one of the internal application servers. A crafted sequence of CPI-C conversation requests flips the gateway’s view of where the request originates. And once it treats the request as internal, its access control lists approve it, and the gateway starts what was requested as adm, which, in its most severe form, could be an arbitrary operating system command.

The result is a pre-authentication remote code execution, demonstrated end to end in the proof of concept shared with SAP. There is no SAP user, no password, and no user interaction, yet full control of the SAP system as the account that owns the installation is achieved. On a production ERP system, that means direct exposure of the business data, transaction integrity, and the availability of critical business applications.

Confirming exposure goes beyond a simple version check: it depends on the gateway’s proxy policy and, when no prxyinfo file exists, on whether SAP’s fix has been fully applied. Because an unconfigured proxy policy could be open by default, a gateway that no one ever hardened on this specific setting can be exposed without anyone having changed anything. Hardening secinfo or reginfo, the two lists most reviews focus on, will not take a system out of scope for exposure to this vulnerability.

The fix is available today in SAP Security Note # 3798345 , together with FAQ Note # 3810197 . This blog is meant first to help the SAP customer community understand the vulnerability and determine, clearly, whether their own systems are affected. Onapsis customers automatically receive all of these checks (as well as immediate, automatic detection of exploitation attempts, notably present before patch release today) directly through the Onapsis Platform. If you are not a customer and want help understanding your exposure, get in touch with us.