CVE-2026-112913 Lectura y escritura fuera de límites en filelock al usar ReadWriteLock en Windows
En Windows, ReadWriteLock y AsyncReadWriteLock de filelock adjuntan SQLite a la base de bloqueo por ruta, lo que permite a otra cuenta local crear archivos side file (database-wal o database-journal) junto a la base. Un WAL no eliminable hace fallar cada adquisición de lectura o escritura, y un hot journal puede provocar que la recuperación de SQLite borre un archivo indicado por ese journal. Requiere un directorio escribible por otra cuenta, como un temporal compartido de Windows. Corregido en la versión 4.2.1.
CVSS 3.1
- Probabilidad de explotación · EPSS del 09/110,1 % · percentil 1
- Explotada activamenteNo confirmada
- Exploit públicoNo conocido
Afectados
tox-dev filelock
>= 3.20.4, < 4.2.1
Qué hacer
- Verificá si usás filelock y en qué versión.
- Actualizá a la versión corregida que indique el fabricante en su aviso o aplicá su mitigación.
- Revisá registros y accesos de los sistemas expuestos para descartar un uso previo.
Calculadora CVSS
CVSS 3.1 · 3.3 BAJA
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
- Vector de ataqueLocal
- Complejidad del ataqueBaja
- Privilegios requeridosBajos
- Interacción del usuarioNinguna
- AlcanceSin cambio
- ConfidencialidadNinguna
- IntegridadNinguna
- DisponibilidadBaja
Descripción original
filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock and AsyncReadWriteLock on Windows use _connect to attach SQLite to the lock database by pathname, allowing another local account that can create adjacent names to place a database-wal or database-journal side file before acquisition. An undeletable WAL file makes each read or write acquisition fail immediately with sqlite3.OperationalError regardless of timeout. Separately, when the database contains at least one table, a hot journal that grants the lock account modify rights can cause SQLite recovery to delete a file named by that journal only when the lock account has permission to delete the target. The issue requires a directory writable by another account, such as a shared Windows temporary directory, and does not affect private directories. This issue is fixed in version 4.2.1.
Referencias (5)
Resumen traducido automáticamente de la descripción original. Fuente: Nureq Monitor. Cómo funciona.