{"schema_version":"1.0","service":"Publicasta","type":"article","id":577,"slug":"sap_overpass_s4get_september_2026_patch_day_response","title":"SAP’s September 2026 Kernel Flaws Demand an Inventory-and-Patch Response","excerpt":"Two critical SAP vulnerabilities disclosed on September 8 reach core communication paths and can threaten an entire ERP landscape. Here is what is known, what is not, and how defenders should verify exposure without waiting for exploit chatter.","language":"en","default_language":"en","canonical_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=en","image":{"url":"https://publicasta.com/storage/projects/9/pages/577/2026/09/0eecf113-0be8-4e9f-9929-205dcb47ba8d.webp","alt":"Enterprise server room with an abstract network map and security patch indicators"},"publisher":{"id":9,"slug":"cybersecurity","name":"Cybersecurity Without Panic","url":"https://publicasta.com/cybersecurity"},"author":{"name":"Anton R"},"published_at":"2026-09-10T13:50:45+00:00","updated_at":"2026-09-10T13:50:45+00:00","content_markdown":"SAP’s September 2026 Security Patch Day contains two critical vulnerabilities that deserve immediate attention from organizations running SAP landscapes. One is a maximum-severity SAP Kernel flaw in Extended Passport processing, tracked as CVE-2026-44756 and nicknamed OVERPASS by the Onapsis Research Labs. The other, CVE-2026-58240, affects the SAP NetWeaver Message Server and has been called S4GET. Both can be reached remotely without authentication on affected systems.\n\n ![Enterprise server room with an abstract network map and security patch indicators](https://publicasta.com/storage/projects/9/pages/577/2026/09/0eecf113-0be8-4e9f-9929-205dcb47ba8d.webp)\n\n The important point is not that every SAP installation is already compromised. The important point is that these flaws sit in shared infrastructure used by multiple communication paths, including paths that administrators may assume are protected simply because the main business application is not directly exposed to the public internet. The first task is therefore not to wait for a dramatic breach report. It is to establish which kernel and Message Server components exist, whether they are reachable from hostile networks, and whether the vendor corrections have actually been installed and restarted.\n\n This article focuses on the defensive question: how should an SAP owner turn a high-severity advisory into evidence about their own environment?\n\n ## What SAP disclosed on September 8\n\n SAP publishes a regular Security Patch Day on the second Tuesday of each month. Its September 2026 bulletin lists the relevant security notes, affected product versions, and corrections for supported releases. The two issues discussed here are not ordinary application bugs confined to one optional business feature. They concern the SAP Kernel and NetWeaver Message Server, components that can sit underneath several products and protocols.\n\n CVE-2026-44756 is addressed by SAP Security Note 3747649. The underlying issue is described as insufficient boundary validation while the SAP Kernel processes Extended Passport data. Extended Passport is a tracing structure carried with requests. In a vulnerable implementation, malformed data can cause memory corruption or other undefined behavior. The CVE record describes a network-reachable condition with high impact to confidentiality, integrity, and availability, and Onapsis assesses the practical consequence as potential operating-system command execution on the SAP host.\n\n CVE-2026-58240 is addressed by SAP Security Note 3759472. It concerns a missing authentication check in the SAP NetWeaver Message Server, specifically the component identified as BC-CST-MS. The Message Server coordinates application-server registration and communication within an SAP environment. A system that accepts an unauthorised component as trusted can turn a boundary intended for internal cluster members into a route for broader compromise.\n\n The European Union Agency for Cybersecurity? No. The relevant technical summary comes from CERT-EU, the Computer Emergency Response Team for the institutions, bodies, offices and agencies of the European Union. CERT-EU rates the operational concern as serious because both vulnerabilities are remotely exploitable without authentication and recommends applying the two SAP security notes as soon as possible.\n\n ## Why the kernel issue is broader than one web endpoint\n\n The name OVERPASS can make the issue sound like a narrow feature bug. That is misleading. Extended Passport handling is shared kernel functionality. Onapsis says the vulnerable processing can be reached through more than one protocol and more than one SAP-facing layer. The reported paths include the internet-facing web layer, SAP GUI-related communication, and RFC connections between SAP systems.\n\n That does not mean every protocol is exposed in every deployment. It does mean that a simple statement such as “our SAP web interface is behind a VPN” is not enough to close the investigation. The same kernel code may be present in a system that is reachable through a reverse proxy, a remote-access design, a partner connection, an internal integration segment, or another SAP system. The correct question is: which affected kernel binaries are installed, what interfaces load them, and what network principals can reach those interfaces?\n\n The distinction matters during triage. A vulnerability can be unauthenticated without being public on the internet. An internal attacker, a compromised workstation, a breached partner network, or a poorly segmented management zone may be sufficient if the relevant service is reachable. Conversely, a service that is genuinely isolated still needs patching, because isolation assumptions change and because the vulnerable component may be reused after a later architecture change.\n\n Onapsis has deliberately withheld exploit details in its public advisory. That is useful for defenders: there is enough information to prioritize remediation without turning a news article into an exploitation guide. It also means that security teams should not use the absence of a public proof of concept as a reason to postpone action.\n\n ## Why S4GET changes the trust-boundary discussion\n\n The second vulnerability is different in mechanism but similar in consequence. The NetWeaver Message Server is designed to coordinate components in an SAP cluster. That design depends on being able to distinguish legitimate application servers from unauthorised systems. CVE-2026-58240 indicates that the relevant authentication check is insufficient in affected versions.\n\n According to CERT-EU’s summary of the researcher’s findings, an unauthenticated actor with network access may register an unauthorised component. Onapsis describes the risk as an attacker presenting themselves as a trusted node and having that trust propagated across the cluster. If successful, the result may include operating-system command execution using the account that runs SAP.\n\n This is why network location matters. The Message Server is not merely another port to close after the application is patched. It is part of the control plane for an SAP landscape. If it is reachable from a user network, a broad server segment, a partner network, or the internet, the reachable population becomes part of the risk calculation. But network filtering is a compensating control, not a substitute for the vendor fix. It can reduce exposure while a change is prepared; it cannot repair a broken trust check.\n\n Onapsis also notes a difficult operational constraint: the vulnerable path may be associated with the same public-facing port used by SAP GUI clients. Blocking it indiscriminately could break legitimate logon. This is a useful warning against emergency firewall changes made without an application owner. The response should combine patching, a verified exposure map, and narrowly scoped restrictions that preserve required business traffic.\n\n ## What is affected\n\n The affected-version lists are technical and should be checked against the exact SAP component inventory, not against a product name typed into a scanner. CERT-EU reports the following broad version families for CVE-2026-44756: KRNL64NUC 7.22 and 7.22EXT; KRNL64UC 7.22, 7.22EXT, 7.53 and 8.04; KERNEL 7.22, 7.53, 7.54, 7.77, 7.89, 7.93, 8.04, 9.16, 9.18, 9.19 and 9.20; and WEBDISP 9.16, 9.18, 9.19 and 9.20. The exact vulnerable build and the corrected build depend on the SAP security note and the platform combination.\n\n For CVE-2026-58240, the affected families reported by CERT-EU are KERNEL 9.16, 9.18, 9.19 and 9.20. The issue is associated with the NetWeaver Message Server component BC-CST-MS, so a generic check for “SAP servers” will produce both false positives and false negatives unless it is tied to installed component and patch-level data.\n\n These lists should not be treated as permission to infer safety from a different version string. SAP landscapes frequently contain multiple systems, old kernel binaries retained for compatibility, application servers on different patch levels, web dispatchers, development and quality environments, and system-to-system connections that do not appear in the same inventory used for internet-facing assets. A complete response must account for all of them.\n\n ## Exploitation status: urgent does not mean confirmed breach\n\n The public evidence available on September 9 does not establish that either vulnerability is being exploited at scale in the wild. Onapsis states that it had not observed active exploitation of OVERPASS at the time of its advisory. CERT-EU recommends immediate remediation because the technical impact and unauthenticated reachability make the vulnerabilities high-risk, not because it reports a confirmed campaign against every SAP customer.\n\n That distinction is worth preserving. “Critical” is a severity and prioritization signal. “Actively exploited” is an observation about attacker behavior. They are not interchangeable. A responsible incident response process should neither declare a breach from a CVE score nor dismiss a CVE because no public campaign has yet been documented.\n\n Security teams should monitor vendor updates, CERT-EU or national CERT advisories, and their own telemetry for changes. The local evidence is more valuable than general internet chatter: unexpected Message Server registrations, new processes under the SAP operating-system account, unusual administrative activity, unexplained changes to profiles or kernel files, anomalous RFC connections, and outbound traffic from SAP hosts to destinations not used by the business are all reasons to escalate. These indicators are not proof by themselves, but they can help determine whether patching is the only required action or whether the event needs incident response.\n\n ## A practical response sequence\n\n ### 1. Name an owner and freeze assumptions\n\n Assign one person or team to coordinate SAP basis administration, security operations, network engineering, and the business owner of the affected system. The coordinator should record decisions and timestamps. This avoids a common failure mode in enterprise patching: the basis team believes the firewall team owns exposure, the firewall team believes the application team has patched, and nobody has evidence that the running process changed.\n\n Do not begin with a generic vulnerability scan alone. Start with the authoritative SAP system inventory and confirm the systems that are actually running. Include production, disaster recovery, quality assurance, development, sandboxes, integration hubs, web dispatchers, and temporary systems used for migrations or testing.\n\n ### 2. Map the affected binaries and live network paths\n\n For each system, record the installed kernel family, exact patch level, operating system, Message Server presence, web dispatcher presence, SAP GUI or RFC exposure, and the network zones that can reach the relevant services. Compare the installed version with the corrected version specified in SAP Security Notes 3747649 and 3759472.\n\n The map should answer concrete questions: Is any relevant service bound to an externally routable address? Can a user workstation reach it directly? Can a partner or integration network reach it? Are there alternate routes through a load balancer, reverse proxy, VPN concentrator, bastion host, or cloud security group? Are production and non-production systems segmented in a way that has been tested recently?\n\n Record the evidence, not just the conclusion. A ticket that says “not exposed” is weak. A ticket that identifies the interface, firewall policy, last validation date, and approving owner can be revisited when the architecture changes.\n\n ### 3. Apply the vendor corrections, then restart and verify\n\n Follow SAP’s published security notes and the organisation’s change process. Kernel updates often require coordination across instances, operating systems, high-availability arrangements, and maintenance windows. A file copied onto a server is not the same as a running process using the corrected build.\n\n After the change, verify the running version on every relevant instance. Check that all application servers in a cluster use the intended kernel level. Check web dispatchers and other components separately. Confirm that a failover node, disaster-recovery environment, or inactive-looking instance has not been left behind. If the environment uses automation, capture the deployment result and compare it with independent runtime evidence.\n\n The success criterion is not “the patch job completed.” It is “every affected service in scope is running the corrected version, the change was recorded, and the reachability assessment still matches the deployed architecture.”\n\n ### 4. Use temporary controls while the patch is being prepared\n\n If an immediate upgrade is impossible, reduce exposure without assuming that the temporary measure solves the defect. Limit access to SAP services to the smallest set of authorised networks. Remove unnecessary internet exposure. Restrict administrative interfaces and Message Server paths from user and partner networks where the business design permits it. Review reverse-proxy and load-balancer rules rather than changing only the server firewall.\n\n For S4GET in particular, be careful with broad port blocking. A rule that breaks SAP GUI or cluster communication may create an availability incident without eliminating every route to the vulnerable component. Make changes with the SAP basis owner, test them against required traffic, and keep a rollback plan.\n\n If a system cannot be patched promptly, document the reason, the compensating controls, the person accepting the risk, and the date for reassessment. “We will patch later” is not a mitigation plan.\n\n ### 5. Check for signs of compromise\n\n Patching is still necessary if there are no suspicious indicators. It is also not sufficient if the system may already have been accessed. Review operating-system process creation, file integrity, scheduled tasks, service definitions, SAP security audit logs, Message Server and application logs, authentication events, administrative changes, and network connections around the period before the patch. Preserve relevant logs before retention windows remove them.\n\n The review should include the SAP operating-system accounts and privileged SAP users, but it should not stop there. An attacker who reaches the host may manipulate the operating system without creating an obvious SAP dialog login. Look for unexplained binaries, modified startup scripts, new local accounts, unusual outbound connections, and changes in the location or ownership of kernel files.\n\n If evidence suggests compromise, isolate carefully with the incident-response team and SAP owner. Do not erase the machine or rotate every credential blindly before collecting the evidence needed to understand scope. Credential rotation, rebuild decisions, and business-continuity actions should follow the organisation’s incident procedure.\n\n ## What the advisory means for different teams\n\n SAP basis administrators should treat the two security notes as a landscape-wide inventory and patching task. The main risk is leaving one instance, dispatcher, or recovery environment behind. Basis teams should also verify that the corrected kernel is running rather than trusting the deployment system’s status.\n\n Network teams should validate the real routes to SAP services, including paths that do not appear as ordinary internet exposure. They should review security groups, load balancers, VPN policies, partner connections, and segmentation between user, server, development, and management networks. They should not make a one-line firewall change without understanding SAP’s cluster and client communication.\n\n Security operations teams should enrich monitoring for suspicious activity around SAP hosts and operating-system accounts. They should compare the advisory’s disclosure time with local telemetry and preserve evidence when the logs are still available. A vulnerability ticket and an incident ticket are different objects; one does not replace the other.\n\n Identity and access teams should review privileged SAP and operating-system accounts if there is any sign of exploitation. Patching the software does not undo commands that may already have run, credentials that may have been read, or trust relationships that may have been altered.\n\n Business owners should help decide which systems need emergency maintenance and which traffic is genuinely required. SAP is often part of finance, manufacturing, logistics, payroll, procurement, or customer operations. The response should be fast, but a rushed outage can create its own serious risk.\n\n ## Questions that should be answered before closing the ticket\n\n A defensible closure record should be able to answer all of the following:\n\n - Which SAP systems and kernel families were checked?\n- Which instances, web dispatchers, and Message Servers were in scope?\n- What exact running versions were observed before and after the update?\n- Which systems were reachable from the internet, user networks, partner networks, or other SAP systems?\n- Were Security Notes 3747649 and 3759472 applied wherever relevant?\n- Were all cluster members, standby systems, and disaster-recovery systems verified?\n- What temporary network controls were used, and who approved them?\n- What logs and telemetry were reviewed for possible exploitation?\n- Did the review find any unexplained processes, registrations, administrative actions, or outbound connections?\n- Who accepted any remaining risk, and when will it be reviewed again?\n\n If the answer to one of these questions is “we do not know,” the work is not complete. It may still be reasonable to proceed to the next operational step, but the uncertainty should be explicit.\n\n ## The calm conclusion\n\n OVERPASS and S4GET are serious because they combine high impact with remote, unauthenticated reachability in shared SAP infrastructure. They are not a reason to assume that every SAP customer has been breached, and public reporting as of September 9 does not establish broad in-the-wild exploitation. They are a reason to stop treating SAP kernel patching as a narrow maintenance task.\n\n The useful response is disciplined: inventory the real landscape, map the real routes, apply the SAP corrections, restart and verify every affected component, use carefully scoped network restrictions during the change, and review telemetry for evidence of prior access. That sequence produces something more valuable than panic or reassurance: a documented answer about what is exposed, what has been fixed, and what still needs attention.\n\n ### Sources and scope\n\n The technical facts in this article are based on SAP’s September 2026 Security Patch Day materials, CERT-EU’s advisory on the two vulnerabilities, Onapsis Research Labs’ responsible-disclosure briefings, and the public CVE records referenced by CERT-EU. Product-specific remediation should follow the current SAP security notes available to the customer’s SAP Support account.","available_translations":[{"language":"ar","title":"ثغرات نواة SAP في سبتمبر 2026 تفرض جرداً شاملاً واستجابة عاجلة للتحديث","html_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=ar","markdown_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=ar","json_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=ar"},{"language":"de","title":"SAPs Kernel-Lücken vom September 2026 erfordern Inventarisierung und Patching","html_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=de","markdown_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=de","json_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=de"},{"language":"en","title":"SAP’s September 2026 Kernel Flaws Demand an Inventory-and-Patch Response","html_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=en","markdown_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=en","json_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=en"},{"language":"es","title":"Las fallas del kernel de SAP de septiembre de 2026 exigen inventariar y aplicar parches","html_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=es","markdown_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=es","json_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=es"},{"language":"fr","title":"Les failles du noyau SAP de septembre 2026 imposent un inventaire et une mise à jour immédiate","html_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=fr","markdown_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=fr","json_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=fr"},{"language":"pl","title":"Luki w jądrze SAP z września 2026 r. wymagają inwentaryzacji i pilnego łatania","html_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=pl","markdown_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=pl","json_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=pl"},{"language":"ru","title":"Уязвимости ядра SAP в сентябре 2026 года требуют инвентаризации и установки исправлений","html_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=ru","markdown_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=ru","json_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=ru"},{"language":"zh","title":"SAP 2026 年 9 月内核漏洞要求立即开展资产盘点与补丁响应","html_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=zh","markdown_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=zh","json_url":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=zh"}],"_links":{"self":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=en","api":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/sap_overpass_s4get_september_2026_patch_day_response?lang=en","html":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=en","canonical":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response?lang=en","markdown":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.md?lang=en","json":"https://publicasta.com/cybersecurity/sap_overpass_s4get_september_2026_patch_day_response.json?lang=en","channel":"https://publicasta.com/api/public/v1/channels/cybersecurity","channel_articles":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}