Il modulo che muove i pagamenti, preso senza un login: CVE-2026-46817 su Oracle E-Business Suite

Il posto dove escono i soldi

Dentro Oracle E-Business Suite, la costellazione di applicazioni che gestisce la finanza di moltissime grandi organizzazioni, Oracle Payments è il modulo che si occupa di una cosa sola: far uscire ed entrare i pagamenti. Centralizza il modo in cui le applicazioni contabili dialogano con banche e circuiti di carte, e per farlo maneggia le credenziali dei sistemi bancari, le chiavi di cifratura, le API dei processori di pagamento. Non è un servizio periferico: è il punto in cui l'azienda tocca il denaro.

Il 15 luglio 2026 CISA ha aggiunto CVE-2026-46817 al catalogo delle vulnerabilità note come sfruttate. È un difetto da CVSS 9.8 in Oracle Payments che consente a un attaccante non autenticato, con il solo accesso HTTP alla console, di compromettere e prendere il controllo del modulo. Nessun login, nessun token, nessun account: la richiesta arriva e viene servita.

1. Fine maggio 2026
   Patch

   Oracle corregge la falla nel Critical Patch Update di maggio.

2. 27 giugno 2026
   Primo sfruttamento

   Gli honeypot di Defused registrano la prima esecuzione in-the-wild, prima di qualunque PoC pubblico.

3. 15 luglio 2026
   exploitation

   CISA aggiunge CVE-2026-46817 al catalogo KEV.

4. 18 luglio 2026
   Scadenza

   Data limite imposta da CISA alle agenzie federali per la remediation.

«Non autenticato» non è un lucchetto scassinato

Il dettaglio che rende questa falla peggiore della media non è il punteggio — di CVSS 9.8 ne escono a decine — ma dove manca il controllo. Secondo l'analisi di Defused sull'attività osservata, l'exploit colpisce l'endpoint ibytransmit del componente File Transmission di Oracle Payments e invoca direttamente una funzione Java interna, dirottandola a leggere un file dal server. Nell'episodio registrato, il file letto era /etc/passwd: la classica prova di lettura arbitraria, innocua in sé, che serve a dimostrare che il meccanismo funziona.

Il punto è che quella funzione interna non era pensata per essere raggiunta da fuori. L'endpoint la chiama senza che nessuno, lungo il percorso, verifichi chi sta chiedendo. La descrizione di Oracle non parla di un singolo bug ma di tre debolezze che convivono: gestione impropria dei privilegi, autenticazione impropria e assenza di autenticazione per una funzione critica. «Non autenticato», qui, non descrive un lucchetto scassinato: descrive un lucchetto che su quella porta non è mai stato montato.

1. 01
   Richiesta HTTP

   POST verso /OA_HTML/ibytransmit, senza credenziali
2. 02
   Funzione Java interna

   l'endpoint la invoca direttamente, nessun controllo di accesso
3. 03
   Lettura di file dal server

   /etc/passwd nella prova; poi config, chiavi, API dei pagamenti
4. 04
   Compromissione del modulo

   dalla lettura arbitraria al takeover di Oracle Payments

Dalla lettura di un file al portafoglio

Nell'episodio osservato l'attaccante ha letto /etc/passwd, cioè quasi niente. Ma la stessa tecnica, avverte Defused, raggiunge file ben più sensibili: i file di configurazione con le credenziali del database, le chiavi di cifratura, le API dei processori di pagamento. È qui che la distanza fra «lettura di un file di sistema banale» e «controllo del modulo che muove i pagamenti» si accorcia in fretta — ed è la ragione per cui Oracle descrive come impatto massimo il takeover del modulo, con compromissione di riservatezza, integrità e disponibilità insieme.

Va detto con precisione cosa è stato visto e cosa no. Ciò che Defused ha registrato è una singola sorgente che eseguiva una lettura di file non autenticata contro il componente Payments: una proof-of-concept mirata, non una scansione di massa. Il takeover completo è l'impatto massimo dichiarato da Oracle sulla base della vulnerabilità, non una catena end-to-end osservata e documentata nel traffico reale. La differenza conta: sappiamo che qualcuno ha aperto la porta, non abbiamo un report pubblico che mostri cosa ci sia stato fatto dentro.

Non è la prima volta, ed è questo il punto

Se questa storia suona familiare è perché lo è. Nell'autunno 2025 un'altra falla critica dello stesso prodotto — CVE-2025-61882, anch'essa CVSS 9.8 — è stata sfruttata da attori legati al ransomware Cl0p per furto ed estorsione, con attacchi iniziati già ad agosto; poco dopo è arrivata CVE-2025-61884. All'inizio di luglio 2026 Oracle ha corretto uno zero-day di missing authentication in PeopleSoft (CVE-2026-35273) sfruttato in attacchi di data theft attribuiti a ShinyHunters. Le suite gestionali Oracle, esposte su internet, sono diventate una superficie di accesso iniziale ricorrente.

È la lezione più utile di questo dossier, più del singolo CVE: quando un prodotto colleziona falle critiche non autenticate in meno di un anno, la domanda smette di essere «ho applicato l'ultima patch?» e diventa «questo componente ha davvero bisogno di stare su internet?». Un modulo di pagamenti che dialoga con banche e circuiti non ha alcuna ragione di offrire la propria console al mondo.

Cosa non sappiamo — e va dichiarato

Alcune cose restano aperte, ed è corretto scriverle. L'attribuzione non esiste: nessun attore nominato, nessuna campagna pubblica, e il catalogo KEV riporta l'uso in campagne ransomware come «Unknown». L'unica evidenza di sfruttamento è l'osservazione di Defused su un proprio decoy — fonte singola, per quanto specifica.

Il punteggio è quello del CNA Oracle (9.8): NVD ha ricevuto il record ma non ha ancora pubblicato una propria valutazione né l'enumeration CWE. Il meccanismo tecnico oltre la lettura di file — quale funzione Java, quale percorso porta dal file-read al takeover — non è pubblicamente dettagliato, e questo dossier non entra in dettagli operativi che non servono a difendersi. Infine gli ID ATT&CK in testa — T1190 e T1552.001 — non provengono da un advisory Oracle o CISA: sono una mappatura ragionata di ciò che la falla consente (raggiungere un'applicazione esposta e leggere credenziali dai file), non un dato copiato da una fonte primaria.

Cosa si fa, e subito

La remediation esiste da fine maggio: applicare il Critical Patch Update di maggio 2026 di Oracle chiude la falla sulle versioni 12.2.3–12.2.15. In attesa della finestra di manutenzione, la mitigazione a impatto più alto è la più semplice — le interfacce web di EBS non dovrebbero essere raggiungibili da internet, ma limitate alla rete interna.

Per la caccia retrospettiva, l'indicatore è concreto: richieste POST inattese verso /OA_HTML/ibytransmit nei log del web tier. Chi trova evidenza di compromissione dovrebbe trattare l'istanza come violata, fare un'analisi forense completa e ruotare tutte le credenziali e le chiavi conservate su quell'host — perché è esattamente ciò che quella lettura di file era in grado di raggiungere. La patch ha quasi due mesi: la finestra fra «disponibile» e «sfruttata» si è chiusa in sei settimane, e chi ha guardato solo il calendario delle patch, non la propria esposizione, quella finestra l'ha tenuta aperta.