WordPress объявил о запуске автоматической проверки безопасности для каждого выпуска плагина перед его распространением через API обновлений WordPress.org. Цель — анализ на предмет потенциальных уязвимостей и обеспечение отсутствия рисков.
«Новые плагины проверяются перед попаданием в каталог, но обновления выпускаются непрерывно после этого», — заявил Дэвид Перес, соруководитель команды репозитория плагинов WordPress. «Плагин может быть безопасным сегодня и представить уязвимость или вредоносный код в будущем выпуске».
WordPress сообщил, что отсутствие «последовательного этапа проверки» между фиксацией выпуска и его отправкой конечным пользователям открывало двери для вредоносных атак.
Платформа системы управления контентом (CMS) отметила, что ее автоматическая проверка обнаружила бэкдор, внедренный в выпуск плагина примерно с 20 000 активных установок 28 июля 2026 года. Поскольку выпуск произошел в течение периода охлаждения, скомпрометированная версия плагина так и не была распространена через API обновлений WordPress.org.
Плагин был закрыт для загрузки через 26 минут после того, как команда плагинов была уведомлена об обновлении компанией по безопасности WordPress Wordfence. WordPress не раскрыл название плагина.
С 5 июня 2026 года каждый плагин и тема WordPress проходят период охлаждения перед распространением через автоматические обновления в рамках новой инициативы безопасности Protect The Shire. Идея состоит в том, чтобы внести некоторое трение в процесс, чтобы вредоносные обновления не достигали конечных пользователей немедленно. Период охлаждения в настоящее время составляет шесть часов, сократившись с 24 часов, когда он был впервые введен.
Последнее усилие направлено на устранение еще одного критического пробела в безопасности: высокий уровень риска для выпуска плагина или темы должен автоматически приостанавливать распространение без участия команды плагинов. Весь процесс проходит следующие этапы:
Тем не менее, стоит отметить, что высокий уровень риска не обязательно указывает на злонамеренный умысел, поскольку он также учитывает непреднамеренно введенные уязвимости, так же как и выявляет преднамеренное вредоносное ПО.
В последующем комментарии Перес уточнил, что проверка безопасности «ищет те же классы уязвимостей, что и любой аудит безопасности», призывая разработчиков следовать стандартам кодирования WordPress и правилам PHP_CodeSniffer (PHPCS) для проверки своего кода и обеспечения его качества. Разработчикам, публикующим расширения WooCommerce, рекомендуется использовать платформу тестирования Quality Insights Toolkit (QIT).
Другие шаблоны, которые также могут повысить уровень риска, приведены ниже:
После блокировки выпуска единственный способ для разработчика снять ограничения — это просмотреть результаты, исправить проблемы и опубликовать новый выпуск. Если новый выпуск получит оценку ниже порога высокого риска, он продолжит обычный процесс охлаждения. «Если результат проверки выглядит некорректным, авторы могут связаться с командой плагинов», — сказал Перес. «Пожалуйста, поймите, что команда обрабатывает большой объем проверок, поэтому публикация исправленного выпуска почти всегда быстрее, чем ожидание ручной проверки апелляции».
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Ravie Lakshmanan
