Vulnerabilità in Datasette: tabelle pubbliche permettono lettura di private
Testo scritto con l’intelligenza artificiale a partire da una fonte citata, senza revisione umana prima della pubblicazione.
Aggiornamento 1.0a38 chiude una SQL injection che lasciava utenti con accesso a tabelle pubbliche leggere dati privati nello stesso database.
Il 6 agosto 2026 Datasette ha rilasciato le versioni 1.0a38 e 0.65.3 per chiudere una SQL injection che permetteva di leggere tabelle private partendo da tabelle pubbliche nello stesso database. Il progetto invita anche a disabilitare il permesso “execute-sql” su quel database1.
Il difetto colpisce istanze che espongono, nello stesso database, un mix di tabelle pubbliche e private governate dal sistema di permessi di Datasette. In questo scenario, un utente con accesso a una tabella pubblica poteva usare l’iniezione per leggere dati in sola lettura da tabelle private. Non si tratta di scrittura o modifica, ma di esfiltrazione di contenuti riservati in quel contesto preciso1.
La nota di rilascio descrive la radice del problema: l’iniezione aggirava il vincolo pensato per bloccare query SQL grezze contro tabelle non esposte quando pubbliche e private convivono nello stesso database. In pratica, il filtro che dovrebbe impedire interrogazioni dirette su risorse non pubbliche non teneva in quel caso. L’effetto era la lettura non autorizzata dei dati privati, limitata a chi poteva già interrogare almeno una tabella pubblica in quel database1.
Il mantenitore definisce questa configurazione probabilmente rara. Dice di non aver incontrato direttamente istanze impostate così. La combinazione resta però possibile ed è sufficiente per giustificare la correzione e un’avvertenza operativa sui permessi1.
Cosa fare ora:
- Aggiornare a Datasette 1.0a38 o, per chi rimane sul ramo stabile precedente, a Datasette 0.65.3. Entrambe le versioni includono la patch1.
- Se si servono tabelle private dallo stesso database di tabelle pubbliche, disabilitare il permesso “execute-sql” su quel database. Il blocco riduce l’uso di query SQL grezze verso tabelle non pubbliche in quell’assetto1.
Le note di rilascio forniscono i dettagli tecnici e le indicazioni per l’aggiornamento. La patch riporta il comportamento atteso: impedire che query grezze contro tabelle non esposte passino quando pubbliche e private convivono nello stesso database1.
La disponibilità della correzione su due rami riduce l’attrito per installazioni con vincoli di compatibilità o di ciclo di rilascio. Chi non può migrare subito al ramo più recente ha una via supportata per chiudere il problema senza stravolgere l’ambiente1.
Il mantenitore non ha riscontrato casi reali di questa configurazione. La scelta di correggere subito e di raccomandare il blocco di “execute-sql” indica però un rischio concreto per chi pubblica dataset misti dallo stesso database: l’allineamento alle versioni corrette e un controllo mirato dei permessi diventano priorità operative1.
Fonti
Come è nato questo articolo Scritto da un sistema di intelligenza artificiale, con controlli automatici
Millebit non ha giornalisti che scrivono gli articoli: li scrive un motore editoriale basato su modelli di intelligenza artificiale, a partire dalle fonti elencate qui sopra. Prima di uscire, ogni testo passa questi controlli:
- Fedeltà alle fonti. Un secondo passaggio toglie ogni affermazione che le fonti non sostengono.
- Anti-cliché. Un filtro scarta frasi fatte, enfasi e tic della prosa artificiale.
- Giudizio editoriale. Un modello valuta il pezzo su sette criteri (apertura, chiarezza, economia, concretezza, voce, struttura, fedeltà) e sotto 7,8/10 non si pubblica.
I controlli riducono gli errori ma non li eliminano: un modello può fraintendere una fonte. Per le decisioni importanti, risali alla fonte originale. Se trovi un errore, segnalacelo.
Per vedere Millebit nelle notizie principali di Google, aggiungilo alle tue fonti preferite. Oppure segui l’edizione di oggi, il feed RSS o La Sintesi.