ProjectSend: i link pubblici che un cliente non doveva vedere

Molti studi, agenzie e piccole aziende scambiano documenti con i clienti attraverso un portale: il cliente carica i suoi file, lo staff li controlla, a volte li condivide con terzi tramite un link pubblico. Chi può creare quel link, e chi può vederlo, è una decisione precisa. In ProjectSend un cliente senza il permesso di pubblicare file non dovrebbe poter distribuire un link pubblico. Eppure, aprendo la pagina di modifica di un proprio file, poteva leggere per intero i link creati dallo staff su quel file, e anche cancellarli.

È il difetto descritto nell'advisory GHSA-g9g5-qxp7-f7v2, pubblicato l'8 novembre 2026 e corretto in ProjectSend 2.8.0. L'abbiamo segnalato noi: la scoperta è di Liam Giannini (Liam-G su GitHub), hacker etico e cofondatore di Webcracy. Ringraziamo i maintainer di ProjectSend, che hanno incluso la correzione nella release successiva alla segnalazione.

Webcracy e la sicurezza informatica

Oltre a sviluppare siti e applicazioni, Webcracy si occupa di sicurezza informatica: penetration test, revisione del codice, analisi delle configurazioni e ricerca sul software open source che usiamo noi e che usano i nostri clienti. Liam lavora come hacker etico: cerca le falle con i metodi di un attaccante, ma per farle chiudere. Le segnala in privato ai maintainer e le rende pubbliche solo quando la correzione è disponibile. È la stessa procedura di divulgazione responsabile seguita per exarch e per FreeScout.

Cosa sono i link pubblici in ProjectSend

ProjectSend è una delle applicazioni open source più popolari e diffuse per condividere file con i clienti dal proprio server: esiste dal 2014, ha oltre 2'000 stelle su GitHub e la sola immagine Docker di LinuxServer.io supera i 4,9 milioni di download. È scritta in PHP, su Laravel. Con un progetto così diffuso, una falla non resta mai un problema di pochi. Ogni file può avere uno o più link pubblici, indirizzi del tipo /s/{token} che chiunque li possieda può aprire senza effettuare l'accesso. Il token funziona come una chiave: chi ha il link entra, senza altre verifiche. Per questo la possibilità di crearne uno è un permesso a parte, upload_public, che l'amministratore può dare o negare a ogni ruolo.

ProjectSend aveva già una regola chiara su chi vede cosa: nel portale, un cliente vede solo i link pubblici che ha creato lui. Se lo staff crea un link su un file caricato dal cliente, ad esempio per mandarlo a un consulente esterno, quel link nella lista dei file del cliente non compare. Il codice applicava questa regola in modo esplicito e c'era perfino un test automatico che la verificava.

Dove la regola non veniva applicata

Il problema stava in due punti che usavano una regola più debole per lo stesso oggetto.

Il primo era l'editor del file. Un cliente con il permesso edit_files può modificare i file che ha caricato. Quando apriva la pagina di modifica, il server controllava giustamente che potesse modificare quel file, ma poi inviava al browser tutti i link pubblici collegati, senza filtrare per autore. Per ogni link c'erano l'indirizzo completo con il token, l'identificativo e l'indirizzo per revocarlo. Bastava guardare i dati della pagina per ottenere il link creato dallo staff.

Il secondo era la revoca. La richiesta che cancella un link controllava di nuovo soltanto il permesso di modifica sul file, non chi avesse creato il link. Il cliente poteva quindi eliminare un link dello staff, e chi lo aveva ricevuto si trovava improvvisamente senza accesso.

In entrambi i casi l'errore è lo stesso, ed è molto comune: confondere il permesso su una risorsa con il permesso su tutto ciò che le è collegato. Poter modificare un file non significa poter gestire ogni link che altri hanno creato su quel file.

Quanto è grave

Niente accesso ai file di altri, niente privilegi da staff: il problema tocca solo i file caricati dal cliente stesso, e serve che lo staff ci abbia creato sopra un link pubblico. Ma dentro quel perimetro saltavano due decisioni dello staff. Un cliente a cui era stato negato il permesso di pubblicare poteva comunque distribuire a chiunque un link pubblico attivo, che apre il file senza accesso. E poteva revocare un link che lo staff aveva dato a terzi, interrompendo una condivisione decisa da altri. L'advisory classifica il problema come gravità moderata, nelle categorie CWE-862, autorizzazione mancante, e CWE-200, esposizione di informazioni sensibili. Nella segnalazione avevamo stimato un CVSS 3.1 di 5.4.

Sono interessate le versioni dalla 2.5.0 alla 2.7.1.

Come l'abbiamo verificato

Il problema è emerso leggendo il codice di ProjectSend 2.7.1 e confrontando le diverse strade che portano agli stessi link: la lista del portale, l'editor del file e la revoca. La lista filtrava per autore, le altre due no.

Per confermarlo, Liam ha scritto quattro test automatici con gli strumenti di test già presenti nel progetto, eseguiti in un container Docker isolato, con un database in memoria e account fittizi. I test verificano che l'editor esponga il link dello staff, che il cliente possa revocarlo, che la lista del portale invece lo nasconda correttamente, e che il link ottenuto funzioni anche senza aver effettuato l'accesso. Due test esistenti hanno fatto da controllo: un cliente senza upload_public non può creare link pubblici, e non può revocare link su file che non sono suoi. Il comportamento è stato confermato anche sul ramo principale di sviluppo.

La correzione nella 2.8.0

Le note di rilascio della 2.8.0, pubblicata il 29 ottobre, lo dicono in una riga: l'editor del file di un cliente ora mostra e revoca solo i link pubblici creati da quel cliente. È la stessa regola che il portale applicava già, estesa ai due punti in cui mancava. I permessi dello staff restano quelli di prima.

La stessa release chiude diversi altri problemi di autorizzazione: token API che potevano fare più di quanto concesso, zip preparati che restavano scaricabili dopo la perdita dell'accesso a un file, caricamenti finiti in cartelle non più consentite all'utente, e altri ancora. Basta già questo per non rimandare l'aggiornamento.

Cosa fare se usate ProjectSend

Se la vostra installazione è tra la 2.5.0 e la 2.7.1, aggiornate alla 2.8.0 o successiva. Leggete prima la sezione "do these yourself" delle note di rilascio: alcuni token API vanno ricreati per mantenere le stesse funzioni, e i modelli email personalizzati con Markdown ora vengono mostrati come testo semplice.

Dopo l'aggiornamento conviene anche rivedere i link pubblici creati dallo staff sui file caricati dai clienti. Se un link è stato condiviso con persone esterne e il cliente non avrebbe dovuto conoscerlo, l'aggiornamento non lo rende segreto a posteriori: la soluzione è revocarlo e crearne uno nuovo. E se un link dello staff è sparito senza motivo apparente, ora sapete una delle possibili cause.

Più in generale, un portale clienti contiene contratti, fatture, documenti d'identità. Merita aggiornamenti regolari e una revisione periodica dei ruoli: chi ha edit_files, chi ha upload_public, e se ne ha davvero bisogno.

Perché facciamo ricerca su software open source

Consigliamo spesso strumenti open source self-hosted come ProjectSend: i dati restano sul proprio server, non ci sono canoni per utente, il codice si può leggere. Ma qualcuno deve leggerlo davvero, e con l'occhio di chi cerca il punto in cui due parti del programma applicano regole diverse alla stessa cosa. Problemi come questo non emergono usando l'applicazione normalmente: emergono confrontando il codice. Segnalarli ai maintainer è il nostro modo di restituire qualcosa a questi progetti, e di sapere con precisione cosa installiamo per i nostri clienti.

Se usate un portale clienti, un gestionale o un'applicazione su misura e volete sapere se i permessi fanno davvero quello che promettono, ne parliamo volentieri. Il nostro lavoro di penetration testing parte proprio da qui: leggere il codice e la configurazione, capire dove un controllo manca, e dirvi con precisione cosa abbiamo verificato e cosa no.

Parliamo della sicurezza delle vostre applicazioni↗