В библиотеке protobuf.js нашли шесть уязвимостей, которые могут привести к отказу в работе сервисов и, в худшем случае, к выполнению произвольного кода. Исследователи назвали этот набор Proto6. Под ударом — Node.js-приложения, которые читают Protobuf-данные, генерируют код из схем или используют связанные инструменты в сборках и облачных контурах.

Исправления уже доступны в protobufjs 7.5.6 и 8.0.2, а также в protobufjs-cli 1.2.1 и 2.0.2. Для команд, где эти пакеты живут в цепочке сборки, вопрос сейчас не теоретический: уязвимость может затронуть и приложение, и пайплайн.

Что такое Proto6 и где лежит проблема

Proto6 — это набор из шести багов в protobuf.js, JavaScript- и TypeScript-реализации Protocol Buffers. Protobuf — это формат для хранения и передачи структурированных данных, который часто используют в микросервисах, SDK и внутренних интеграциях.

Проблема упирается в то, что библиотека слишком доверяет схеме и метаданным. Если приложение принимает внешнюю схему, десериализует сообщения или генерирует код на лету, атакующий может подсунуть вредоносный объект и сломать логику обработки.

Среди описанных сценариев — бесконечная рекурсия, падение процесса при загрузке схемы, инъекция в конструкторы сообщений и подмена поведения через pollution prototype. В отдельных случаях речь уже идет не только о сбое, но и о выполнении JavaScript-кода внутри процесса Node.js.

Как это работает технически

Слабое место — в том, как protobuf.js ищет типы и собирает код. Библиотека делает обычные обращения к свойствам объектов, а значит, загрязнение Object.prototype может подменить ожидаемое значение.

Дальше сценарий развивается быстро: библиотека вставляет подставленную строку в сгенерированный encoder или decoder, а затем компилирует результат через Function(). Если атакующий успел подменить входные данные, он получает выполнение своего JavaScript-кода в контексте процесса.

В других вариантах атаки достаточно специально оформленной схемы или имени поля, чтобы вызвать отказ в работе. Это особенно неприятно для сервисов, которые автоматически принимают схемы из репозиториев, артефактов сборки или внешних интеграций. Подобные цепочки уже ломали и крупные корпоративные среды — похожий сценарий мы разбирали на примере уязвимости в Microsoft Defender.

Почему это опасно для бизнеса и разработки

Опасность Proto6 в том, что библиотека сидит не только в прикладном коде. Ее можно встретить в облачных SDK, очередях сообщений, генераторах клиентов, CI/CD-инструментах и ML-пайплайнах.

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

Для компаний, которые строят сложные цепочки из сервисов, это отдельный риск. Здесь уже неважно, что именно ломается — бот, шлюз, обработчик сообщений или внутренний API. Любая точка, где Protobuf считают «доверенным форматом», становится потенциальной мишенью. Логика похожа на историю с дырой в ServiceNow, через которую открывался лишний доступ: уязвимость живет там, где ей слишком доверяют.

Как понять, что проблема касается вас

Проверьте, использует ли проект protobuf.js или protobufjs-cli напрямую либо через зависимости. Отдельно посмотрите, есть ли в архитектуре загрузка внешних схем, генерация кода из метаданных и автоматическая обработка сообщений Protobuf.

Если у вас Node.js-сервис, который принимает данные из очередей, облачных SDK, внутренних API или CI/CD-артефактов, риск выше. Особенно если схемы приходят из разных команд, репозиториев или сторонних интеграций без жесткой проверки.

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

Что делать прямо сейчас

Обновите protobuf.js и связанные пакеты до исправленных версий. Для большинства команд это самый быстрый и надежный шаг.

Дальше проверьте, откуда приходят схемы и метаданные. Если код принимает внешние файлы, ограничьте круг источников и добавьте проверку входных данных до генерации кода или десериализации.

Для сотрудников, которые работают из поездок или подключаются к корпоративным ресурсам через публичные точки доступа, полезно держать под рукой сервис для защищенного подключения в дороге как один из элементов общей гигиены связи. Это не чинит уязвимость в библиотеке, но снижает лишние риски для данных и сеансов работы.

Практический чек-лист

  • Проверьте версии protobuf.js и protobufjs-cli в проекте и в транзитивных зависимостях.
  • Обновите пакеты до исправленных релизов 7.5.6, 8.0.2, 1.2.1 или 2.0.2.
  • Найдите места, где код принимает внешние Protobuf-схемы, descriptors или payloads.
  • Ограничьте источники схем и уберите автоматическую загрузку из непроверенных мест.
  • Посмотрите на пайплайны сборки: нет ли там генерации кода из внешних метаданных.
  • Проверьте логи на падения, ошибки парсинга и сбои после обновления зависимостей.
  • Если сервис критичный, добавьте отдельный контроль входных данных перед десериализацией.
  • Зафиксируйте обновление в ближайшем релизном плане, а не откладывайте на следующий цикл.
Поделиться: