S4GET, la falla pre-autenticazione nel kernel SAP S/4HANA con CVSS 9.8

Il 8 settembre 2026 SAP ha pubblicato la Security Note 3759472 correggendo CVE-2026-58240, una vulnerabilità pre-autenticazione nel Message Server di SAP NetWeaver con punteggio CVSS 3.1 di 9,8. Scoperta da Pablo 'Partu' Agustin Artuso di Onapsis Research Labs e battezzata S4GET, la falla consente a un attaccante remoto e non autenticato di registrarsi come nodo fidato nel cluster SAP, propagare il trust a tutti gli application server e ottenere esecuzione remota di codice con i privilegi dell'utente operativo sidadm. Il canale d'attacco è la stessa porta pubblica 36NN che i client SAP GUI usano per il login quotidiano, rendendo impraticabile la mitigazione tramite segmentazione di rete senza interrompere le operazioni aziendali.

Il cuore del problema: quando il codice legittimo diventa vulnerabile

Il Message Server di SAP NetWeaver funge da broker centrale per la distribuzione delle richieste nel cluster: ogni application server si registra presso di esso per ricevere connessioni dai client SAP GUI. Durante questa fase di registrazione, il codice non valida sufficientemente che il richiedente sia effettivamente un nodo interno autorizzato. Artuso ha identificato questa lacuna come un logic flaw intrinseco, non come una configurazione errata o un hardening insufficiente. "S4GET is a logic flaw, not a misconfiguration. It is present in SAP's 9.x kernel lines – the kernels that SAP S/4HANA and SAP S/4HANA Cloud Private Edition run on", ha dichiarato il ricercatore secondo quanto riportato da The Hacker News.

Questa distinzione ha conseguenze operative concrete: un audit di sicurezza orientato alla configurazione non rileva la falla, perché il comportamento vulnerabile è quello previsto dal codice stesso. Secondo shattered.io, l'anomalia risiede nella mancata verifica dell'autenticità dei componenti applicativi durante la registrazione, che permette a un pacchetto artificioso di far accettare all'attaccante l'indirizzo IP come nodo fidato del cluster.

Come funziona la catena di attacco: dalla porta pubblica al sistema operativo

Una volta stabilito il trust, il Message Server lo propaga automaticamente a tutti gli application server collegati. L'attaccante può quindi invocare funzioni RFC (Remote Function Call) normalmente riservate ai componenti interni del cluster. Queste invocazioni transitano attraverso lo stesso canale di comunicazione legittimo, rendendo invisibile l'attività malevola ai controlli di traffico convenzionali.

L'esito finale è l'esecuzione remota di codice con i privilegi dell'account sidadm, l'utente amministrativo del sistema operativo che gestisce l'istanza SAP. Secondo il CERT-EU, citando l'analisi Onapsis, "The Message Server propagates that trust to every application server in the cluster, and that a successful attack yields remote code execution as the operating-system user that runs SAP". L'account sidadm detiene privilegi elevati sul sistema host: la compromissione di questo utente equivale al controllo completo della macchina sottostante.

"What makes it uniquely dangerous is its reachability: the flaw is triggered through the same public port that every SAP GUI client connects to, so it cannot be firewalled away without breaking the end-user logon. Exploitation requires no credentials, no certificate, and no pre-existing misconfiguration."
— Pablo 'Partu' Agustin Artuso, Onapsis Research Labs, citato da The Hacker News

Perché la segmentazione tradizionale non basta

La criticità di S4GET non risiede soltanto nella facilità di exploitation—il vettore CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H documenta accesso di rete, bassa complessità, nessun privilegio richiesto, nessuna interazione utente—ma nella sua irriducibilità architetturale. La porta 36NN non è un servizio ausiliario esposto per errore: è il canale primario attraverso cui gli utenti aziendali accedono quotidianamente al sistema ERP. Firewallarla o spostarla in una VLAN segregata interromperebbe le operazioni di business.

Questa caratteristica ripropone un pattern già osservato nel landscape delle vulnerabilità SAP. Il confronto con 10KBLAZE del 2019 e con OVERPASS (CVE-2026-44756, CVSS 10.0) mostra come i sistemi ERP più moderni ereditino ancora vulnerabilità di progettazione nel codice di autenticazione e trust interno. La differenza rispetto a S4GET è specifica: mentre OVERPASS colpiva il Gateway SAP con un meccanismo diverso, S4GET sfrutta il Message Server e il suo modello di propagazione del trust per raggiungere l'intero cluster da un singolo punto di ingresso.

Le aziende che operano in ambienti on-premises o in Cloud Private Edition si trovano così di fronte a un dilemma di pianificazione: le finestre di manutenzione per applicare patch ai kernel SAP richiedono settimane di preparazione per test di regressione e coordinamento con i processi industriali, mentre l'esposizione effettiva inizia con la pubblicazione della vulnerabilità. I controlli SAP standard—autorizzazioni, separazione dei compiti (SoD), policy password—sono ininfluenti perché l'attacco è interamente pre-autenticazione.

Cosa fare adesso

Le azioni prioritarie per i team responsabili dei sistemi SAP si concentrano su tre ambiti: identificazione, contenimento e correzione definitiva.

Verificare i patch level attuali. Confrontare le versioni kernel in produzione con i livelli minimi sicuri documentati nella SAP Security Note 3759472: 9.16 PL 100, 9.18 PL 32, 9.19 PL 17, 9.20 PL 7. Secondo shattered.io ed exploit-intel.com, questi sono i soli livelli che includono la correzione completa del logic flaw.

Mappare l'esposizione delle porte 36NN. Identificare quali sistemi rendano raggiungibile la porta del Message Server dalla rete esterna o da segmenti non fidati. Il CERT-EU ha segnalato la raggiungibilità attraverso la stessa porta dei client SAP GUI come condizione necessaria all'attacco.

Pianificare l'applicazione della patch nel più breve ciclo di manutenzione disponibile. Non emergono nel dossier workaround temporanei alternativi alla correzione definitiva; il brief non documenta mitigazioni intermedie che preservino la funzionalità operativa.

Monitorare i log del Message Server per registrazioni anomale di nodi. La fonte non specifica indicatori di compromissione precostituiti, ma la catena di attacco lascia tracce nella propagazione del trust che possono essere identificate tramite audit dei componenti registrati.

Il ritorno del trust implicito nei sistemi critici

S4GET riapre una conversazione che il settore della sicurezza enterprise tende a considerare risolta: la fiducia presupposta tra componenti interni di un sistema distribuito. Il Message Server assume che chi si presenta per registrarsi sia legittimo perché la rete interna è considerata perimetralmente protetta. Quando quel perimetro coincide con la stessa interfaccia di accesso utente, l'assunzione crolla senza possibilità di riconfigurazione.

La vulnerabilità documenta anche un ritmo di scoperta che non si è attenuato nei kernel SAP: dopo 10KBLAZE nel 2019 e la piattaforma di vulnerabilità pre-autenticazione emersa nel 2026, il codice di base del sistema ERP continua a nascondere logic flaw con impatto sistemico. Per le organizzazioni che mantengono S/4HANA on-premises, il messaggio è che la modernizzazione dell'architettura di business non ha automaticamente eliminato le fragilità del layer di infrastruttura.

L'EPSS dello 0,34% nel breve termine potrebbe apparire contenuto, ma la struttura della falla—nessuna credenziale, nessun prerequisito, impatto massimo sul sistema host—la rende tecnicamente banale da automatizzare. La finestra tra patch day ed exploitation attiva, misurata in giorni per vulnerabilità SAP precedenti, impone ai team di sicurezza una velocità di risposta che i processi di change management tradizionali non sempre sostengono.

FAQ

È necessario avere credenziali SAP per sfruttare questa vulnerabilità?
No. La falla è pre-autenticazione: l'attaccante non necessita di username, password, certificati o accessi pregressi.

Posso bloccare l'attacco con il firewall o con le ACL del Gateway?
No. La porta di attacco è la stessa porta 36NN usata dai client SAP GUI legittimi; bloccarla interromperebbe le operazioni. Le ACL del Gateway vengono bypassate dalla propagazione automatica del trust dal Message Server.

I sistemi SAP S/4HANA in versione public cloud sono esposti?
Il brief non specifica la condizione delle istanze SAP-managed in public cloud; le versioni affette documentate sono quelle on-premises e Cloud Private Edition con kernel 9.16-9.20.

Fonti

• https://shattered.io/it/sap-netweaver-s4get-cve-2026-58240-cvss-9-8/
• https://onapsis.com/blog/s4get-cve-2026-58240-sap-message-server-threat-advisory/
• https://tech-insider.org/sap-overpass-s4get-critical-vulnerabilities-2026/
• https://www.strix.ai/cve/CVE-2026-58240
• https://exploit-intel.com/vuln/CVE-2026-58240
• https://thehackernews.com/2026/09/sap-patches-cvss-100-kernel-flaw.html
• https://forkast.news/saps-september-patch-day-drops-four-critical-cves-three-of-them-bypass-authentication-entirely/
• https://nvd.nist.gov/vuln/detail/CVE-2026-58240
• https://cert.europa.eu/publications/security-advisories/2026-011/
• https://support.sap.com/en/my-support/knowledge-base/security-notes-news/september-2026.html?isu_page=1