Nel Patch Day SAP di settembre 2026, pubblicato l'8 settembre insieme a ventidue note di sicurezza, ce n'è una che merita di essere trattata a parte. CVE-2026-44756, punteggio CVSS 10.0, nota SAP 3747649, è una corruzione della memoria nel modulo Extended Passport (EPP) Processing del kernel SAP. La ricerca è degli Onapsis Research Labs, che l'hanno battezzata OVERPASS.
La meccanica è semplice da descrivere e sgradevole da leggere: durante la deserializzazione dei dati EPP manca la validazione dei limiti sui campi di lunghezza forniti dall'esterno. Un attaccante non autenticato invia una richiesta di rete con un header EPP malformato e ottiene un comportamento indefinito della memoria.
Perché una 10.0 e non una 9.8
Il punteggio massimo non è retorica. Tre elementi si sommano.
Il primo è quando la falla viene raggiunta. L'Extended Passport è il meccanismo di tracing di SAP e viene elaborato all'apertura di ogni nuova sessione, dal client al server. Come osservano gli Onapsis Research Labs, tutti i controlli SAP che decidono chi può fare che cosa — blocchi utente, ruoli, oggetti di autorizzazione, policy di logon — vengono valutati in un momento successivo rispetto al punto in cui il difetto viene toccato. Nessuno di questi controlli si trova sulla strada dell'attaccante.
Il secondo è da dove si arriva. La funzionalità vulnerabile è raggiungibile da almeno tre vettori distinti: richieste web, protocollo SAP GUI e connessioni RFC. Nessuno dei tre richiede credenziali. Questo significa, molto concretamente, che non esiste un singolo controllo di rete che azzeri il rischio: chiudere una porta lascia aperte le altre due.
Il terzo è con quali privilegi si esegue. I componenti interessati girano sotto l'account di sistema operativo proprietario dell'installazione SAP. Eseguire codice in quel contesto equivale a possedere il sistema SAP: comandi arbitrari sull'host, recupero delle credenziali del database e degli hash delle password, lettura delle sessioni attive degli utenti collegati, modifica di dati, configurazioni e binari SAP.
Il difetto risiede nel codice del kernel, quindi la superficie è vastissima: S/4HANA, ERP, Business Suite (ECC), NetWeaver, Web Dispatcher, BW/4HANA, Enterprise Portal, PI/PO, Solution Manager. La nota fornisce la correzione per i kernel ABAP e Java e per SAP Web Dispatcher versione 9.16; le altre versioni di Web Dispatcher e il Web Dispatcher incluso in SAP HANA Extended Application Services non risultano interessati. Al momento né SAP né Onapsis segnalano indicatori di sfruttamento in rete.
S4GET: la seconda che conta davvero
Nello stesso Patch Day compare CVE-2026-58240 (CVSS 9.8, nota 3759472), che Onapsis chiama S4GET. Il Message Server di SAP NetWeaver — il componente che smista le richieste di logon della SAP GUI all'interno di un cluster — non verifica in modo sufficiente l'autenticità dei componenti applicativi interni durante la registrazione. Un attaccante non autenticato con accesso di rete può quindi registrarsi come nodo fidato dentro il cluster SAP e da lì compiere azioni non autorizzate.
Il dettaglio che cambia la priorità: la falla è presente su tutta la famiglia del kernel moderno (9.16, 9.18, 9.19, 9.20). Tradotto, ogni sistema S/4HANA 2025 e ogni release precedente che sia già stata portata su uno di quei kernel è interessata per costruzione.
Completano il quadro delle note HotNews la CVE-2026-76969 (CVSS 9.4, divulgazione di credenziali nelle applicazioni multitenant che usano il Cloud Application Programming Model), la CVE-2026-66768 (CVSS 9.0, controllo degli accessi improprio in SAP GUI for Java) e l'aggiornamento della nota sulla CVE-2026-58231 in Commerce Cloud, già trattata su queste pagine ad agosto: l'aggiornamento chiarisce che gli ambienti Commerce Cloud non modificati non sono esposti per impostazione predefinita.
Cosa significa per le aziende italiane
SAP è il sistema nervoso di buona parte del manifatturiero italiano, della grande distribuzione, della farmaceutica e dell'alimentare. È anche il posto dove l'esposizione reale è quasi sempre peggiore di quella percepita, e vale la pena spiegare perché.
Il panorama SAP tipico di un gruppo industriale italiano non è un sistema: sono sviluppo, qualità e produzione, più un Solution Manager, più uno o più satelliti, tenuti insieme da una ragnatela di connessioni RFC che nessuno ha più rivisto dalla migrazione. Quelle connessioni sono storicamente il punto meno segmentato dell'intero perimetro, perché segmentarle romperebbe i trasporti e le interfacce. OVERPASS si raggiunge anche via RFC. Chi conta sulla segmentazione di rete come misura compensativa in attesa della finestra di manutenzione dovrebbe verificare, non assumere.
Il secondo punto riguarda chi ha un progetto S/4HANA in corso, ed è la maggioranza delle grandi imprese italiane in questa fase, spinte dalla scadenza del supporto ECC. Un progetto in corso significa kernel recenti, ed è esattamente la condizione che rende un sistema vulnerabile a S4GET. Il paradosso è concreto: l'ambiente modernizzato è più esposto di quello legacy che si sta dismettendo.
Terzo: essere in RISE with SAP non chiude automaticamente la questione. Il modello di responsabilità condivisa distribuisce i compiti in modo diverso a seconda del contratto e dello scenario di deployment, e l'aggiornamento del kernel non ricade sempre dalla parte del fornitore. È una domanda da porre per iscritto al provider adesso, con riferimento esplicito alle note 3747649 e 3759472, e da conservare nella documentazione.
Sul piano dei tempi, il precedente più utile è quello della CVE-2025-31324 in NetWeaver Visual Composer: nel 2025 è passata da "nessuno sfruttamento osservato" a campagne di massa nel giro di poche settimane, con più gruppi criminali e statuali a sfruttarla. L'assenza attuale di sfruttamento per OVERPASS non è una rassicurazione, è una finestra.
Sul piano normativo, il manifatturiero, l'alimentare e la chimica rientrano nell'allegato II del d.lgs. 138/2024, che recepisce NIS2, mentre energia e sanità sono nell'allegato I. Per questi soggetti una compromissione del kernel SAP non è un incidente IT circoscritto: è la compromissione del sistema che regge ordini, produzione e fatturazione, quindi con ogni probabilità un incidente significativo, con notifica preliminare al CSIRT Italia entro 24 ore e notifica completa entro 72. In parallelo, poiché un sistema SAP contiene dati di dipendenti, clienti e fornitori, scatta il binario GDPR: valutazione ai sensi dell'art. 33 e, se ricorrono i presupposti, notifica al Garante entro 72 ore. Sono due procedimenti distinti, con due autorità e due scadenze, e conviene averli scritti prima di doverli eseguire di corsa.
Cosa fare subito
- Applicare la nota SAP 3747649 su tutti i sistemi con kernel ABAP o Java, e su SAP Web Dispatcher 9.16. È una correzione a livello di kernel: va pianificato un riavvio.
- Applicare la nota 3759472 (S4GET) su tutti i sistemi con kernel 9.16, 9.18, 9.19 o 9.20, a partire dagli S/4HANA 2025.
- Censire immediatamente quali sistemi SAP siano raggiungibili da reti non fidate, e su quali porte: HTTP/HTTPS dell'ICM, porta della SAP GUI, gateway RFC, Message Server. L'esposizione del Message Server verso l'esterno non ha quasi mai una giustificazione.
- Rivedere l'elenco delle destinazioni RFC e delle relazioni di fiducia fra sistemi, con particolare attenzione a quelle che partono da sviluppo o qualità verso la produzione.
- Applicare le altre note HotNews: 3798315 (CAP), 3781729 (SAP GUI for Java) e l'aggiornamento 3771065 per Commerce Cloud, verificando il proprio setup con la FAQ 3775386.
- Per i clienti RISE with SAP, ottenere per iscritto dal provider chi applica queste note e in quale finestra.
- Attivare o verificare la registrazione dei log del Security Audit Log e del gateway, perché senza di essi un'eventuale compromissione del kernel non lascia traccia utilizzabile in fase di risposta.