Установка обновлений — основа обслуживания. Но отчеты показывают, что само обновление может быть скомпрометировано, в том числе в экосистеме WordPress. В этой статье мы рассмотрим, как работают атаки на цепочку поставок (supply chain attacks), используя публичную информацию, а затем разберемся, как найти баланс между «обновлять быстро» и «подождать немного», а также как сократить количество скриптов, которые ваш сайт загружает извне. Цель — спокойное планирование, а не паника.

Что такое атака на цепочку поставок

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

То, чему вы доверяете Примеры
Доставка обновлений Серверы обновлений, официальный каталог, каналы обновлений платных плагинов
Сам вендор Аккаунты разработчиков, системы сборки, владельцы вендора
Файлы, загружаемые извне JavaScript с CDN, сторонние теги, доставка шрифтов

Когда администратор решает: «есть обновление, надо установить» или «этот скрипт известный, надо загрузить», это доверие оборачивается против него. В отличие от обычной уязвимости, проблема возникает  в результате установки обновления.

Публичные случаи (проверено на 2026-11-01)

Они приведены здесь, чтобы показать различные механизмы, а не для того, чтобы обвинить какой-либо продукт.

Изменение скрипта, загружаемого с CDN (2024)

Домен, который раздавал популярную JavaScript-библиотеку, был приобретен другой компанией в феврале 2024 года. Компания по безопасности Sansec сообщила 25.06.2024, что скрипты с этого домена стали содержать код, который перенаправлял посетителей с определенных устройств на другие сайты. Сообщалось, что его использовали более 100 000 сайтов.

Источник: Sansec, Атака на цепочку поставок Polyfill

Главный вывод:  в собственном коде сайта ничего не изменилось. Изменилось только содержимое по адресу загрузки. Обновление сайта или его плагинов не помогло бы это предотвратить.

Смена владельца вендора (2025–2026)

В статье от 15.04.2026 Patchstack сообщил, что вендор плагинов был продан в 2025 году и что вредоносный механизм был внедрен в самых первых изменениях нового владельца. Сообщается, что он оставался неактивным в течение нескольких месяцев и активировался примерно в апреле 2026 года. Команда проверки плагинов WordPress.org подтвердила это 07.04.2026 и закрыла доступ к затронутым плагинам в каталоге.

Источник: Patchstack, Критическая компрометация цепочки поставок в 20+ плагинах

Количество затронутых плагинов в одной и той же статье варьируется («20+» и «25+»), поэтому мы не указываем точное число. Суть в том, что  одна только смена владельца может изменить суть плагина.

Компрометация канала обновлений (2026)

В нескольких отчетах за 2026 год описываются случаи компрометации каналов обновлений платных плагинов, из-за чего официальные обновления содержали вредоносный код (например, The Hacker News). Сроки и масштаб в отчетах различаются, поэтому мы не будем вдаваться в подробности. Проверяйте бюллетени каждой охранной фирмы для получения первичной информации.

Что показывают эти три случая

  • Официальный канал или валидное обновление не  гарантируют безопасность содержимого
  • Между внедрением и обнаружением может пройти  время (некоторые оставались неактивными месяцами)
  • Сканеры ищут известные вредоносные паттерны, поэтому то, что приходит  через легитимный канал, обнаружить сложнее

«Обновлять быстро» и «подождать немного» вместе

В более ранней статье (подождите перед мажорным обновлением) говорилось, что стоит немного подождать с обновлениями, содержащими новые функции. В предыдущей (часы, а не недели) говорилось, что исправления безопасности нужно устанавливать как можно скорее. Атаки на цепочку поставок добавляют еще один аспект.

Тип обновления Базовый подход Что добавить с учетом риска цепочки поставок
Исправление безопасности Проверить и установить как можно скорее Взглянуть, выглядит ли вендор нормально (внезапная смена владельца, странные релизы)
Небольшое плановое обновление Еженедельная пакетная установка Сначала бэкап, потом проверка экранов
Мажорное обновление Подождать и проверить Пока ждете, посмотрите, не появились ли сообщения о проблемах или странностях

Таким образом, два правила объединяются в одну идею:  принимайте решение исходя из содержимого обновления и состояния его источника. Не фиксируйте количество дней ожидания; знайте, почему вы ждете (совместимость или состояние источника).

Что вы можете сделать

Знайте, откуда берется каждый элемент 

 # Installed plugins and their state
wp plugin list --fields=name,status,version,update

# Do core and plugin files match the official releases?
wp core verify-checksums
wp plugin verify-checksums --all
 

 verify-checksums  сравнивает плагины, зарегистрированные на WordPress.org, с официальными релизами.  Платные или распространяемые самостоятельно плагины не входят в область его покрытия. Даже просто составить список того, что нельзя проверить, — уже полезно.

Следите за изменениями у вендора

  • Не изменился ли внезапно вендор или контактные данные используемого вами плагина (страница плагина, changelog)?
  • Не начал ли внезапно выпускать обновления плагин, который долго молчал?
  •  Удаляйте, а не просто деактивируйте плагины, которые вы не используете (статья об инвентаризации)

Сведите к минимуму использование внешних скриптов

Загрузка внешнего скрипта дает коду вне вашего сайта право выполняться внутри него.

  • Составьте список внешних доменов, которые вы загружаете сейчас (вкладка Network в инструментах разработчика браузера или проверьте  <script src>  в HTML, полученном с помощью  curl )
  • Оставьте только то, что нужно. Откажитесь от того, что больше не требуется, например, от полифиллов совместимости для старых браузеров
  • Для того, что осталось, рассмотрите возможность хостинга на своем сервере. Если источник сменит владельца, ваша локальная копия не изменится
  • Добавление  integrity  (хеша) к внешним скриптам — еще один вариант, хотя вам придется обновлять хеш, когда содержимое будет легитимно обновлено

Сохраняйте возможность отката

Не все можно предотвратить. Возможность  вернуться к состоянию до возникновения проблемы — это последний рубеж подготовки. Бэкап является обслуживанием только в том случае, если вы можете из него восстановиться.

Если что-то выглядит подозрительно

  1. Не совершайте лишних действий; зафиксируйте ситуацию (версия, время, скриншоты)
  2. Проверьте бюллетени вендора и охранных фирм
  3. При необходимости переведите сайт в режим обслуживания, чтобы воздействие не распространялось
  4. Восстановитесь из  чистого бэкапа в качестве базовой линии

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

Итоги

  • Атаки на цепочку поставок нацелены на  то, чему доверяет ваш сайт. Они могут произойти, даже если вы обновляетесь и даже если вы загружаете внешние скрипты
  • Публичные случаи разнообразны: перезапись на CDN, смена владельца вендора, компрометация каналов обновлений
  • «Обновлять быстро» и «подождать немного» — это одно правило: принимайте решение исходя из содержимого обновления и  состояния источника
  • Сократите количество внешних скриптов и рассмотрите возможность хостинга оставшихся на своем сервере
  • Сохраняйте возможность отката. Обслуживание включает в себя возможность восстановления

Что нужно сделать сегодня: запустите  wp plugin verify-checksums --all  и составьте список  плагинов, которые не попадают под проверку.