Новости
Nextcloud 35 (Hub 26 Summer): OTP для файловых ссылок, ИИ-агенты и Teams-пространства
Новая версия Nextcloud добавила одноразовые коды для публичных файловых ссылок, ИИ-агентов и пространства для команд.
Коротко: CVE-2026-77165 — уязвимость уровня «умеренная» (CVSS 6.5) в модуле блокировки файлов Nextcloud Server. Любой пользователь с доступом на запись к общему файлу мог поставить на него блокировку типа TYPE_TOKEN, которую не умел снимать владелец файла — файл «зависал» без возможности сохранить изменения, пока администратор не вмешивался напрямую в базу данных. Патч вышел в версии 34.0.1 (также закрыт в Enterprise 32.0.6 и 33.0.6).
Что произошло
8 октября 2026 года проект Nextcloud опубликовал на GitHub security-бюллетень GHSA-22w9-gpgv-pcgc, которому присвоен идентификатор CVE-2026-77165. Проблема найдена в механизме файловых блокировок (file locking) — функции, которая запрещает нескольким людям одновременно редактировать один и тот же документ в общей папке.
У блокировок в Nextcloud есть разные типы, и один из них — TYPE_TOKEN — предназначен для временных сессий редактирования. Баг был в том, что снять такую блокировку мог только тот, кто её поставил, либо администратор через прямую правку базы данных — но не владелец файла. Если соавтор с доступом на запись ставил TYPE_TOKEN-блокировку и затем, например, закрывал вкладку без штатного завершения сессии, файл оставался заблокированным навсегда.
!
Кто под угрозой
Уязвимость затрагивает Nextcloud Server версий 32.0.0 и выше, до исправления в 34.0.1. Нужен сценарий совместной работы: общий файл или папка, где хотя бы у одного соавтора есть право на запись, помимо владельца. Для одиночных личных хранилищ без расшаренных файлов риск минимален.
Почему это важно не только для админов Nextcloud
На первый взгляд баг звучит как мелкое неудобство — «не могу сохранить файл». Но для команд, которые держат рабочие документы в самостоятельно размещённом (self-hosted) облаке вместо коммерческого SaaS, это удар по самой причине выбора такого решения: контролю над собственными файлами. Если заблокировать чужой документ может любой соавтор, а разблокировать — только через ручное вмешательство в базу данных, рабочий процесс команды останавливается, пока не подключится администратор.
Это также напоминание, что безопасность файлового хранилища — это не только шифрование и права доступа, но и логика работы с метаданными файла, включая блокировки. Мы уже разбирали похожие механики в материале о релизе Nextcloud 35 (Hub 26 Summer), где появились OTP для файловых ссылок — там же обновлялась и логика совместной работы над документами.
Как обновиться и что делать, если файл уже заблокирован
- Зайдите в панель администратора Nextcloud и проверьте текущую версию сервера в разделе «Обзор».
- Если версия ниже
34.0.1(для Enterprise — ниже32.0.6/33.0.6), обновите сервер стандартным способом — через встроенный обновитель или пакетный менеджер хостинга. - После обновления проверьте «зависшие» файлы: в приложении files_lock администратор теперь может снять TYPE_TOKEN-блокировку штатно, без прямой правки базы.
- Если вы не администратор, а просто столкнулись с «несохраняемым» файлом в общей папке — обратитесь к администратору вашего Nextcloud-инстанса и попросите проверить версию сервера.
Уязвимость обнаружена и передана через программу приёма отчётов HackerOne (отчёт #3770482) — то есть по ответственной схеме раскрытия, без публикации рабочего эксплойта до выхода патча. Публично подтверждённых случаев массовой эксплуатации на момент публикации бюллетеня не зафиксировано.
Если ваша команда передаёт файлы не только через облачное хранилище, но и напрямую — через мессенджеры или ссылки, — почитайте также наш гайд о том, как безопасно передавать большие файлы в команде.
