Безопасность сайта в 2026 году: три урока одного сезона

Эти три темы объединяет не время выхода, а логика: уязвимый интерпретатор, необновлённое ядро и копии данных, живущие рядом с рабочими, — это три звена одной цепи. Сайты, устоявшие против PHP2Shell, гибли от старого модуля голосования; сайты с актуальным ядром теряли всё вместе с хостингом, у которого бэкапы лежали в том же управляющем контуре, что и продакшен. Разбираем каждое звено по отдельности — и как выстроить защиту так, чтобы отказ любого звена не стал фатальным.

Часть 1PHP2Shell: критическое обновление PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35

21 октября 2026 года команда PHP выпустила экстренные security-версии — 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две критические уязвимости удалённого выполнения кода (RCE): CVE-2026-109618 и CVE-2026-109619. Обе получили кодовое имя PHP2Shell и оценку 9,2 из 10 по CVSS v4.0: они позволяют выполнить произвольный код на сервере без аутентификации, просто отправив специально сформированный запрос.

Что случилось

Проблема обнаружена в механизме обработки фатальных ошибок и исчерпания памяти (out-of-memory, OOM) внутри интерпретатора PHP.

• CVE-2026-109618 — при исчерпании памяти интерпретатор прерывается через longjmp() в момент, когда внутренние данные запроса инициализированы лишь частично. При очистке запроса эти «битые» структуры принимаются за корректные, и злоумышленник получает возможность подменить внутреннее состояние и добиться выполнения своего кода.
• CVE-2026-109619 — глобальное состояние, привязанное к запросу, не сбрасывается после фатальной ошибки или нехватки памяти. Следующий запрос, обслуженный тем же воркером, обращается к «протухшему» состоянию по уже освобождённому указателю — классический use-after-free, ведущий к RCE.

Почему это серьёзно

• Проблема — в самом интерпретаторе, а не в CMS или плагинах. Обновление WordPress, Битрикса или Joomla ничего не даёт — нужно обновлять PHP.
• Затронуты версии начиная с PHP 5.4, то есть примерно десять лет PHP-кода. Уязвимость работает при настройках по умолчанию: никакого «сложного конфига» для триггера не нужно.
• Уязвимы все способы обработки веб-запросов: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP, LiteSpeed. Наибольший риск — у mod_php: эксплойт срабатывает до выполнения кода приложения.
• Эксплуатация подтверждена: watchTowr зафиксировал атаки через 19 минут после выхода патчей, Cloudflare — «миллионы» попыток за первые сутки, Perplexity поймала успешные RCE на своих honeypot-серверах.
• Любопытный штрих: уязвимости нашёл искусственный интеллект — исследователи Calif с помощью GPT-5.6 в рамках инициативы Patch the Planet, и независимо от них — компания Wiz.

Исправленные версии

Как проверить свои серверы

Скрипт ищет все установки PHP на машине — а не только ту, что отвечает на php -v. Уязвимым может оказаться бинарник CLI, отдельная установка для конкретного vhost или остатки старой версии.

#!/usr/bin/env bash
# php2shell-check.sh — поиск установок PHP и проверка версии
shopt -s nullglob
FOUND=0
for bin in $(which -a php php-fpm php-cgi 2>/dev/null | sort -u) \
           /usr/bin/php* /usr/local/bin/php* /opt/php*/bin/php \
           /etc/alternatives/php; do
  [ -x "$bin" ] || continue
  VER=$("$bin" -r 'echo PHP_VERSION;' 2>/dev/null) || continue
  FOUND=1
  BRANCH=${VER%.*}
  PATCH=${VER##*.}
  case "$BRANCH" in
    8.5) [ "$PATCH" -ge 12 ] && S=OK || S=VULNERABLE ;;
    8.4) [ "$PATCH" -ge 27 ] && S=OK || S=VULNERABLE ;;
    8.3) [ "$PATCH" -ge 36 ] && S=OK || S=VULNERABLE ;;
    8.2) [ "$PATCH" -ge 35 ] && S=OK || S=VULNERABLE ;;
    *)   S="NO-OFFICIAL-PATCH (ветка $BRANCH)" ;;
  esac
  printf "%-30s %-10s %s\n" "$bin" "$VER" "$S"
done
[ "$FOUND" = 0 ] && echo "Установки PHP не найдены"

После обновления не забудьте перезапустить все процессы PHP — пулы PHP-FPM, Apache и прочие. Работающие воркеры продолжают жить со старой (уязвимой) версией в памяти:

sudo systemctl restart php*-fpm apache2 nginx

План реагирования

1. Запустить скрипт проверки на всех серверах, включая тестовые окружения и коробочные Битрикс24 на своих серверах.
2. Обновить PHP до патч-версии своей ветки: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 или выше. Для 8.2 это окно и повод спланировать миграцию на 8.3/8.4/8.5 — поддержка ветки заканчивается 31 декабря 2026 года.
3. Перезапустить все процессы PHP. Проверить, что новые версии реально используются каждым пулом и каждым сайтом.
4. Проверить логи на признаки эксплуатации: неожиданные падения воркеров по OOM, аномальные запросы, POST-запросы к URL, которые не должны их принимать.
5. Если обновление невозможно немедленно — применить частичные меры: memory_limit=-1 (чтобы OOM не наступал внутри интерпретатора), ограничение памяти на уровне cgroup (не RLIMIT_AS), pm.max_requests=1 в PHP-FPM. Помните: это лишь смягчение, не полноценная защита.

Нюансы, о которых стоит знать

• PHP 8.1 и старше официальных релизов не получат: для 7.4, 8.0 и 8.1 есть только минимальные бэкпорты в исходниках, которые нужно собирать самому; 5.4–7.3 остались совсем без патчей. Единственный надёжный путь — миграция.
• Третья уязвимость без патча. 23 октября всплыла CVE-2026-115560 — редкий вектор RCE через session.upload_progress. Релизы от 21 октября её не закрывают. Временная мера: session.upload_progress.enabled=0 в php.ini, если вы не используете индикатор загрузки файлов.
• Второй пакет обновлений — Brotli. Вскоре после основного релиза вышли патчи CVE-2026-111497, связанные с библиотекой сжатия Brotli. Обновляйтесь до самого свежего пакета, а не только до версий от 21 октября.

Часть 2Цена обновлений: уязвимости сайтов при игнорировании обновлений Битрикса и его модулей

Если PHP2Shell — это атака на фундамент, то необновлённый Битрикс — атака на двери и окна, которые открыты годами, потому что «обновляться было некогда». По оценкам исследователей, через два года после выхода патча ещё 150 000 сайтов оставались уязвимыми к давным-давно исправленной ошибке, а около 90% взломов приходится на сайты, чьё ядро старше шести месяцев.

Почему обновление — не опция

• Механика SiteUpdate работает только при активной лицензии. Участок кода, доставляющий обновления, защищён от записи. У обезличенной копии или неактивированного сайта обновления не приходят, а уязвимости остаются навсегда.
• Вендор закрывает уязвимости быстро, но не всегда публично. В закрытом реестре за год накопилось 36 исправленных уязвимостей — злоумышленники успевают отработать их массово раньше, чем администраторы успевают обновиться.
• «Обновить Битрикс» и «обновить сервер» — разные вещи. Ядро может быть свежим, а уязвимым — модуль, шаблон Aspro или серверный стек (см. часть 1 и историю NGINX Rift).

Хронология атак 2022–2026

Тактика атак

• Массовое сканирование. Ботнеты сканируют интернет на признаки известных уязвимостей (старые модули, характерные ошибки в ответах) и составляют списки целей до выхода патча.
• Тихие бэкдоры. Вместо эффектного дефейса — закладка в коде или в cron: доступ сохраняется на месяцы, пока владелец не подозревает о компрометации.
• Отложенные атаки. Получив доступ, злоумышленники ждут подходящего момента — например, обновления, которое можно «сорвать», чтобы продвинуться дальше или оставить след.

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

Четыре причины, по которым сайты не обновляются

1. «Кастом сломает обновление». Часто это миф: грамотные доработки живут в шаблонах и отдельных модулях, обновление ядра их не трогает. Ломают обычно хаки в ядре — те самые, которые нельзя отслеживать.
2. «Лицензия кончилась, обновиться нечем». Продление лицензии дешевле, чем восстановление после взлома: плановое обновление стоит копейки, а инцидент — сотни тысяч и штрафы.
3. «У нас всё работает, не трогайте». Уязвимость не отключает сайт — она просто ждёт. «Работает» и «защищено» — разные утверждения.
4. «Ответственного нет». Без регулярной проверки обновлений и модулей никто не отвечает за патчи — и сайт остаётся с уязвимостями годами.

Последствия: не только технические

• Простой и SEO-потери. Восстановление после взлома — дни и недели; поисковые системы помечают заражённые сайты и теряют позиции, на восстановление которых уходят месяцы.
• Штрафы по ст. 13.11 КоАП. За утечку персональных данных — до 500 млн рублей в отдельных случаях, за повторное нарушение — выше. Обязанность уведомить РКН о факте инцидента наступает в течение 24 часов (предварительно) и 72 часов (итогово).
• Репутация. Утечка клиентской базы стирает доверие быстрее, чем реклама его наращивает.

Пошаговый план защиты

1. Актуализировать лицензию и настроить ежедневную проверку SiteUpdate. Обновления ядра — приоритет, но также модули и шаблоны.
2. Удалить неиспользуемые модули и компоненты. Каждый «забытый» модуль — потенциальный вектор.
3. Проверить версию PHP на сервере и убедиться, что она патченная (см. часть 1).
4. Ограничить доступ к админке: IP-фильтрация, 2FA, отдельный путь авторизации, сложные пароли, ограничение числа администраторов.
5. Настроить мониторинг целостности кода: агент Битрикса или внешний контроль — аномальные изменения в файлах ядра и шаблонах должны поднимать тревогу.
6. Регулярно бэкапить (см. часть 3): файлы, БД, конфиги — с проверкой восстановления.
7. Пересмотреть кастомизации: уводить доработки из ядра в шаблоны и модули, вести changelog всех изменений, чтобы патчи применялись предсказуемо.

Скрипт самопроверки

#!/usr/bin/env bash
# bitrix-selfcheck.sh — базовая проверка окружения Битрикса
echo "== Версия PHP =="; php -r 'echo PHP_VERSION, PHP_EOL;'
echo "== Модули, отсутствующие в оригинальном дистрибутиве (пример)=="
ls /www/bitrix/modules/ 2>/dev/null | grep -vE '^(main|iblock|forum|search|blog|sale|crm|disk|im|mobileapp|sender|landing|socialservices|catalog|crm.*|main.*|mail|form|calendar|subscribe|lists|seo|translate|perfmon|api|ui|rest|gadgets)$'
echo "== Права на ядровые каталоги (не должны быть 777)==" 
find /www/bitrix -type d -perm 777 -print
echo "== Наличие SiteUpdate=="
curl -sS --max-time 10 -I https://api.1c-bitrix.ru/bx/ | head -1

План для «просроченной на годы» лицензии

1. Продлить лицензию (это дешевле всего, что может случиться потом) — обновления SiteUpdate сразу разблокируются.
2. Сделать полный бэкап ДО обновления (см. часть 3).
3. Обновить ядро последовательно по мажорным версиям, а не «перепрыгивать» через несколько — разработчики Битрикса дают миграционные скрипты.
4. Обновить все модули и шаблоны; для Aspro и прочих тяжёлых шаблонов — проверить совместимость на тестовой копии.
5. Провести аудит модулей: удалить всё, что не используется и не поддерживается.

План реагирования на взлом

1. Отключить публичный доступ (но не удалять данные — они нужны для разбора).
2. Сохранить образы логов веб-сервера, PHP, БД и самих файлов для расследования.
3. Восстановиться из проверенного бэкапа (см. часть 3), а не «подчищать» следы в живой системе.
4. Обновить ВСЕ компоненты стека до актуальных версий, сменить все пароли и ключи.
5. Уведомить РКН в установленные сроки, если произошла утечка персональных данных; подготовить внутренний отчёт об инциденте.

Часть 3Бэкапы сайтов: атака на Beget и правило трёх копий

Атака на Beget в ноябре 2026 года показала, что даже «у нас есть бэкапы» не равносильно «мы готовы к инциденту». Событие стало рабочим тестом для тысячи сайтов и закрытой школой для остальных.

Хронология инцидента

Разбор потерь

Главный урок

Вопрос после Beget звучит не как «есть ли бэкап», а как «кто может его удалить».

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

Пять причин, почему «копия во втором облаке» — тоже не гарантия

1. Ключи от хранилища лежат на атакованном сервере. Если для выгрузки и удаления копий используется один и тот же пароль или токен — второе облако не защищено.
2. Та же панель управления. Бэкапы, доступные через ту же админку, уязвимы вместе с ней.
3. Копии не проверяются на восстановление. Архив без теста восстановления — это просто надежда, а не план.
4. Одна копия, один момент времени. Если копия делается раз в неделю, сутки после последнего бэкапа — это окно, которое атака обязательно найдёт.
5. Отсутствие неизменяемости (immutable). Если копии можно перезаписать, они будут перезаписаны — автоматизированным шифровальщиком или вручную.

Правило 3-2-1 и современная версия 3-2-1-1-0

3-2-1: три копии данных, на двух разных типах носителей, одна — вне площадки (off-site).
3-2-1-1-0: плюс одна офлайн-копия (air-gap) и ноль ошибок при проверке восстановления.

• Air-gap — физическая или логическая изоляция: отключаемый диск, NAS, отключенный от сети носитель, недоступный из интернета.
• Immutable-хранилища — режим WORM (Write Once, Read Many): после записи объект нельзя изменить или удалить в течение заданного срока. Поддерживается в объектных хранилищах (S3 Object Lock и аналоги) и в системах класса NAS.

Отдельно о локальных копиях

Как показал Beget, локальная копия — единственный слой, полностью независимый от чужого управляющего контура.

• Что подходит: отключаемый внешний диск (подключается только на время бэкапа), NAS в отдельной VLAN без прямого доступа из интернета, локальный сервер с репликой.
• Что НЕ считается локальной копией: папка на том же сервере, вторая директория в том же облаке, синхронизация Dropbox на ту же машину.
• Как часто: локальная копия должна сниматься хотя бы раз в сутки для сайтов с частыми изменениями и раз в неделю — для статичных.
• Срок хранения: минимум 30 дней с ротацией (дневные / недельные / месячные), чтобы пережить долгое «незаметное» повреждение.

Что бэкапить: не только файлы

Три практических уровня

1. Виртуальный хостинг

• Использовать встроенные бэкапы панели, но не полагаться только на них: скачать копию на локальный диск (по FTP/SSH) раз в неделю или чаще.
• Проверить, где физически хранятся бэкапы провайдера — на том же сервере или на отдельной площадке.

2. VPS / выделенный сервер

Готовый скрипт: дамп БД + tar + выгрузка rclone в два независимых хранилища + ротация + проверка целостности.

#!/usr/bin/env bash
# daily-backup.sh — полный бэкап сайта: файлы + БД + выгрузка в 2 хранилища
set -euo pipefail

SITE_DIR=/var/www/mysite
DB_NAME=mysite_db
DB_USER=backup_user
DB_PASS="CHANGE_ME"      # хранить в /root/.my.cnf или env-файле с 600
BACKUP_ROOT=/var/backups/mysite
REMOTE1=remote_s3:bucket/mysite     # rclone remote #1 (облако, WORM если возможно)
REMOTE2=/mnt/offsite_disk           # rclone remote #2: NAS/отключаемый диск
RETENTION_DAYS=30
DATE=$(date +%F)
TS=$(date +%F_%H%M)
DEST="$BACKUP_ROOT/$DATE"
LOG=/var/log/daily-backup.log

mkdir -p "$DEST"
exec >>(tee -a "$LOG") 2>&1
echo "[$(date -Is)] start backup"

# 1. Консистентный дамп БД
mysqldump --single-transaction --quick --routines --events \
          -u"$DB_USER" -p"$DB_PASS" "$DB_NAME" \
          | gzip > "$DEST/db_${TS}.sql.gz"

# 2. Архив файлов (исключаем кэши и временные каталоги)
tar -czf "$DEST/files_${TS}.tar.gz" \
    --exclude="$SITE_DIR/bitrix/cache" \
    --exclude="$SITE_DIR/bitrix/managed_cache" \
    --exclude="$SITE_DIR/bitrix/stack_cache" \
    --exclude="$SITE_DIR/upload/tmp" \
    -C /var/www mysite

# 3. Выгрузка в два независимых хранилища
rclone copy "$DEST" "$REMOTE1" --transfers 4 --checkers 8
rclone copy "$DEST" "$REMOTE2" --transfers 2

# 4. Проверка целостности: хэш-файл
(cd "$DEST" && sha256sum *.tar.gz *.sql.gz > SHA256SUMS)
rclone copy "$DEST/SHA256SUMS" "$REMOTE1"
rclone copy "$DEST/SHA256SUMS" "$REMOTE2"

# 5. Ротация локальных копий
find "$BACKUP_ROOT" -type d -mtime +$RETENTION_DAYS -exec rm -rf {} +

# 6. Контроль: проверка, что архив не пуст и размер > 0
for f in "$DEST"/*.tar.gz "$DEST"/*.sql.gz; do
  [ -s "$f" ] || { echo "ERROR: $f is empty"; exit 1; }
done
echo "[$(date -Is)] backup done"

Запуск по cron с уведомлением о результатах (Telegram, e-mail, Zabbix). Ключевой момент: REMOTE2 должен монтироваться отдельной машиной или через SSH-ключи, недоступные из compromised-сервера.

3. Облачные сервисы

• Объектное хранилище с WORM/immutable политикой (S3 Object Lock, GCS retention, Azur Blob immutability) — с удалённым доступом через отдельные учетные данные.
• Включить версионирование: даже если объект «перезаписали», предыдущая версия сохраняется.
• Ограничить право удаления отдельной учёткой, которую атакующие не получат, захватив продакшен.

Тест восстановления

Копия, которая не проверялась на восстановление, — это не бэкап, а теория. Раз в квартал:

1. Развернуть свежую копию на отдельной машине/контейнере.
2. Проверить работоспособность: сайт открывается, БД содержит свежие записи, админка работает.
3. Засечь время: восстановление не должно длиться дольше, чем допустимый простой (RTO), и не должно терять больше данных, чем допустимо (RPO).
4. Зафиксировать результат в чек-листе и исправить найденные проблемы.

Если ваш провайдер уже пострадал

1. Не паниковать и не удалять ничего на стороне провайдера — даже если интерфейс «не отвечает».
2. Если есть локальные копии — готовить их к восстановлению на новой площадке: параллельно закупке/аренде сервера и настройке DNS.
3. Собрать доказательства инцидента (скриншоты, e-mail, логи) — они пригодятся для разбирательств и РКН.
4. Проверить, не были ли скомпрометированы секреты (пароли БД, ключи API, токены) — их нужно сменить при переносе.
5. Пересмотреть, где теперь хранятся копии, и выстроить независимость по контуру управления (см. «Главный урок»).

Общий чек-лист безопасности

Источники

1. comss.ru — «Обнаружены две критические уязвимости PHP (PHP2Shell)»
2. Laravel News — «PHP critical RCE security releases»
3. Smart-Soft — разбор CVE-2026-109618 и CVE-2026-109619
4. iFellow — «Уязвимости в PHP: как это случилось и что делать владельцам сайтов»
5. OpenNET — обзор инцидента PHP2Shell
6. РБК — «Миллионы попыток атак в первые сутки после выхода патчей PHP»
7. Joomla.center — «PHP critical security release»
8. Integrator.digital — рекомендации для владельцев коробочных Битрикс24
9. Mallory.ai — «PHP RCE rapid response» (CVE-2026-115560)
10. Исследования по необновлённым Битрикс-сайтам, статистике взломов и реестру уязвимостей вендора
11. Документация 1С-Битрикс: механизм SiteUpdate, права доступа, модули
12. Публикации о CVE-2022-27228 (модуль vote) и уязвимости NGINX Rift
13. Материалы о штрафах по ст. 13.11 КоАП и сроках уведомления РКН (24/72 часа)
14. Аналитика инцидентов 2023–2026 по российской CMS-экосистеме
15. Публикации об атаке на Beget, восстановлении сервисов и объёмах потерь
16. Сообщения Роскомнадзора о приостановке аккредитации Beget как регистратора
17. IBM Cost of a Data Breach Report 2026
18. Практические руководства по резервному копированию: правило 3-2-1 / 3-2-1-1-0, air-gap, WORM-хранилища