SAP: accept the patch with route and runtime evidence
SAP’s November fixes require checking the component, the access path and the effective configuration. Organize that evidence so change acceptance does not depend on the version inventory alone.
Читати португальськоюBy Pentesty
Separate the components before accepting the change
SAP’s public November 10, 2026 bulletin lists maximum-severity fixes for ICM, Web Dispatcher, Gateway and the SAML2 provider. These are four distinct references: CVE-2026-76964, CVE-2026-89126, CVE-2026-89103 and CVE-2026-120017. For the last issue, the record published by SAP as the CNA describes possible user impersonation under certain authentication configurations.
In its original ICM2SHELL research, Onapsis describes memory corruption in the WebSocket code shared by ICM and Web Dispatcher. The component at the network edge also needs individual assessment.
The PROXYGATE research concerns SAP Gateway’s trust in proxy connections. Onapsis identifies the state of prxyinfo and, where applicable, gw/acl_mode_proxy as part of the assessment; reviewing only secinfo and reginfo does not complete that work.
Make the diagram match the observed environment
For the business, the acceptance question is concrete: which component answered each connection after the change? Propose one row per instance, identifying its owner, function, observed version, authorized origin and destination. Include test environments holding business data. A list of server names does not establish that an integration’s actual path ends at the component listed in the record.
Compare the approved diagram with an authorized network observation. Record whether the connection reaches the expected intermediary and whether another path to the backend exists. A denied connection is useful evidence only when its origin, destination and responding control are recorded. A missing response alone may indicate a collection failure and requires investigation.
Gather evidence that lets someone repeat the decision
The record can be small if another responsible person can check the conclusion. Before the maintenance window, define the expected result for a legitimate integration, the rejection condition for an unauthorized origin and the person who decides about downtime. Use fictitious identifiers and supported procedures; this approach does not require reproducing the researchers’ exploit.
- Identity: associate each item of evidence with the instance and component actually observed. Record the time, version, patch level and reference to the instructions consulted by the SAP Basis owner.
- Configuration: compare the effective state with the approved policy. A changed file, completed transport or management screen alone does not establish which configuration the process is using.
- Operation: retain the result of the permitted connection and the benign rejection test. Tie both to the same maintenance window and record deviations, dependencies and the owner of each exception.
Acceptance depends on the combined evidence
One team may deliver the package while another validates the route. Acceptance should bring those observations into the same record, keeping proven conclusions, incomplete checks and temporarily accepted exceptions distinct. Missing data must not become a favorable result. If an instance was outside the maintenance window, record it explicitly with an owner and a next action.
Public material does not replace the note applicable to the installation. Authenticated SAP guidance and operational validation remain necessary when deciding versions, parameters and restarts. The same discipline appears in PowerSYSTEM Center update acceptance: the delivered package needs to connect to the state that was observed. This proposed assessment supports that evidence and does not guarantee an absence of compromise.
Frequently asked questions
Do secinfo and reginfo checks close PROXYGATE?
No. The primary analysis points to the proxy policy. Acceptance needs to record the effective rule and the remediation instructions applicable to the observed kernel.
Does a patched Web Dispatcher protect every backend?
That conclusion requires establishing the conditions in the specific guidance and an exclusive access path. A direct route to the backend needs its own assessment.
Must I run an exploit to accept the change?
This approach proposes configuration inspection and benign access tests with authorization and fictitious data. A compromise investigation has its own scope and evidence requirements.
Does the announcement confirm attacks on customers?
Onapsis reported no observed active exploitation of ICM2SHELL or PROXYGATE in the November 10 advisories consulted. That limited observation does not establish an absence of incidents.
Sources and references
- Cyber Security Brazil: editorial news reference
- BleepingComputer: reporting on the four SAP flaws
- SecurityWeek: ICM2SHELL and PROXYGATE reporting
- Cybersecurity News: SAP Gateway and ICM context
- SAP: public November 2026 patch bulletin
- Onapsis: original PROXYGATE research
- Onapsis: original ICM2SHELL research
- CVE-2026-120017: record published by SAP
Original Pentesty analysis, published November 10, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.