filelock: риск удаления соседних данных в ReadWriteLock — CVE-2026-112937

Кому нужно проверить

Разработчикам Python-приложений и администраторам серверов, контейнеров и macOS-систем, где используется пакет filelock. Особенно важно проверить приложения с несколькими пользователями или процессами, если они применяют ReadWriteLock либо AsyncReadWriteLock и размещают базу блокировки в общей директории. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.

В чём риск

ReadWriteLock хранит состояние блокировки в SQLite и создаёт временные каталоги-ссылки. В описанном advisory дефекте при очистке использовался запомненный путь без проверки, что по нему всё ещё находится созданный самой библиотекой каталог. При подходящем системном маршруте и доступе другого локального пользователя к переименованию записей процесс приложения мог рекурсивно удалить подменённое дерево с правами самого приложения. Возможный результат — удаление файлов и каталогов, доступных процессу-владельцу блокировки; advisory сообщает, что операция могла завершиться без ошибки. Это локальный сценарий, а не удалённый доступ через обычный запрос к сайту. Не запускайте искусственные проверки гонки на рабочей системе.

Что сделать

1. 1Сначала определите Python-окружения, в которых реально работают веб-приложение, фоновые задачи и контейнеры. Выполните безопасную команду ниже именно тем интерпретатором, который запускает службу; отдельно проверьте lock-файлы зависимостей и собранные образы.
2. 2Проверьте использование ReadWriteLock и AsyncReadWriteLock в коде и выясните, где находится их SQLite-файл. Зафиксируйте операционную систему, доступность /proc/self/fd в том же контейнере или chroot и права на каталог базы и его родительские каталоги. Не считайте штатный Linux с доступным /proc уязвимым именно по описанному advisory сценарию, но всё равно обновите зависимость.
3. 3Если установка работает на затронутом POSIX-маршруте и обновление нельзя выполнить сразу, временно перенесите базу ReadWriteLock в каталог, куда писать может только учётная запись блокировки (или root), без права записи для группы и остальных. Проверьте также родительские каталоги: по рекомендациям проекта они должны принадлежать этой учётной записи или root и быть недоступны для записи посторонним либо иметь sticky bit. Не делите базу между учётными записями через общий доступный для записи каталог и не держите ценные соседние каталоги рядом с базой в такой общей директории. Это временная мера, не замена обновлению.
4. 4Перед обновлением сохраните файл фиксации зависимостей, конфигурацию сборки и нужные данные приложения. На staging-среде обновите пакет до актуального совместимого выпуска с исправлением; минимально исправленным advisory называет 4.2.1, а страница релизов на дату проверки показывала 4.2.4. Проверьте совместимость приложения и его тесты до выкладки.
5. 5Для отката подготовьте прежний артефакт приложения, но не возвращайте уязвимую версию без сохранения временных ограничений доступа к каталогу. Если совместимость требует отката к версии 4.2.0 или ниже, сначала согласуйте безопасный режим и ограничьте доступ к каталогу базы.
6. 6Разверните новый пакет во всех виртуальных окружениях, образах, workers и экземплярах службы, затем перезапустите процессы, чтобы они загрузили обновлённую библиотеку. Повторите проверку версии в фактическом окружении и убедитесь, что каталог блокировки имеет запланированные владельца и права.
7. 7Проверьте штатные сценарии чтения и записи приложения, совместную работу процессов и журналы на предмет неожиданных ошибок или отсутствующих файлов. Если приложение работало с общей директорией и есть признаки удаления данных, сохраните журналы и резервные копии для расследования; одно обновление не восстанавливает уже удалённые данные.

Когда версия filelock требует особого внимания

Статичная схема отделяет сам факт наличия старой версии от условий применимости CVE. Она читается как нумерованный список и не использует цвет или движение для передачи смысла.

1. 1Приложение использует ReadWriteLock или AsyncReadWriteLock из filelock.
2. 2Версия попадает в диапазон 4.1.0–4.2.0, а процесс идёт по маршруту с жёсткими ссылками.
3. 3Другой локальный пользователь может менять имена записей в доступном для записи каталоге базы блокировки.
4. 4Обновите библиотеку и ограничьте права каталога; затем проверьте фактическую версию и работу приложения.

Примеры конфигурации и проверки

python - <<'PY'
from importlib.metadata import PackageNotFoundError, version

try:
    print('filelock:', version('filelock'))
except PackageNotFoundError:
    print('filelock: не установлен в этом Python-окружении')
PY

Как не подпустить ботов к сайту

Первоисточники

• GitHub Security Advisory проекта: условия, диапазон, CVSS и mitigation
• PR сопровождающего: исправление и поддержка веток
• Релизы проекта: исправление 4.2.1 и последующие выпуски
• PyPI: сведения о выпущенном пакете filelock
• Официальная документация API ReadWriteLock и AsyncReadWriteLock