В мире распределенных баз данных на основе графов обнаружена опасная уязвимость, позволяющая удаленным злоумышленникам без каких-либо учетных данных получить полный контроль над серверами. Проблема, получившая идентификатор CVE-2026-34976 и максимально возможный балл критичности 10.0 по шкале CVSS, затрагивает все версии открытой системы Dgraph вплоть до v25.3.0. Её суть заключается в отсутствии проверок авторизации для одной из административных команд, что открывает путь к перезаписи баз данных, чтению конфиденциальных файлов и атакам типа SSRF (подделка межсайтовых запросов). На текущий момент официальный патч не выпущен, что вынуждает тысячи компаний, использующих эту технологию, полагаться на временные меры защиты.
Уязвимость CVE-2026-34976
Инцидент важен не только для технических специалистов, но и для бизнеса, чья инфраструктура зависит от графовых баз данных. Dgraph часто используется для построения сложных связей в рекомендательных системах, аналитике социальных графов и системах управления знаниями, где хранятся чувствительные данные. Уязвимость такого уровня критичности ставит под угрозу целостность информации и доступность сервисов, потенциально приводя к масштабным утечкам и операционным простоям.
Причина уязвимости, обнаруженной исследователем Кодой Рифом, кроется в классической ошибке конфигурации контроля доступа. В архитектуре Dgraph критически важные административные команды защищены специальным промежуточным программным обеспечением (middleware), которое обеспечивает обязательную аутентификацию, фильтрацию по белым спискам IP-адресов и ведение журналов аудита. Однако, как это часто бывает, при расширении функционала разработчики упустили из виду одну команду - "restoreTenant". В отличие от стандартной и защищенной команды "restore", эта операция была случайно исключена из списка контролируемых промежуточным ПО. В результате любой запрос, отправленный на административный сетевой интерфейс сервера Dgraph, может выполнить эту команду без каких-либо проверок.
Эксплуатация этой бреши не требует от атакующего специальных знаний или предварительного доступа к системе. Исследователь продемонстрировал несколько разрушительных сценариев использования уязвимой функции "restoreTenant", которая принимает для обработки резервных копий внешние URL. Во-первых, злоумышленник может полностью перезаписать рабочую базу данных, разместив вредоносный файл резервной копии на публичном облачном хранилище и указав на него уязвимой команде. После этого Dgraph некритично заменит все существующие данные на контролируемые атакующим. Во-вторых, возможно зондирование локальной файловой системы сервера. Путем указания стандартных путей к файлам в запросе можно заставить систему возвращать детализированные сообщения об ошибках, которые зачастую содержат фрагменты содержимого конфиденциальных каталогов, таких как "/etc/" или "/proc/".
В-третьих, открывается возможность для проведения атак типа Server-Side Request Forgery (SSRF). Указывая в команде внутренние IP-адреса, злоумышленник может заставить сервер базы данных выступать в роли прокси и взаимодействовать с внутренними службами, которые изначально были изолированы от внешней сети. Это позволяет, например, обращаться к метаданным облачных сред (вроде AWS IMDS или Azure Instance Metadata Service) и похищать временные токены доступа, что может привести к компрометации всего облачного проекта. В-четвертых, существует риск кражи учетных данных. Манипулируя параметрами команды, атакующий может заставить систему неправильно обрабатывать внутренние токены сервисных аккаунтов Kubernetes или файлы с паролями, фактически получая к ним доступ.
Отсутствие официального исправления на момент публикации информации об уязвимости создает сложную ситуацию для эксплуатантов. Постоянное исправление на уровне кода требует добавления операции "restoreTenant" в карту административного промежуточного ПО Dgraph, что моментально восстановит для неё стандартные проверки аутентификации и авторизации. Однако до выпуска обновления специалистам по безопасности настоятельно рекомендуется сосредоточиться на сетевой изоляции. Ключевой временной мерой является строгое ограничение сетевого доступа к административным конечным точкам (endpoints) Dgraph. Административный порт ни в коем случае не должен быть доступен из публичного интернета. Необходимо обеспечить его доступность только из доверенных сегментов внутренней сети, используя строгие правила межсетевого экрана (файрвола) и, желательно, VPN для административного доступа.
Между тем, данный инцидент служит очередным напоминанием о критической важности процессов безопасной разработки (Secure Development Lifecycle, SDLC), особенно в проектах с открытым исходным кодом. Регулярные аудиты кода, ревью изменений безопасности и тестирование на проникновение могли бы выявить подобный пропуск до попадания в рабочую среду. Для организаций, использующих Dgraph, последствия могут варьироваться от необходимости экстренного восстановления данных из чистых резервных копий до полной компрометации внутренней сети в случае успешной SSRF-атаки. В текущих условиях бдительность и строгая сегментация сети становятся единственными эффективными щитами против этой критической угрозы.
