После очередного запуска компьютера я начал открывать привычные программы. Они одна за другой не запускались, а при проверке оказывалось, что их exe‑файлы просто исчезли.

Сначала я решил, что сломалась Windows или умирает диск. Но проблема выглядела странно: папки оставались на месте, а файлы внутри них пропадали. В папке C:\custom, где у меня лежали программы, проекты и другие данные, почти ничего не осталось.

Всего там находилось около 800 ГБ.

Я начал запускать приложения по одному и смотреть, в какой момент пропадают файлы. Так я начал искать, кто именно их удаляет.

След привел к Telegram Desktop.

Как я нашёл виновника

Telegram был установлен в C:\custom\program\Telegram Desktop, поэтому сначала я подумал на ошибку обновления. Возможно, мессенджер пытался удалить свои старые файлы и заодно задевал всё, что лежало рядом.

Чтобы это проверить, я переустановил Telegram в другое место:

C:\telegram\Telegram Desktop\Telegram.exe

Папку загрузок также указал за пределами C:\custom. Затем создал тестовый файл:

C:\custom\Текстовый документ.txt

После запуска Telegram файл исчез. Я создал его заново, перезапустил мессенджер — файл снова исчез.

Получалось, что Telegram, установленный в C:\telegram, зачем‑то продолжал чистить совершенно постороннюю папку C:\custom

Проверка разных версий показала, когда появился баг. В Telegram Desktop 6.9.4 всё работало нормально, а после обновления до 7.1.1 файлы снова удалялись.

Что показал Process Monitor

Для следующего запуска я включил Process Monitor и запретил удаление тестового файла через права Windows. Telegram дошел до самого удаления, получил отказ, а в логе остался весь процесс.

Между открытием C:\custom и попыткой удалить тестовый файл прошло около 7 секунд.

Стеки вызовов вели внутрь Telegram.exe. Это был не малварь и не какой‑то случайный процесс. Сам Telegram обходил все вложенные папки и удалял всё, до чего мог добраться.

С этими логами я создал issue #31170 и приложил выборку событий и стеков.

Разработчик подтвердил ошибку. Оказалось, что C:\custom удаляла проверка орфографии.

Почему именно custom

Telegram хранит добавленные пользователем слова в файле с именем custom. За эту часть отвечает библиотека lib_spellcheck

В версии 7.1.0 изменили работу пользовательских слов со встроенной в Windows проверкой орфографии. После коммита 4929c892 код для Windows тоже начал обращаться к внутреннему файлу со словами.

Но путь к этому файлу задавался после return, который завершал функцию раньше времени.

Если сильно упростить старый код, получалось следующее:

if (IsSystemSpellchecker()) {
    return;
}

SetWorkingDirPath(DictionariesPath());

На Windows условие выполнялось, функция завершалась, а путь к словарю оставался пустым.

Дальше библиотека строила путь к пользовательскому словарю:

customWordsFile = WorkingDirPath() + "/custom";

Вместо внутреннего файла Telegram получалась строка /custom. Qt преобразовал её в папку custom в корне текущего диска — в моём случае в C:\custom

Код ожидал, что custom будет файлом. Если вместо файла там находилась папка, код считал это ошибкой и удалял её:

if (QFileInfo(path).isDir()) {
    QDir(path).removeRecursively();
}

В нормальной ситуации удалялась бы небольшая служебная папка внутри Telegram. Из‑за пустого пути код добрался до моей папки.

QDir::removeRecursively() продолжает работу, даже если часть файлов удалить не удалось. Поэтому занятые DLL оставались на месте, а остальные файлы исчезали.

Ошибка сложилась в простую цепочку:

1. Windows‑код обратился к внутреннему словарю.

2. Путь к словарю не был задан.

3. Пустой путь превратился в /custom

4. Qt превратил его в C:\custom

5. Telegram запустил рекурсивное удаление.

Отдельная ирония в том, что коммит 40441b29, участвовавший в этой цепочке, сам исправлял другую ошибку с удалением каталогов словарей.

Как исправили ошибку

Исправление оказалось небольшим. В коммите 9c316281 путь стали задавать до return:

SetWorkingDirPath(DictionariesPath());

if (IsSystemSpellchecker()) {
    return;
}

В самой библиотеке коммитом ac399e5c добавили проверку: если путь пустой, работать со словарём нельзя.

Баг попал в релизы 7.1.0 и 7.1.1. Исправление вошло в 7.1.2. Версии с ошибкой были доступны около 66 часов.

Баг подтвердили на Windows со встроенной проверкой орфографии. На Linux и macOS именно такую цепочку действий не находили.

Что в итоге

Это была не сложная атака и не поломка диска. Telegram получил пустую строку, добавил к ней /custom и рекурсивно удалил всё, что смог.

Каждое решение по отдельности выглядело нормально: сохранить пользовательские слова, убрать каталог вместо повреждённого файла, использовать готовую функцию рекурсивного удаления. Опасными они стали вместе, потому что перед удалением никто не проверил итоговый путь.

Перед таким удалением программа должна проверить хотя бы две вещи: путь не пустой и он действительно ведёт внутрь папки приложения.

Популярность продукта и количество его пользователей от простых ошибок не защищают. Иногда между «починили пользовательский словарь» и «удалили 800 ГБ данных» находится всего несколько строк кода.