FreeScout: la vulnerabilità di Polycast che abbiamo segnalato

Quando apri un ticket in FreeScout e un collega sta guardando la stessa conversazione, compare il suo nome in alto. È una funzione piccola e comoda: evita che due persone rispondano allo stesso cliente nello stesso momento. Per farla funzionare il browser di ogni agente invia regolarmente al server una richiesta che dice, in sostanza, "sto guardando la conversazione numero X". Il server non verificava che quella conversazione esistesse, né che l'utente avesse il diritto di vederla. Accettava semplicemente il valore e lo salvava.

È il difetto descritto nell'advisory GHSA-vcgj-6qfr-7qr6, pubblicato il 17 ottobre 2026 e corretto in FreeScout 1.8.248. L'abbiamo segnalato noi: la scoperta è di Liam Giannini (Liam-G su GitHub) del gruppo di ricerca sulla sicurezza di Webcracy. Ringraziamo i maintainer di FreeScout, che hanno pubblicato la correzione nella release successiva.

Cosa succedeva dietro l'indicatore "sta visualizzando"

FreeScout è un helpdesk open source in PHP, basato su Laravel, usato da molte aziende come alternativa self-hosted a servizi come Help Scout o Zendesk. Gli aggiornamenti in tempo reale passano da un componente chiamato Polycast, che riceve le richieste periodiche dei browser sull'endpoint POST /polycast/receive.

Ogni richiesta finiva in un metodo, processConvView(), che leggeva il campo data[conversation_id] e lo usava così com'era. Nessun controllo che fosse un numero, nessun limite di lunghezza, nessuna verifica dei permessi. La ricerca della conversazione nel database avveniva solo in alcuni casi, e anche quando falliva il valore non veniva scartato. Per ogni identificativo nuovo il server creava una voce in cache dedicata e aggiungeva lo stesso identificativo a un unico array condiviso, conv_view, che contiene le visualizzazioni attive di tutta l'installazione.

Il dettaglio che trasforma un controllo mancante in un problema di disponibilità è proprio quell'array. Viene letto per intero, modificato e riscritto per intero a ogni richiesta, con una durata di venti minuti. Se qualcuno ci infila migliaia di identificativi inventati, ogni scrittura successiva diventa più pesante, e questo vale anche per le richieste legittime degli altri agenti, che usano lo stesso oggetto. A peggiorare le cose c'è un comando pianificato, freescout:check-conv-viewers, che gira ogni minuto: scorre tutte le voci, e per ogni voce scaduta rimuove una chiave dalla cache e genera un evento in tempo reale. Più voci false, più lavoro sul database e sul sistema di broadcast. L'endpoint, inoltre, non aveva un limite di frequenza specifico.

Il risultato è che un singolo account agente, anche senza privilegi di amministrazione, poteva rallentare l'helpdesk per tutti: richieste più lente, worker occupati, pressione su Redis o sul backend di cache configurato, attività pianificate in ritardo. Non c'è accesso a dati altrui né modifica di contenuti. GitHub classifica il problema come gravità moderata, CVSS 3.1 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), nella categoria CWE-400, consumo incontrollato di risorse. Al momento della scrittura non risulta ancora un CVE assegnato.

Perché "serve essere autenticati" non basta

Sarebbe facile liquidare la cosa dicendo che l'attaccante deve avere un account. In un helpdesk, però, gli account sono tanti e cambiano spesso: agenti stagionali, collaboratori esterni, fornitori a cui si apre una casella condivisa, credenziali riutilizzate da qualche altro servizio violato. Il controllo di accesso di Polycast verificava che l'utente fosse loggato e che potesse ascoltare il canale richiesto. Non diceva nulla sul contenuto della richiesta. Il confine giusto non è "l'utente è autenticato", ma "l'utente può vedere questa specifica conversazione".

C'è anche un precedente sullo stesso endpoint. A luglio era stato pubblicato GHSA-gh3r-jh6q-wrvj (CVE-2026-62856), una falla di gravità alta, corretta nella 1.8.226, che usava i caratteri jolly di una query LIKE nella selezione dei canali per leggere notifiche di altri utenti. Il nostro caso è diverso: il campo vulnerabile è data[conversation_id] e l'effetto riguarda le risorse, non la riservatezza. Ma il fatto che lo stesso punto d'ingresso abbia prodotto due advisory in pochi mesi dice qualcosa. Gli endpoint di polling, quelli che il browser chiama ogni pochi secondi senza che nessuno ci pensi, tendono a ricevere meno attenzione delle schermate che l'utente vede.

Come l'abbiamo verificato, e cosa non abbiamo fatto

Il problema è emerso da una revisione del codice sorgente di FreeScout 1.8.247 (commit 9d11ff0), seguendo il percorso del dato dall'endpoint fino al comando di pulizia. Nella segnalazione abbiamo descritto una procedura di verifica limitata, da eseguire in un ambiente di laboratorio isolato: accedere come agente normale, inviare poche richieste con identificativi inesistenti, osservare la cache e la crescita dell'oggetto conv_view, poi lasciare girare il comando pianificato. Qualche decina o centinaio di voci basta a vedere il fenomeno. Non abbiamo generato traffico di carico né portato al limite alcuna installazione, tantomeno sistemi in produzione o di terzi. Per un problema di disponibilità, dimostrare la crescita è sufficiente; far cadere un servizio non aggiunge informazioni utili e può fare danni veri.

La correzione nella 1.8.248

Le note di rilascio della versione 1.8.248 indicano la sanificazione dell'identificativo in processConvView(). Nel codice corretto il valore viene accettato solo se è un intero positivo di al massimo dieci cifre, l'utente deve essere autenticato, e prima di qualsiasi scrittura in cache viene verificato che possa effettivamente vedere la conversazione. Una richiesta con un identificativo falso, o relativo a una conversazione non accessibile, non lascia più traccia.

Nella segnalazione avevamo proposto anche altre misure: un limite di frequenza dedicato per l'endpoint Polycast, un tetto al numero di visualizzazioni attive per utente e per conversazione, e soprattutto la sostituzione dell'array globale con una struttura per conversazione, in modo da non riscrivere tutto a ogni richiesta. La validazione con il controllo dei permessi chiude il percorso di attacco descritto nell'advisory. Le altre misure sono difese in profondità, utili contro abusi futuri, e restano una scelta progettuale dei maintainer.

La stessa release corregge altri tre advisory: GHSA-w3jr-fphw-whgv, sulle conversazioni precedenti visibili a utenti che dovrebbero vedere solo quelle assegnate; GHSA-c8rg-2r2h-5vgc, sulla creazione di più sessioni riscattando lo stesso invito in parallelo; e GHSA-cxf4-7mrp-vvpr, un problema di caratteri di controllo nella dipendenza league/flysystem. Già questo basta per non rimandare l'aggiornamento.

Cosa fare se usate FreeScout

Se la vostra installazione è precedente alla 1.8.248, aggiornatela. L'advisory non indica soluzioni temporanee, e disattivare Polycast vorrebbe dire perdere gli aggiornamenti in tempo reale su cui l'interfaccia fa affidamento. Prima dell'aggiornamento conviene fare un backup del database e della cartella dei moduli: molti problemi dopo un upgrade di FreeScout vengono da moduli di terze parti non allineati, più che dal core.

Se avete notato rallentamenti inspiegabili dell'helpdesk, vale la pena guardare anche la dimensione della voce conv_view nella cache. Un valore con molte più voci di quante siano le conversazioni realmente aperte dagli agenti è un segnale da approfondire. Dopo l'aggiornamento, comunque, le voci esistenti scadono da sole entro venti minuti.

E se FreeScout gira su un server che nessuno controlla da mesi, il problema probabilmente non è solo questo advisory. Un helpdesk contiene le email dei clienti, gli allegati, a volte dati personali delicati: merita la stessa manutenzione del sito aziendale, se non di più.

Perché facciamo ricerca su software open source

Molti dei nostri clienti usano strumenti open source self-hosted, e li consigliamo spesso: niente canoni per utente, dati sul proprio server, codice che si può leggere. Ma "si può leggere" non significa che qualcuno lo stia leggendo. Dedicare parte del nostro tempo alla revisione dei progetti che installiamo, e segnalare quello che troviamo in modo responsabile ai maintainer, è il modo più concreto che conosciamo per restituire qualcosa a quei progetti. E per sapere davvero cosa stiamo mettendo in produzione.

Se volete un controllo simile sul vostro helpdesk, sul gestionale o su un'applicazione sviluppata su misura, ne parliamo volentieri. Il nostro lavoro di penetration testing parte proprio da qui: leggere il codice e la configurazione, capire dove un dato non viene controllato, e dirvi con precisione cosa abbiamo verificato e cosa no.

Parliamo della sicurezza delle vostre applicazioni↗