Критическая уязвимость в nginx-ui позволяет злоумышленникам выполнять произвольные команды через манипуляции с резервными копиями

В сфере веб-администрирования безопасность инструментов управления имеет первостепенное значение, так как компрометация такого ПО открывает доступ к самой инфраструктуре. Очередным подтверждением этой аксиомы стала критика уязвимость в популярном веб-интерфейсе для управления nginx - nginx-ui. Обнаруженная проблема, зарегистрированная под идентификатором CVE-2026-33026, затрагивает механизм восстановления из резервных копий и позволяет атакующему выполнить произвольный код на целевой системе. Уже опубликован рабочий код эксплуатации, что вынуждает администраторов по всему миру в срочном порядке принимать меры.

Уязвимость CVE-2026-33026

Суть уязвимости кроется в фундаментальном недостатке архитектуры, который исследователь в области информационной безопасности, известный под псевдонимом 0xJacky, охарактеризовал как модель циклического доверия. Процедура резервного копирования в nginx-ui шифрует данные, включая конфигурационные файлы и метаданные для проверки целостности, используя алгоритм AES в режиме CBC. Однако ключ шифрования и вектор инициализации (IV), необходимые для расшифровки, передаются клиенту в виде токена безопасности. Это само по себе создаёт риск, но главная опасность заключается в следующем: один и тот же токен используется как для защиты данных, так и для защиты контрольных сумм (SHA-256 хешей), которые призваны удостоверить, что резервная копия не была изменена.

Таким образом, злоумышленник, получивший этот токен (например, имея права на создание резервной копии в системе), получает возможность не только расшифровать архив, но и незаметно модифицировать его содержимое. Атакующий может извлечь файлы из запакованного архива, внести в конфигурации nginx произвольные вредоносные команды, пересчитать и подменить хеши в файле "hash_info.txt", а затем заново зашифровать архив тем же самым ключом. Поскольку механизм восстановления безоговорочно доверяет хешам, зашифрованным предоставленным токеном, он примет модифицированную резервную копию как подлинную. В результате при её восстановлении на сервере будет применена зловредная конфигурация.

cipher = AES.new(key, AES.MODE_CBC, iv)

decrypted = cipher.decrypt(encrypted_data)

return unpad(decrypted, AES.block_size)

with zipfile.ZipFile(file_path, 'r') as main_zip:

main_zip.extractall(output_dir)

files_to_decrypt = ["hash_info.txt", "nginx-ui.zip", "nginx.zip"]

for filename in files_to_decrypt:

path = os.path.join(output_dir, filename)

if os.path.exists(path):

with open(path, "rb") as f:

encrypted = f.read()

decrypted = decrypt_aes_cbc(encrypted, key_b64, iv_b64)

out_path = path + ".decrypted"

with open(out_path, "wb") as f:

f.write(decrypted)

print(f"[*] Successfully decrypted: {out_path}")

Последствия такой манипуляции крайне серьёзны. Это предоставляет злоумышленникам прямой путь к полному контролю над хост-машиной. Внедрив бэкдор через конфигурацию веб-сервера, можно добиться выполнения произвольных команд с привилегиями процесса nginx. Что делает уязвимость особенно коварной, так это её бесшумность - процесс восстановления не выявляет несоответствия, поскольку проверка целостности опирается на скомпрометированные метаданные. В итоге развёртывание nginx-ui может быть полностью скомпрометировано без каких-либо явных признаков взлома на этапе восстановления данных.

Учитывая публикацию деталей эксплуатации, угроза переходит из теоретической в практическую плоскость. Разработчики nginx-ui уже отреагировали выпуском исправленной версии 2.3.4, в которой данная проблема устранена. Следовательно, первоочередная и самая эффективная мера для всех администраторов - немедленное обновление установленных экземпляров интерфейса до этой версии. Промедление с установкой патча в текущих условиях равносильно осознанному принятию риска взлома.

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

Уязвимость CVE-2026-33026

Ссылки