Payload CMS 3.90: le correzioni sono uscite a settembre, gli avvisi degli scanner arrivano adesso. Cosa controllare se gestisci il plugin Multi-Tenant

Payload CMS 3.90: le correzioni sono uscite a settembre, gli avvisi degli scanner arrivano adesso. Cosa controllare se gestisci il plugin Multi-Tenant

Se questa settimana lo scanner delle dipendenze ha segnalato Payload, la correzione non è nuova. Payload, il CMS headless open source che molte agenzie e molti MSP usano per i siti dei clienti, ha pubblicato un gruppo di advisory di sicurezza il 18 settembre 2026 insieme alla versione 3.90.0, che li corregge. I record CVE e le voci verificate nel database degli advisory di GitHub sono arrivati il 6 e 7 ottobre, ed è lì che leggono Dependabot e strumenti simili: per questo gli avvisi compaiono circa tre settimane dopo la patch. Il gruppo è ampio: secondo il nostro conteggio dalle API di GitHub, 22 advisory datati 18 settembre nel repository di Payload, quattro critici, quattordici di gravità alta e quattro di gravità media.

Per gli MSP il primo da leggere riguarda il plugin Multi-Tenant, l'estensione che permette a una sola installazione di Payload di servire più clienti: con le impostazioni predefinite, un utente autenticato poteva assegnarsi ad altri tenant. Altri riguardano il plugin Form Builder, le collezioni che usano l'opzione orderable, la gestione del token di login e le installazioni nuove in cui non è mai stato creato il primo utente amministratore. Nessuno compare nel catalogo Known Exploited Vulnerabilities della CISA, e nessuno degli advisory che abbiamo letto parla di sfruttamento. La nostra tesi: la patch è la metà facile. Se hai usato per mesi una versione vulnerabile con queste funzioni, devi anche verificare chi appartiene oggi a quale tenant. Di seguito: cosa è cambiato, cosa ti riguarda, come controllare la versione e cosa rivedere dopo l'aggiornamento. Fonti: advisory di Payload e dati npm tramite le API di GitHub e npm, e il catalogo CISA, letti il 9 ottobre 2026.

Gli advisory più importanti per gli MSP

Vanno letti come condizioni «sei esposto se»: ognuno dipende da una funzione che potresti usare o no. Plugin Multi-Tenant, appartenenza ai tenant (GHSA-p96c-xwx8-3cqj, CVE-2026-105860, alta, punteggio CVSS 4 di 7,1). L'advisory di Payload dice che con l'accesso predefinito al campo che elenca i tenant un utente autenticato poteva assegnarsi ad altri tenant. Non sei esposto a questo comportamento predefinito se avevi già configurato tu i permessi di creazione e modifica di quel campo. Un advisory collegato (GHSA-xhm9-gwgw-3q2q, CVE-2026-105864, media) dice che un utente limitato a un tenant poteva creare un record in un altro tenant, anche se lettura e modifica diretta dei documenti esistenti non erano aggirate.

Collezioni ordinabili (GHSA-f7hx-52q9-hcrf, CVE-2026-105859, critica, punteggio CVSS 3 di 9,8). Se una collezione o un campo join usa orderable: true, i documenti potevano essere modificati ignorando i controlli di accesso. Plugin Form Builder (GHSA-r488-j9vj-wx3q, CVE-2026-105857, critica, punteggio CVSS 3 di 10,0). Se usi il plugin, invii di moduli costruiti ad arte potevano eseguire codice sul server. Token di login (GHSA-66wr-7vmr-p5jq, CVE-2026-105863, critica, punteggio CVSS 4 di 9,2). Riguarda le configurazioni in cui un'opzione personalizzata associa un campo a un nome di claim di autenticazione riservato; Payload dice che non esiste un workaround completo. Primo utente amministratore (GHSA-97rh-rhh2-7vjv, CVE-2026-105858, alta, punteggio CVSS 3 di 8,1). Riguarda le app con autenticazione locale in cui non è ancora stato creato il primo utente, condizione in cui un'installazione nuova o uno staging dimenticato possono restare per settimane.

Tutto ciò è corretto nella 3.90.0 e, nella linea canary 4.0, dalla 4.0.0-canary.34. Il resto del gruppo del 18 settembre riguarda, tra l'altro, controlli di accesso ai campi nelle collezioni di autenticazione, esposizione di chiavi API tramite normali letture di documenti, gestione degli upload, sanificazione degli SVG, SQL injection negli adapter SQLite e Postgres, e i plugin Stripe ed Ecommerce, tutti corretti nella 3.90.0 o, per alcuni adapter, in versioni precedenti. Non riportiamo dettagli tecnici oltre a quelli necessari per capire se sei esposto.

Perché gli avvisi arrivano con tre settimane di ritardo, e i gruppi successivi

I tempi spiegano il rumore. Payload ha pubblicato gli advisory nel proprio repository GitHub il 18 settembre, lo stesso pomeriggio in cui la 3.90.0 è arrivata su npm. Gli scanner come Dependabot lavorano soprattutto sul database verificato degli advisory di GitHub e sui record CVE, e per questi casi sono comparsi il 6 e il 7 ottobre. Se il tuo team ha aggiornato a settembre, l'avviso è una conferma; altrimenti è un buco di tre settimane.

Dopo la correzione sono arrivati altri advisory. Tra il 22 e il 29 settembre Payload ne ha pubblicati altri sette, corretti fra la 3.88.0 e la 3.90.0. Il 6 ottobre ne ha pubblicati tre di gravità alta: due nel plugin MCP (uno su risposte di login che includevano campi normalmente nascosti, uno sul recupero password che dava a un utente MCP autenticato l'accesso a un altro account), rilevanti solo se quegli strumenti MCP sono attivi, e uno su Payload Jobs, rilevante se i Jobs sono attivi e utenti non fidati raggiungono la collezione dei Jobs. Le correzioni sono rispettivamente nella 3.88.0, nella 3.90.0 e nella 3.89.0. L'8 ottobre ne sono seguiti altri sette, uno di gravità alta e sei di gravità media, anch'essi corretti entro la 3.90.0. Una sola regola copre quindi tutti i gruppi: essere alla 3.90.0 o successiva. Al 9 ottobre la versione 3.x più recente su npm è la 3.90.2. Nessuno di questi compare nel catalogo della CISA all'aggiornamento dell'8 ottobre.

Perché il problema multi-tenant merita la prima occhiata, anche se è classificato «alto» e non «critico»: in un'installazione condivisa, l'elenco dei tenant nel profilo di un utente è il confine tra un cliente e l'altro. L'advisory di Payload descrive un'impostazione predefinita in cui quell'elenco poteva essere modificato dall'utente stesso. Per un'agenzia che ospita più clienti su una sola app Payload, un normale account da redattore presso un cliente diventa una possibile porta verso i contenuti di un altro, senza alcuna compromissione del server: basta una modifica di appartenenza che sembra un dato qualsiasi. Ecco perché il solo aggiornamento non chiude la questione. La nuova versione impedisce che succeda di nuovo; non può dirti se è già successo. Possono dirlo solo i tuoi dati e i tuoi log. Esegui questi comandi in ogni progetto per vedere cosa è installato, poi aggiorna insieme tutti i pacchetti payload e @payloadcms/*.

# Which Payload packages and versions are actually installed? (read-only)
npm ls payload @payloadcms/plugin-multi-tenant @payloadcms/plugin-form-builder @payloadcms/plugin-mcp
# pnpm:  pnpm why payload
# yarn:  yarn why payload

# Upgrade all Payload packages together (same version across @payloadcms/*)
npm install payload@^3.90.0 @payloadcms/next@^3.90.0
# ...repeat for every @payloadcms/* package in package.json, then commit the lockfile

Dopo l'aggiornamento: una lista di verifica per le installazioni multi-tenant

È la nostra checklist difensiva; i workaround del fornitore sono indicati come tali.

1. Prima aggiorna, ovunque. Produzione, staging, preview e istanze demo dimenticate. Un lockfile fermo sotto la 3.90.0 mantiene il codice vecchio anche se il package.json sembra corretto.
2. Verifica le appartenenze ai tenant. Esporta l'elenco dei tenant di ogni utente e confrontalo con chi deve avere accesso, cliente per cliente. Cerca utenti presenti in più tenant di quanto giustifichi il loro ruolo, e modifiche alle appartenenze fatte da non amministratori. Le prove sono i timestamp di aggiornamento nel database e gli eventuali log di audit; l'advisory di Payload non fornisce un metodo di rilevamento, quindi non prometterne uno ai clienti.
3. Blocca il campo delle appartenenze. Anche sulla 3.90.0, imposta permessi espliciti di creazione e modifica sul campo dei tenant, così che solo amministratori fidati con accesso a tutti i tenant possano cambiarlo. È anche il workaround del fornitore se un'installazione non si può aggiornare oggi.
4. Cerca record tra tenant diversi. Poiché un advisory permetteva di creare record in un altro tenant, controlla a campione i documenti recenti nelle collezioni con tenant per voci create da utenti di un altro cliente.
5. Form Builder. Se installato, verifica di essere alla 3.90.0, rivedi chi può inviare e chi può leggere gli invii, e valuta se i moduli pubblici ne hanno davvero bisogno.
6. Collezioni ordinabili. Elenca ogni collezione o campo join con orderable: true e rivedi le modifiche recenti fatte da utenti che non dovrebbero avere permessi di scrittura.
7. Primo utente. Assicurati che ogni app Payload con autenticazione locale abbia l'account amministratore iniziale; non lasciare installazioni nuove raggiungibili da internet senza.
8. MCP e Jobs. Se sono attivi gli strumenti di autenticazione del plugin MCP o Payload Jobs, verifica chi può raggiungerli e spegni ciò che non usi.
9. Nel dubbio, ruota le chiavi. Un advisory del 18 settembre riguarda l'esposizione di chiavi API tramite normali letture di documenti; ruotare le chiavi API dopo l'aggiornamento è una precauzione economica (nostro suggerimento, non un'istruzione del fornitore).
10. Comunica chiaro ai clienti: corretto dal 18 settembre, avvisi dal 6–7 ottobre, nessuno sfruttamento segnalato, aggiornamento e verifica delle appartenenze completati in una data precisa.

Riassumendo: Payload ha pubblicato un gruppo di advisory e la 3.90.0 il 18 settembre 2026; i record CVE e le voci verificate nel database di GitHub per i casi principali sono arrivati il 6–7 ottobre, ed è per questo che gli scanner li segnalano ora. Secondo il nostro conteggio, il gruppo del 18 settembre conta 22 advisory nel repository di Payload (quattro critici, quattordici di gravità alta, quattro di gravità media). Il punto chiave per gli MSP è il plugin Multi-Tenant: con l'accesso predefinito al campo delle appartenenze, un utente autenticato poteva assegnarsi ad altri tenant (alta), e un problema collegato permetteva di creare record in un altro tenant (media). I casi critici riguardano il plugin Form Builder, le collezioni con orderable: true e la gestione del token di login; un caso di gravità alta riguarda le installazioni senza primo utente amministratore. Gli advisory successivi, compresi i gruppi del 6 e dell'8 ottobre, sono corretti entro la 3.90.0. Non compare nel catalogo KEV della CISA; nessun advisory che abbiamo letto segnala sfruttamento. Azione: aggiornare tutti i pacchetti Payload alla 3.90.0 o successiva (attuale 3.90.2), poi verificare le appartenenze ai tenant e rivedere gli accessi a Form Builder e alle collezioni ordinabili.