SAP ha reso pubblica l’8 settembre 2026, nel suo Patch Day mensile, una falla critica nel Message Server di NetWeaver che permette a un attaccante privo di credenziali di prendere il controllo completo di un cluster SAP. La vulnerabilità, tracciata come CVE-2026-58240 e battezzata S4GET dai ricercatori di Onapsis, ha ottenuto un punteggio CVSS 9.8 su 10, la fascia più alta della scala di gravità. Per le aziende italiane ed europee che gestiscono contabilità, logistica e produzione su infrastrutture SAP, la notizia arriva in un momento delicato: il patching dei sistemi SAP richiede quasi sempre finestre di manutenzione pianificate con settimane di anticipo, mentre la finestra di esposizione a un exploit pubblico si misura in giorni. Il caso si aggiunge a una lunga serie di episodi che seguiamo nella nostra sezione sicurezza dedicata alle vulnerabilità critiche e agli incidenti informatici del 2026.
Il problema non riguarda una configurazione errata né una password debole. È un difetto logico nel modo in cui il Message Server valida l’identità dei componenti applicativi che si registrano nel cluster. Chiunque abbia accesso di rete alla porta usata normalmente dai client SAP GUI può, in teoria, farsi passare per un nodo fidato e ottenere l’esecuzione di codice con i privilegi dell’account di sistema che gestisce l’installazione SAP, il cosiddetto sidadm. Non serve un certificato, non serve una configurazione debole preesistente: basta la sola raggiungibilità di rete.
Cos’è CVE-2026-58240 e perché si chiama S4GET
Il nome S4GET, coniato dai ricercatori di Onapsis Research Labs, richiama il fatto che la falla colpisce l’intera nuova generazione di kernel SAP, quelli su cui gira SAP S/4HANA 2025. Il componente coinvolto è il Message Server, identificato internamente da SAP con la sigla BC-CST-MS: si tratta del broker che smista le richieste di accesso SAP GUI all’interno di un cluster applicativo e che, in condizioni normali, dovrebbe fidarsi solo dei nodi effettivamente appartenenti all’infrastruttura.
Il problema è che il Message Server “non convalida a sufficienza l’autenticità dei componenti applicativi interni durante la registrazione”, per usare la formulazione tecnica riportata nella descrizione ufficiale della vulnerabilità. Tradotto in pratica: un attaccante che raggiunge in rete la porta pubblica usata dal servizio (la classica porta nella fascia 36NN, la stessa usata dai normali login SAP GUI) può inviare un pacchetto costruito ad arte e farsi accettare come componente legittimo del cluster. Da quel momento, il Message Server propaga la fiducia acquisita a tutti gli application server collegati, aprendo la strada all’esecuzione di programmi RFC e, in ultima istanza, all’esecuzione di codice arbitrario sul sistema operativo sottostante.
Onapsis ha descritto la scoperta come un difetto logico, non una configurazione errata, una distinzione che pesa parecchio dal punto di vista difensivo: non basta un audit di configurazione per trovarla, perché il comportamento vulnerabile è quello previsto dal codice stesso del Message Server prima della patch. Per approfondire la meccanica dei bypass di autenticazione in ambito enterprise, può essere utile anche il nostro approfondimento sul bypass di autenticazione scoperto in JFrog Artifactory, un caso con dinamiche di fondo simili anche se su uno stack completamente diverso.
Quali versioni SAP sono coinvolte
La falla riguarda il Message Server incluso nelle linee kernel 9.16, 9.18, 9.19 e 9.20, che sono le versioni su cui gira la generazione più recente di SAP S/4HANA, incluso S/4HANA 2025 e la variante S/4HANA Cloud Private Edition. Secondo Onapsis, ogni sistema S/4HANA 2025 e ogni installazione precedente già migrata su uno di questi kernel è potenzialmente esposta, e la stessa base di codice può essere presente anche in altri prodotti SAP basati su tecnologia ABAP che condividono lo stesso layer di infrastruttura.
SAP ha pubblicato il correttivo tramite la Security Note 3759472, indicando per ciascuna linea kernel il livello minimo di patch (Patch Level, PL) che risolve il problema. Chi si trova sotto queste soglie resta vulnerabile.
| Linea kernel SAP | Patch Level minimo sicuro | Prodotti tipici interessati |
|---|---|---|
| Kernel 9.16 | PL 100 | S/4HANA (rilasci precedenti migrati) |
| Kernel 9.18 | PL 32 | S/4HANA, NetWeaver AS ABAP |
| Kernel 9.19 | PL 17 | S/4HANA 2025 (rilasci intermedi) |
| Kernel 9.20 | PL 7 | S/4HANA 2025, S/4HANA Cloud Private Edition |
Chi amministra ambienti SAP dovrebbe considerare prioritario un inventario completo delle installazioni, verificando kernel e patch level di ogni istanza prima ancora di valutare i tempi della finestra di manutenzione. Le aziende che si affidano a partner esterni per la gestione SAP dovrebbero chiedere conferma scritta dello stato di patching entro la fine di settembre 2026.
Il punteggio CVSS 9.8 spiegato nel dettaglio
Un punteggio CVSS 9.8 si trova appena sotto il massimo teorico di 10.0 e viene assegnato solo a vulnerabilità che combinano bassissima complessità di attacco con impatto totale su riservatezza, integrità e disponibilità. Nel caso di S4GET, gli elementi che spingono il punteggio così in alto sono tre: l’attacco avviene interamente da rete (nessun accesso fisico o locale richiesto), non richiede alcun privilegio preesistente (l’attaccante parte da zero credenziali) e non richiede interazione umana (nessun clic su un link, nessuna azione della vittima). A questo si somma un impatto massimo su tutti e tre i pilastri della sicurezza: chi sfrutta la falla può leggere dati riservati, modificarli e interrompere il servizio a piacimento.
Per contestualizzare quanto sia raro un punteggio simile, vale la pena ricordare che la maggior parte delle vulnerabilità critiche pubblicate nel 2026 si ferma tra 8.0 e 9.1: bug che richiedono comunque qualche precondizione, come un account a basso privilegio o l’accesso a una rete interna già segmentata. S4GET invece non richiede nulla di tutto ciò, ed è esattamente questo aspetto “zero prerequisiti” a preoccupare di più gli analisti di Onapsis e del CERT-EU, che nel bollettino dedicato hanno definito l’accesso alla porta del Message Server sufficiente da solo a innescare la catena di compromissione.
Chi vuole calcolare manualmente il proprio livello di rischio interno può usare il calcolatore ufficiale CVSS 3.1 di FIRST.org per simulare scenari con mitigazioni parziali, per esempio con il Message Server segmentato dietro un firewall interno invece che esposto direttamente.
Come funziona l’attacco passo per passo
La catena di sfruttamento descritta da Onapsis e ripresa da CERT-EU si articola in pochi passaggi concettuali, ma richiede una conoscenza approfondita del protocollo interno del Message Server, cosa che rende plausibile un rapido sviluppo di strumenti di exploit una volta che i dettagli tecnici completi diventeranno pubblici.
- L’attaccante individua un Message Server raggiungibile sulla porta pubblica usata per i login SAP GUI, spesso nella fascia 3600-3699 a seconda del numero di istanza.
- Invia un pacchetto costruito ad arte che sfrutta l’insufficiente validazione durante la fase di registrazione di un nuovo componente nel cluster.
- Il Message Server accetta l’indirizzo IP dell’attaccante come nodo fidato, bypassando i normali controlli di trust del Gateway SAP, anche quando questi risultano correttamente configurati.
- La fiducia acquisita si propaga automaticamente a tutti gli application server collegati al cluster.
- L’attaccante invoca programmi RFC (Remote Function Call) riservati ai componenti interni, ottenendo l’esecuzione di comandi arbitrari con i privilegi dell’account di sistema sidadm.
Il punto più insidioso, sottolineato da più fonti tecniche, è che l’attacco sfrutta lo stesso canale usato ogni giorno dagli utenti legittimi per accedere via SAP GUI. Non esiste quindi un segnale di rete anomalo facile da individuare con un firewall tradizionale: il traffico verso quella porta è per definizione traffico atteso. Solo un’analisi comportamentale a livello applicativo, o la registrazione dettagliata delle operazioni di registrazione dei componenti nel cluster, può far emergere un tentativo di sfruttamento.
Chi ha scoperto la falla e come è stata gestita la divulgazione
A individuare S4GET è stato il team di ricerca di Onapsis, azienda specializzata da anni nella sicurezza degli ambienti SAP e collaboratrice storica del programma di divulgazione responsabile di SAP stesso. Il processo ha seguito lo schema classico della divulgazione coordinata: Onapsis ha segnalato la falla a SAP con largo anticipo, SAP ha sviluppato e testato la correzione, e la pubblicazione pubblica è avvenuta in contemporanea al rilascio della patch, nell’ambito del Patch Day di settembre 2026.
Nello stesso Patch Day, SAP ha corretto anche un’altra falla critica di gravità comparabile nel kernel, soprannominata OVERPASS. Le due vulnerabilità condividono un profilo di rischio simile, entrambe sfruttabili da remoto senza autenticazione e con esito finale l’esecuzione di comandi arbitrari sul sistema operativo, ma agiscono su livelli diversi dello stack: S4GET sul Message Server e sulla logica di trust del cluster, l’altra più in profondità nel kernel stesso. La coincidenza di due bug così gravi nello stesso ciclo di patch ha spinto diversi analisti a raccomandare un ciclo di patching straordinario invece di attendere la normale finestra trimestrale usata da molte aziende per gli aggiornamenti SAP.
Stato dello sfruttamento attivo e inclusione nel catalogo CISA KEV
Al momento della divulgazione, né Onapsis né SAP hanno riportato evidenze di sfruttamento attivo in circolazione. Anche il bollettino Blackpoint Cyber, diffuso agli MSP nei giorni immediatamente successivi al Patch Day, ha confermato l’assenza di segnalazioni di exploitation reale fino a metà settembre 2026. Allo stesso modo, alla data del 15 settembre 2026 la vulnerabilità non risultava ancora inserita nel catalogo Known Exploited Vulnerabilities di CISA, il registro statunitense che raccoglie le falle per cui esiste evidenza documentata di sfruttamento reale. La scheda ufficiale della falla, tracciata a livello internazionale, resta consultabile tramite il programma CVE di MITRE.
Questo dato, tuttavia, va letto con cautela e non come un motivo per rimandare la patch. La storia recente delle vulnerabilità SAP mostra un pattern ricorrente: exploit proof-of-concept pubblici compaiono in genere entro due o tre settimane dalla divulgazione di dettagli tecnici sufficientemente specifici, e da lì allo sfruttamento su larga scala il passo è breve, specialmente quando, come in questo caso, non serve alcuna credenziale. Diversi analisti, tra cui gli autori del blog Mallory.ai, hanno definito la vulnerabilità un problema di patching ad alta priorità proprio per la combinazione tra superficie di attacco pubblica e probabile rapida armatura da parte di gruppi criminali.
Il contesto: un anno record di falle SAP critiche
S4GET non nasce nel vuoto. Il 2026 si sta confermando un anno particolarmente intenso per le vulnerabilità negli ambienti enterprise mission-critical, con SAP che ha già dovuto affrontare almeno un altro incidente di gravità massima nei mesi precedenti: la falla in SAP Commerce Cloud, tracciata come CVE-2026-58231, che a suo tempo aveva ottenuto anch’essa un punteggio CVSS 10.0 pieno e aveva esposto secondo le stime circa 4.200 istanze pubblicamente raggiungibili. La differenza sostanziale è che quella falla colpiva la componente e-commerce (Commerce Cloud), mentre S4GET agisce sul cuore infrastrutturale condiviso da praticamente tutte le installazioni S/4HANA moderne, un bacino di sistemi potenzialmente molto più ampio anche se con minore esposizione diretta a internet.
Il parallelo con altre falle di autenticazione mancante emerse nello stesso periodo, come quella scoperta in JFrog Artifactory (CVE-2026-82329, CVSS 9,8) o nel gateway remoto SonicWall SMA1000, suggerisce un trend più ampio: gli attaccanti e i ricercatori si stanno concentrando sempre di più sui meccanismi di trust interno tra componenti, piuttosto che sulle classiche vulnerabilità di iniezione o cross-site scripting rivolte all’utente finale. Sono bug più difficili da scoprire ma, una volta trovati, offrono un impatto quasi sempre totale sul sistema colpito.
| Vulnerabilità | CVE | CVSS | Componente colpito | Stato exploit noto |
|---|---|---|---|---|
| S4GET (SAP NetWeaver) | CVE-2026-58240 | 9.8 | Message Server / BC-CST-MS | Nessuno confermato al 15/09/2026 |
| SAP Commerce Cloud RCE | CVE-2026-58231 | 10.0 | Commerce Cloud | 4.200 istanze esposte rilevate |
| JFrog Artifactory bypass | CVE-2026-82329 | 9.8 | Autenticazione repository | Divulgato con patch disponibile |
| Adobe Commerce/Magento RCE | CVE-2026-75650 | 10.0 | Piattaforma e-commerce | Divulgato con patch disponibile |
| N-central (terzo zero-day) | CVE-2026-86218 | 10.0 | Piattaforma di gestione remota | Terzo bug critico in 6 settimane |
L’impatto per le aziende italiane che usano SAP
SAP resta il sistema ERP più diffuso tra le medie e grandi imprese italiane, dalla manifattura alla logistica fino alla grande distribuzione, e la migrazione verso S/4HANA è un processo che moltissime aziende hanno accelerato negli ultimi due anni in vista della fine del supporto standard per SAP ECC, fissata da SAP stessa per il 2027. Questo significa che una fetta crescente del tessuto industriale italiano sta proprio in questi mesi transitando sui kernel 9.x coinvolti da S4GET, spesso in configurazioni ibride con ambienti di test, staging e produzione che convivono sulla stessa rete interna durante la fase di migrazione.
Il rischio pratico più concreto non è tanto l’esposizione diretta a internet del Message Server, descritta dagli stessi ricercatori di Onapsis come fortunatamente non comune, quanto la possibilità che un attaccante già presente nella rete interna, magari dopo una compromissione iniziale via phishing o un altro vettore, usi S4GET come tecnica di movimento laterale per saltare da un sistema periferico al cuore dell’ERP aziendale. In molte reti industriali italiane la segmentazione tra rete IT e rete OT, o tra ambienti di test e produzione, resta più teorica che reale, e questo aumenta il valore di un bug come questo per un attaccante che ha già messo piede nella rete. Il tema della segmentazione insufficiente è emerso anche nel caso Salt Typhoon contro IBM Italia, dove un attaccante ha sfruttato per settimane l’accesso laterale tra sistemi collegati prima di essere individuato.
Le aziende che si affidano a fornitori di hosting SAP gestito, molto diffusi tra le PMI italiane che non hanno un team SAP Basis interno, dovrebbero richiedere entro la fine di settembre 2026 una dichiarazione formale sullo stato del patch a fronte della Security Note 3759472, oltre a un controllo esplicito dell’esposizione della porta del Message Server verso reti non fidate.
Cosa devono fare i team di sicurezza SAP adesso
Le raccomandazioni operative diffuse da Onapsis e riprese da CERT-EU convergono su una sequenza di priorità piuttosto chiara, pensata per chi deve gestire dozzine o centinaia di sistemi SAP e non può applicare la patch ovunque nello stesso giorno.
- Censire tutte le installazioni SAP con kernel 9.16, 9.18, 9.19 e 9.20, verificando il patch level attuale contro le soglie minime sicure indicate nella tabella precedente.
- Applicare come priorità assoluta la Security Note 3759472 sui sistemi con il Message Server raggiungibile da internet o da reti non pienamente fidate.
- Verificare l’esposizione della porta del Message Server (fascia 36NN) tramite scansioni interne ed esterne, eliminando regole NAT dimenticate o accessi diretti da reti DMZ legacy.
- Rivedere le configurazioni di trust del Gateway SAP e del cluster, assicurandosi che solo gli indirizzi IP effettivamente appartenenti all’infrastruttura possano registrarsi come componenti.
- Estendere il controllo anche ai sistemi di test, sviluppo e staging, spesso trascurati nei cicli di patching ma ugualmente sfruttabili come punto di ingresso verso la rete di produzione.
- Attivare, dove disponibile, il logging dettagliato delle operazioni di registrazione dei componenti nel Message Server per individuare tentativi di sfruttamento pregressi o in corso.
Per chi gestisce anche l’infrastruttura di monitoraggio delle vulnerabilità in modo più strutturato, il nostro tutorial su come monitorare il catalogo CISA KEV con Python e un SIEM mostra un approccio automatizzato che si può adattare per tracciare anche le Security Note SAP più critiche, non solo le voci del catalogo americano. Per un confronto più ampio tra i cataloghi di vulnerabilità usati negli Stati Uniti e in Europa, si veda anche il nostro pezzo su CISA KEV vs ENISA EUVD.
Confronto con le vulnerabilità di autenticazione mancante più recenti
Le falle di tipo missing authentication come S4GET stanno diventando una categoria a sé nel panorama delle vulnerabilità enterprise 2026. A differenza delle classiche SQL injection o delle falle XSS, che richiedono quasi sempre un’interazione con un’interfaccia web esposta pubblicamente, questi bug colpiscono i meccanismi di fiducia tra componenti interni di un sistema distribuito, spesso progettati anni fa quando il modello di minaccia dominante era “la rete interna è fidata per definizione”. Quel presupposto oggi non regge più, soprattutto in ambienti cloud ibridi dove il confine tra rete interna ed esterna è sempre più sfumato.
Il caso ConnectWise ScreenConnect (CVE-2026-84869, CVSS 9,9) segue una logica simile: un bypass nella catena di autenticazione tra client e server di gestione remota, sfruttabile senza credenziali. Così come il caso N-central, arrivato al terzo zero-day critico in sei settimane con CVSS 10.0, anch’esso legato a debolezze nella catena di fiducia tra componenti di gestione remota. Il filo conduttore tra questi episodi è che gli attaccanti, di fronte a superfici di attacco web sempre più difese da WAF e filtri, si stanno spostando verso i protocolli interni e i meccanismi di trust tra servizi, un’area storicamente meno testata e meno monitorata.
Previsioni: cosa aspettarsi nelle prossime settimane
Sulla base del pattern storico osservato per vulnerabilità SAP di gravità comparabile, e delle dichiarazioni dei ricercatori coinvolti, è possibile delineare alcuni scenari plausibili per l’evoluzione di questa vicenda nelle prossime settimane.
- È probabile che entro la fine di ottobre 2026 emergano i primi tool o script proof-of-concept pubblici capaci di automatizzare la scoperta di Message Server vulnerabili esposti in rete, sulla base dell’esperienza con falle SAP precedenti di gravità simile.
- Se non verrà applicata la patch in modo diffuso, è ragionevole attendersi che S4GET venga aggiunta al catalogo CISA KEV nel momento in cui emergeranno le prime evidenze concrete di sfruttamento, come già accaduto in passato per altre falle SAP critiche entro 60-90 giorni dalla divulgazione.
- Le aziende di consulenza SAP e gli MSSP italiani che seguono clienti enterprise probabilmente inseriranno una scansione dedicata per S4GET nei prossimi cicli di audit di sicurezza, considerata la vastità del parco installato S/4HANA in fase di migrazione da ECC.
- È plausibile un aumento della pressione normativa, in particolare per le aziende soggette a NIS2 in Italia, affinché dimostrino tempi di patching più rapidi per falle di questa gravità, dato che il Message Server SAP rientra a pieno titolo tra i sistemi critici per la continuità operativa di molte filiere.
- Nel medio periodo, ci si può attendere che SAP e i principali vendor di sicurezza rafforzino i controlli automatici di configurazione del trust tra cluster, un’area finora poco coperta dagli strumenti standard di vulnerability assessment per ambienti SAP.
Perché questa falla è diversa dalle solite vulnerabilità SAP
Molte delle vulnerabilità SAP degli ultimi anni riguardavano moduli applicativi specifici, come il Commerce Cloud o singole transazioni ABAP personalizzate, e colpivano quindi un sottoinsieme relativamente circoscritto di clienti che usavano proprio quella funzionalità. S4GET è diverso perché colpisce un componente infrastrutturale condiviso praticamente da ogni installazione S/4HANA moderna, indipendentemente dal settore o dal modulo applicativo utilizzato. Non importa se un’azienda usa SAP per la contabilità, per la produzione o per la logistica: se gira su uno dei kernel coinvolti, il Message Server è comunque presente e potenzialmente vulnerabile.
Questo aspetto orizzontale della falla, che prescinde dal caso d’uso specifico, è probabilmente il motivo per cui CERT-EU ha scelto di emettere un bollettino a livello europeo invece di lasciare la comunicazione al solo canale SAP, un segnale che gli enti di sicurezza informatica dell’Unione considerano questa categoria di rischio come una priorità infrastrutturale trasversale, non un problema di settore.
Le lezioni per chi gestisce infrastrutture SAP in Europa
Al di là della patch specifica, il caso S4GET offre alcune lezioni più generali per chi gestisce ambienti ERP critici. La prima è che la segmentazione di rete resta la difesa più efficace anche contro bug non ancora divulgati: se il Message Server non è mai raggiungibile da segmenti di rete non fidati, l’intera catena di attacco descritta da Onapsis semplicemente non può iniziare, indipendentemente dal patch level installato. La seconda è che il monitoraggio dei log applicativi, non solo di quelli di rete, diventa indispensabile quando l’attacco sfrutta un canale di comunicazione legittimo: un firewall perimetrale non vede nulla di anomalo in un pacchetto diretto alla normale porta SAP GUI.
La terza lezione riguarda la governance dei cicli di patching: molte aziende pianificano gli aggiornamenti SAP su base trimestrale per limitare l’impatto sulle operazioni di business, ma una falla con queste caratteristiche dimostra la necessità di un processo di eccezione rapido per gli aggiornamenti classificati come critici, capace di comprimere i tempi da settimane a giorni quando il punteggio CVSS supera una soglia predefinita, per esempio 9.0. Un riferimento europeo utile in questo senso resta ENISA, l’agenzia dell’Unione per la cybersicurezza, che pubblica periodicamente linee guida sulla gestione delle vulnerabilità critiche nei sistemi infrastrutturali.
Domande frequenti su CVE-2026-58240 e S4GET
Cos’è esattamente CVE-2026-58240?
È una vulnerabilità critica, CVSS 9.8, che riguarda il Message Server di SAP NetWeaver e che permette a un attaccante remoto privo di credenziali di registrarsi come componente fidato nel cluster SAP, aprendo la strada all’esecuzione di codice arbitrario. Il dettaglio tecnico completo è consultabile sulla scheda NVD della vulnerabilità.
Quali versioni SAP sono vulnerabili?
Le linee kernel 9.16, 9.18, 9.19 e 9.20, che comprendono SAP S/4HANA 2025 e S/4HANA Cloud Private Edition, oltre a eventuali altri prodotti basati su tecnologia ABAP migrati sugli stessi kernel.
Esiste già una patch disponibile?
Sì, SAP l’ha rilasciata l’8 settembre 2026 tramite la Security Note 3759472, con patch level minimi differenti per ciascuna linea kernel coinvolta. La documentazione ufficiale sulle security note è disponibile su SAP Support Portal.
La vulnerabilità è già stata sfruttata attivamente?
Al 15 settembre 2026 non risultano evidenze pubbliche di sfruttamento attivo confermato, né l’inserimento nel catalogo CISA KEV, ma gli analisti considerano probabile una rapida armatura dato che l’exploit non richiede credenziali.
Come posso verificare se il mio sistema SAP è esposto?
Occorre controllare il kernel e il patch level di ogni istanza SAP, verificare se la porta del Message Server (fascia 36NN) è raggiungibile da reti non fidate, e applicare la Security Note 3759472 prioritariamente sui sistemi più esposti.
S4GET è collegata alla falla di SAP Commerce Cloud vista in precedenza?
No, sono due vulnerabilità distinte con CVE diversi: S4GET colpisce il Message Server di NetWeaver, mentre la falla precedente in Commerce Cloud (CVE-2026-58231, CVSS 10.0) riguardava il modulo e-commerce e aveva esposto circa 4.200 istanze pubblicamente raggiungibili.
Basta la sola patch per essere protetti?
La patch è la misura risolutiva definitiva, ma Onapsis raccomanda anche di limitare l’esposizione di rete del Message Server e di rivedere le configurazioni di trust del cluster come misure aggiuntive, soprattutto per i sistemi che non possono essere aggiornati immediatamente.
Le aziende italiane devono segnalare l’incidente in base al NIS2?
Se un’azienda rientra tra i soggetti obbligati dal NIS2 e subisce uno sfruttamento effettivo di questa vulnerabilità con impatto sui servizi, scatta l’obbligo di notifica preliminare all’ACN entro 24 ore dalla scoperta dell’incidente significativo, indipendentemente dal fatto che la falla sia già nota pubblicamente.
