Roundcube Webmail a rischio: CVE-2025-49113, deserializzazione PHP e remote code execution post-auth

Ultimo aggiornamento: 26 febbraio 2026

La CVE-2025-49113 è una vulnerabilità critica che interessa Roundcube Webmail e consente remote code execution a utenti autenticati tramite un difetto di validazione del parametro _from, con conseguente PHP Object Deserialization. Anche se il requisito di autenticazione può far pensare a un rischio più contenuto, in ambienti reali questa lettura è spesso fuorviante.

Roundcube è frequentemente esposto su internet, utilizzato in contesti shared hosting, provider mail, pannelli di amministrazione e infrastrutture dove la separazione tra utenza “semplice” e impatto sistemico non è sempre netta. In questo scenario, una vulnerabilità post-auth può diventare rapidamente un punto di compromissione reale quando un attaccante dispone già di credenziali deboli, sessioni sottratte, accessi ottenuti tramite phishing o account di basso privilegio già compromessi.

Perché il requisito di autenticazione non abbassa davvero il rischio

Uno degli errori più comuni nella gestione delle vulnerabilità è sottovalutare i bug post-auth. In teoria, l’attaccante deve avere un accesso valido. In pratica, però, le credenziali mail sono tra gli asset più frequentemente esposti, riutilizzati o intercettati, e spesso un account utente apparentemente marginale è sufficiente per avviare una catena di compromissione molto più seria.

Nel caso di Roundcube, il problema è ancora più delicato perché il servizio vive spesso su server che ospitano più tenant, domini, configurazioni PHP e componenti condivisi. Questo significa che una RCE dentro il perimetro webmail non è solo un incidente applicativo: può trasformarsi in un accesso utile per persistenza, raccolta dati, abuso del contesto applicativo e, in certi casi, movimento verso altri elementi della piattaforma.

La debolezza tecnica: deserializzazione di dati non fidati

La deserializzazione insicura è una classe di vulnerabilità nota e particolarmente pericolosa perché, se combinata con oggetti o gadget adeguati, può trasformare input controllabili in esecuzione di codice. Qui il punto non è solo l’errore di validazione, ma il fatto che il flusso vulnerabile può portare il runtime PHP a gestire dati in modo pericoloso, aprendo la strada a effetti ben superiori al semplice malfunzionamento dell’applicazione.

Questa è la ragione per cui bug apparentemente “banali” nei parametri URL non vanno letti come difetti superficiali. Se il sink finale è una deserializzazione insicura, il profilo di rischio cambia drasticamente.

Impatto reale in ambienti esposti

In un ambiente di posta esposto su internet, una vulnerabilità come questa può essere sfruttata in più modi operativi:

• uso di credenziali rubate o riutilizzate per ottenere accesso iniziale;
• esecuzione di codice nel contesto dell’applicazione webmail;
• persistenza sul server o nel contesto PHP;
• raccolta di dati sensibili da caselle, configurazioni o file temporanei;
• espansione dell’accesso verso altri componenti ospitati sullo stesso host.

Il rischio aumenta ulteriormente dove Roundcube è integrato in stack non pienamente segmentati, con permessi eccessivi, plugin legacy, configurazioni PHP permissive o scarsa visibilità sui log applicativi.

Cosa controllare subito

Chi gestisce Roundcube dovrebbe verificare immediatamente:

• la versione installata e la presenza di release vulnerabili;
• accessi sospetti a caselle con pattern anomali o geografie insolite;
• richieste anomale verso percorsi legati a impostazioni e upload;
• errori PHP, eccezioni o log applicativi incompatibili con il traffico normale;
• eventuali file inattesi, modifiche a componenti web o indicatori di persistenza;
• attività successive sul server che suggeriscano post-exploitation.

Il punto non è solo chiudere la vulnerabilità, ma capire se sia già stata sfruttata prima della correzione. In presenza di un servizio internet-facing e di utenze compromettibili, questa seconda verifica è essenziale.

Remediation corretta

La risposta matura richiede almeno quattro azioni:

• aggiornare immediatamente Roundcube alle versioni corrette;
• riesaminare gli account con accessi sospetti o credenziali deboli;
• verificare la presenza di plugin, estensioni o personalizzazioni non aggiornate;
• condurre un controllo di integrità sull’host e sul codice applicativo.

Nei casi più esposti, ha senso considerare anche reset delle password, review delle sessioni attive e verifica di eventuali residui di compromissione nel contesto PHP o nel filesystem dell’applicazione.

Conclusione

La CVE-2025-49113 è un esempio perfetto di vulnerabilità che molti rischiano di sottostimare perché non è completamente pre-auth. Ma quando il bersaglio è una webmail esposta, il requisito di autenticazione non basta a rendere il problema secondario. Se le credenziali sono recuperabili, intercettabili o già compromesse, la distanza tra accesso iniziale e impatto reale diventa molto corta.

In questi casi, la postura giusta non è pensare “serve login, quindi è meno urgente”. La postura giusta è chiedersi quanto facilmente quel login possa essere ottenuto e quanto danno possa fare un attaccante una volta dentro. Ed è proprio qui che questa vulnerabilità diventa seriamente pericolosa.