SEPPMail: 7 CVE critiche aprono tutta la posta aziendale
Sette falle nel gateway email SEPPMail, con CVSS fino a 10.0, permettono RCE non autenticato e lettura totale del traffico aziendale. Patch disponibili.
Contenuto
Il 19 maggio 2026 InfoGuard Labs ha divulgato sette vulnerabilità critiche nel SEPPMail Secure E-Mail Gateway, appliance posizionata a protezione del perimetro email delle aziende. La più grave, con punteggio CVSS 10.0, consente a un attaccante remoto e non autenticato di sovrascrivere file di sistema e ottenere esecuzione di codice arbitrario. Il risultato: lettura completa del traffico email e potenziale ingresso nella rete interna.
- Sette CVE certificate nel SEPPMail Secure E-Mail Gateway, con punteggi CVSS tra 9.2 e 10.0, permettono RCE non autenticato
- La path traversal CVE-2026-2743 sfrutta il feature Large File Transfer per scrivere su /etc/syslog.conf e ottenere shell tramite log rotation
- CVE-2026-44128 (CVSS 9.3) inserisce il parametro utente upldd direttamente in una chiamata Perl eval() senza sanificazione
- Le patch sono disponibili nelle versioni 15.0.2.1, 15.0.3 e 15.0.4 a seconda della vulnerabilità specifica
Il meccanismo della shell: quando la log rotation diventa un'arma
Il cuore dell'attacco più grave risiede in un'abitudine sistemistica apparentemente innocua: la rotazione dei log. InfoGuard Labs ha dimostrato che la vulnerabilità di path traversal nel modulo Large File Transfer permette di scrivere file arbitrari con i privilegi dell'utente nobody. L'obiettivo scelto è /etc/syslog.conf: una volta compromesso, è sufficiente attendere l'esecuzione di newsyslog via cron.
Lo strumento, che gestisce la rotazione automatica dei file di log, invia il segnale SIGHUP al demone syslogd per forzarne il reload della configurazione. Se il file syslog.conf è stato manipolato dall'attaccante, quel SIGHUP innocuo diventa il grilletto per una reverse shell. L'intervallo di attesa è definito: newsyslog gira ogni circa 15 minuti. Nessuna autenticazione, nessuna interazione utente, nessun exploit complesso contro mitigazioni moderne.
La scelta di /etc/syslog.conf non è casuale. Il file è leggibile e scrivibile nel contesto del processo compromesso, e il reload è un comportamento standard del sistema operativo sottostante. L'attaccante non deve introdurre codice eseguibile nuovo, ma semplicemente dirottare un meccanismo esistente. È un esempio classico di trust abuse: il sistema si fida della propria infrastruttura di logging, e quella fiducia viene convertita in ponte di accesso.
Eval injection e deserialization: tre strade per lo stesso obiettivo
Parallelamente alla catena syslog, i ricercatori hanno identificato CVE-2026-44128, una eval injection nel componente /api.app/template. Il parametro upldd, fornito dall'utente, viene passato direttamente a una chiamata Perl eval() senza alcuna sanificazione. In linguaggi dinamici come Perl, eval() esegue il contenuto come codice: l'intero interprete diviene quindi esecutore di payload arbitrari. Il punteggio CVSS 9.3 riflette sia la semplicità dell'exploit che l'impatto completo sulla disponibilità e integrità del sistema.
Una tertra via, CVE-2026-44126 con CVSS 9.2, sfrutta la deserialization di oggetti non attendibili. Quando un'applicazione ricostruisce oggetti da stream di dati esterni senza validazione, il codice malevolo può essere eseguito nel contesto del processo deserializzatore. Anche in questo caso, l'autenticazione non è richiesta. Tre meccanismi distinti — path traversal, eval injection, deserialization — convergono sul medesimo risultato: Remote Code Execution con privilegi elevati sull'appliance di sicurezza.
Il dato che colpisce non è la complessità individuale di ogni falla, ma la loro combinazione in un singolo prodotto posizionato come controllo di sicurezza. Il SEPPMail Gateway è progettato per ispezionare, filtrare e proteggere il traffico email. La sua compromissione non è equivalente a quella di un server applicativo qualsiasi: trasforma il punto di osservazione difensivo in punto di osservazione offensivo, con visibilità su comunicazioni presumibilmente riservate.
Il traffico email come collateral damage inevitabile
"These vulnerabilities could have been exploited to read all mail traffic or as an entry vector into the internal network" — InfoGuard Labs researchers Dario Weiss, Manuel Feifel, and Olivier Becker
La citazione dei ricercatori definisce il perimetro del danno senza eufemismi. L'appliance SEPPMail, per funzionare, termina le connessioni SMTP e SMTPS, decifra o ispeziona il traffico, applica policy di sicurezza e quindi ritrasmette verso i server interni. Questa architettura di man-in-the-middle legittimo implica che chi controlla l'appliance controlla il contenuto, i metadati e gli allegati dell'intera corrispondenza aziendale.
La compromissione bypassa implicitamente le garanzie di cifratura end-to-end. Se due utenti si scambiano email cifrate con S/MIME o PGP, il gateway le decifra per l'ispezione antimalware e antispam. I materiali in chiaro transitano quindi in memoria e, potenzialmente, in log sull'appliance. Un attaccante con RCE può intercettare questi dati al volo, esfiltrarli, o instaurare una presenza persistente che continui a raccogliere informazioni nel tempo. Non è richiesto alcun accesso ai client o ai server finali: il bottleneck strutturale del gateway diviene il bottleneck informativo dell'attaccante.
Il rischio di movimento laterale, menzionato esplicitamente dai ricercatori, completa il quadro. L'appliance risiede tipicamente in una DMZ o in una zona di rete con privilegi di comunicazione verso sistemi interni. Una shell sull'host può essere sfruttata per scansioni, pivoting e accesso a segmenti altrimenti isolati. Il gateway email, elemento di trust architetturale, si converte in ponte di violazione.
Cosa fare adesso
Le patch sono disponibili ma distribuite su versioni diverse: 15.0.2.1 per CVE-2026-44128, 15.0.3 per CVE-2026-44126, 15.0.4 per le rimanenti vulnerabilità inclusa la path traversal CVE-2026-2743. Gli operatori devono verificare la propria versione installata e pianificare l'aggiornamento con priorità critica, data l'assenza di requisiti di autenticazione per l'exploit.
Gli endpoint /api.app/template, /api.app/attachment/preview e le funzionalità GINA UI coinvolte nelle falle dovrebbero essere limitati via firewall a sorgenti autorizzate, dove l'architettura di rete lo consente, fino all'applicazione della patch. Questa mitigazione non elimina il rischio ma riduce la superficie di attacco.
I team di sicurezza devono controllare i log di accesso all'appliance per connessioni anomale, modifiche a /etc/syslog.conf o esecuzioni di processi Perl non previsti. La presenza di newsyslog nei cron job è normale; la sua associazione a file di configurazione alterati è indicatore di compromissione.
Infine, va valutata la segmentazione della rete attorno al gateway. Se l'appliance dispone di connettività verso sistemi interni oltre quanto strettamente necessario, la compromissione ha raggio d'azione maggiore. La restrizione dei flussi consentiti è mitigazione architetturale indipendente dalla patch.
Non è confermato che le vulnerabilità siano state sfruttate attivamente prima della disclosure, ma l'assenza di requisiti di autenticazione e la semplicità degli exploit — specialmente la catena syslog/SIGHUP — rendono l'exploitation tecnicamente banale per attori con capacità di base.
Perché queste falle pesano più di altre
La gravità relativa di queste sette CVE risiede nella posizione strutturale del prodotto colpito. Non si tratta di una vulnerabilità in un'applicazione aziendale tra molte, ma nel componente che le altre applicazioni e gli utenti assumono come affidabile. Il SEPPMail Gateway è, per design, un man-in-the-middle autorizzato: la sua sicurezza è presupposto della sicurezza percepita dell'intero flusso di comunicazione.
Quando questo presupposto fallisce, l'effetto è duplice. Primo, la violazione è invisibile ai comunicanti: mittente e destinatario credono di scambiarsi messaggi protetti dall'infrastruttura, mentre l'infrastruttura stessa è compromessa. Secondo, la persistenza è facilitata: un gateway email è componente critica, raramente spento o sostituito, e i suoi processi sono attesi come normali dall'ambiente di monitoraggio.
La lezione è vecchia ma qui si manifesta con crudezza: la sicurezza di un sistema è tanto forte quanto la sicurezza dei suoi controlli. Input validation insufficiente in un modulo di file transfer, mancata sanificazione in un parametro template, assenza di autorizzazione su endpoint amministrativi — errori classici, quasi banali — si sommano in un appliance di sicurezza a produrre il risultato opposto alla sua missione. Non protezione, ma esposizione totale.
Fonti
- https://unit42.paloaltonetworks.com/captive-portal-zero-day/
- https://blog.talosintelligence.com/insights-into-the-clustering-and-reuse-of-phone-numbers-in-scam-emails/
- https://thehackernews.com/2026/05/funnel-builder-flaw-under-active.html
- https://www.helpnetsecurity.com/2026/05/19/babel-street-insights-investigator/
- https://thehackernews.com/2026/05/seppmail-secure-e-mail-gateway.html
- https://cyberscoop.com/cisco-sd-wan-zero-day-exploited/
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://unit42.paloaltonetworks.com/captive-portal-zero-day/
- https://blog.talosintelligence.com/insights-into-the-clustering-and-reuse-of-phone-numbers-in-scam-emails/
- https://thehackernews.com/2026/05/funnel-builder-flaw-under-active.html
- https://www.helpnetsecurity.com/2026/05/19/babel-street-insights-investigator/
- https://thehackernews.com/2026/05/seppmail-secure-e-mail-gateway.html
- https://cyberscoop.com/cisco-sd-wan-zero-day-exploited/