Перейти к содержимому
>_ITDITDПлатформа веб-безопасности

Глоссарий

Что такое RCE (Remote Code Execution) — почему это худший класс багов

RCE (Remote Code Execution) позволяет атакующему выполнить код на вашем сервере по сети — прямой путь к захвату, худший класс. Чем оно отличается от XSS и SQLi, что задаёт радиус поражения и как защищаться: быстрые патчи, мониторинг CVE, минимум привилегий.

Опубликовано 2026-06-07 Обновлено 2026-06-07 3 мин чтения

«RCE с CVSS 10.0» — фраза, от которой безопасники напрягаются сильнее всего. Вот почему RCE — «худший класс» и чем оно отличается от других багов, с нуля.

Чем оно отличается от других багов

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

УязвимостьГде выполняется кодОсновной ущербТипичная критичность
XSSв браузерекража сессии, дефейссредняя–высокая
SQLiв базе данныхчтение/изменение данныхвысокая
RCEна самом серверезахват, латеральное движение, всёхудшая (класс 10.0)

Почему это худший класс

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

RCE достигнуто (выполнение произвольного кода)

↓ что это позволяет
прочитать .env и украсть секреты
дотянуться до БД, чтобы вынести/изменить
плацдарм для латерального движения
↓ как далеко распространяется =
«привилегии» процесса (поэтому минимум привилегий работает)
Радиус поражения задаётся привилегиями работающего процесса. Минимум привилегий и изоляция — последняя линия защиты.

Радиус поражения задаётся «привилегиями этого процесса». Именно поэтому контейнеризация, минимум привилегий и изоляция (минимизация радиуса поражения) работают. Запустите под root — и всё потеряно; запустите непривилегированно и изолированно — и вы локализуете это.

Большинство RCE приходят из «известных дыр», а не из ваших багов

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

Что вы можете сделать для защиты

1

Не пренебрегайте опубликованными CVE (главная защита)

Мониторьте CVE машинами (Dependabot / osv-scanner) и быстро обновляйтесь до исправленных версий. Большинство RCE приходят из пренебрежения известными дырами.

2

Судите по работающей версии

Измеряйте риск по версии, которая реально работает, а не по нижней границе в манифесте. Доверие тексту искажает оценку опасности.

3

Минимизируйте радиус поражения

Запускайте под непривилегированным пользователем; изолируйте контейнеры и сети. Локализуйте ущерб, если вас поразили.

4

Не передавайте ввод прямо в выполнение

Никогда не подавайте внешний ввод напрямую в команды оболочки, десериализацию или вычисление шаблонов. Основы того, чтобы не написать RCE самому.

Читать дальше

FAQ

QЧем RCE отличается от обычных багов вроде XSS?
A

XSS и подобные в основном безобразничают внутри браузера пользователя; RCE запускает произвольные программы на самом сервере. Поскольку оно может дотянуться до привилегий сервера, данных и других сервисов, это, как правило, самый тяжёлый класс.

QКак далеко распространяется ущерб от RCE?
A

Настолько далеко, насколько простираются привилегии процесса, работавшего в момент атаки. Запуск под root или с широкими правами — ущерб огромен; запуск под непривилегированным пользователем с изоляцией контейнера — можно локализовать. Вот почему минимум привилегий и изоляция важны.

QКак мне (разработчику) защититься от RCE?
A

Помимо того, чтобы не писать RCE-баги самому (не передавайте ввод прямо в выполнение), главная защита — не пренебрегать опубликованными RCE в используемых вами фреймворках/библиотеках. Мониторинг CVE и быстрые обновления — основа.