La documentation de SQLite recense les sauvegardes risquées, les erreurs de verrouillage et les réglages qui peuvent corrompre une base de données.
Des erreurs d’utilisation, pas une nouvelle faille
Dans une page technique mise à jour le 13 avril 2026, le projet SQLite recense les situations capables de corrompre une base de données. Il ne s’agit pas d’une nouvelle vulnérabilité, mais d’erreurs liées aux sauvegardes, aux fichiers auxiliaires, au verrouillage ou au stockage.
Ne pas copier une base pendant une transaction
Copier directement le fichier d’une base active peut produire une sauvegarde incohérente. Si une transaction modifie le fichier pendant sa copie, le résultat risque de contenir un mélange entre l’ancien et le nouvel état.
Pour sauvegarder une base en cours d’utilisation, SQLite recommande VACUUM INTO, son API de sauvegarde ou sqlite3_rsync, disponible depuis SQLite 3.47.0. Une copie classique du fichier reste possible si aucune transaction n’a lieu pendant l’opération.
Conserver les fichiers journal et WAL
Les fichiers portant les suffixes -journal et -wal contiennent les informations dont SQLite peut avoir besoin pour récupérer une transaction interrompue.
Après un crash ou une coupure de courant, les supprimer, les renommer ou les associer à une autre copie de la base peut empêcher la récupération automatique. Lors d’une sauvegarde manuelle après l’échec d’une écriture, ces fichiers doivent accompagner le fichier principal.
Les verrous peuvent devenir dangereux
SQLite utilise des verrous pour coordonner les accès concurrents. Leur fonctionnement peut être compromis sur certains systèmes de fichiers réseau, lorsque plusieurs copies de la bibliothèque SQLite accèdent au même fichier ou lorsque deux processus emploient des protocoles de verrouillage différents.
Une connexion ouverte ne doit pas non plus être réutilisée après fork(). Le processus enfant doit ouvrir sa propre connexion.
Les réglages rapides réduisent les garanties
Certains paramètres améliorent les performances en désactivant une partie des protections de SQLite :
PRAGMA synchronous=OFF;
PRAGMA journal_mode=OFF;
PRAGMA journal_mode=MEMORY;
Avec synchronous=OFF, une coupure de courant ou un arrêt brutal peut laisser les écritures dans un ordre incohérent. Les modes journal_mode=OFF et journal_mode=MEMORY peuvent également entraîner une corruption si l’application plante pendant une transaction d’écriture.
Ces réglages ne devraient être utilisés que si la perte ou la reconstruction de la base est acceptable.
Le stockage doit respecter les écritures
SQLite dépend du système et du matériel pour enregistrer réellement les données. Un disque ou un contrôleur flash qui confirme une synchronisation avant la fin de l’écriture peut provoquer une corruption après une coupure de courant.
Le risque concerne notamment les supports flash de mauvaise qualité, les périphériques retirés brutalement et certains systèmes de fichiers dont les mécanismes de verrouillage ou de synchronisation sont incomplets.
Source :
SQLite — How To Corrupt An SQLite Database File