Некоторые сайты WordPress по-прежнему могут быть атакованы во время установки исправления для активно используемой уязвимости, как сообщил Умут Байрам, исследователь Picus Security, обнаруживший ее. Обновление, устанавливающее исправление, по-прежнему распаковывает файлы, используя старый, неисправленный код сайта, поэтому злоумышленник, действующий в нужный момент, может выполнить код на сервере. Исследователь советует заблокировать веб-доступ к папке wp-content/upgrade сайта перед обновлением. Уязвимость, отслеживаемая как CVE-2026-119977, затрагивает WordPress версий с 4.7 по 7.1.3. Во время обновления ядра с использованием полного пакета WordPress распаковывает копию новой версии во временную папку внутри wp-content/upgrade. Эта копия включает установщик WordPress, и веб-сервер обычно может получить к ней доступ. Злоумышленник без учетной записи, который может определить имя папки и получить доступ к установщику до того, как WordPress удалит копию, может выполнить код на сервере. Агентство по кибербезопасности и защите инфраструктуры США (CISA) добавило эту уязвимость в свой каталог известных уязвимостей, используемых в настоящее время, ранее на этой неделе. WordPress выпустила исправление на прошлой неделе в версии 7.1.4 и в соответствующих обновлениях для старых ветвей, начиная с 4.7, все они перечислены в ее консультативном уведомлении по безопасности. Исправление присваивает временной папке случайное имя. Однако обновление, устанавливающее исправление, распаковывает файлы, используя старый код, уже имеющийся на сайте, как показывает код обновления WordPress. На сайтах, работающих под управлением версии 5.9 или более поздней, этот старый код называет папку по имени загруженного файла, поэтому имя можно предсказать в последний раз. До исправления злоумышленник мог использовать установщик для записи нового файла конфигурации, wp-config.php, во временную копию. Затем обновление перезаписало бы реальный файл сайта этим файлом. Часть исправления, которая останавливает это, уже работает во время обновления, устанавливающего его, поскольку WordPress копирует файлы на место, используя новый код. Байрам в своем техническом описании заявляет, что злоумышленник, который воспользуется этим окном во время обновления, все еще может настроить временную копию WordPress со своей собственной базой данных, войти в нее и выполнить PHP-код с разрешениями веб-сервера до удаления копии. Оттуда злоумышленник может читать или записывать файлы на реальном сайте WordPress. Исследователь отмечает, что не каждое обновление раскрывает установщик. Полные пакеты всегда включают файлы установщика. Небольшой частичный пакет, созданный для одной конкретной начальной версии, раскрывает сайт только в том случае, если он случайно содержит эти файлы. На сайтах, где включены автоматические фоновые обновления, WordPress устанавливает исправление автоматически, используя тот же механизм обновления и те же шаги. The Hacker News проверила службу обновлений WordPress.org сегодня для нескольких версий. Для обновлений в пределах ветви, например, с 7.1.3 до 7.1.4, предлагался частичный пакет, в том числе для автоматических обновлений. Для перехода из старой ветви, например, с 7.0.7 до 7.1.4, предлагался только полный пакет. На версиях с 4.4 по 5.8 старый код добавляет случайные символы к имени папки. Это скрывает имя, если только сайт не раскрывает его каким-либо другим способом, например, в сообщении об ошибке, говорит исследователь. После установки 7.1.4 или исправления ветви последующие обновления используют случайное имя папки, а файл wp-config.php во временной копии никогда не копируется поверх реального. Первая рекомендация исследователя — полностью запретить веб-серверу доступ к wp-content/upgrade. Он отмечает, что WordPress работает с этой папкой непосредственно на диске, поэтому блокировка веб-доступа не нарушает обновления. Другой безопасный путь, по его словам, — это ручное обновление, выполненное вне корневой директории веб-сервера. Сделайте резервную копию файлов сайта и базы данных, распакуйте новый выпуск в папку, которую веб-сервер не обслуживает, скопируйте основные файлы на место, не затрагивая wp-config.php или wp-content, а затем запустите обновление базы данных WordPress. Таким образом, временный установщик никогда не будет создан в папке, доступной через веб. Команда WP-CLI `wp core update` не является заменой, поскольку она использует тот же механизм обновления и распаковывает пакет в ту же папку. WordPress 4.6 и более ранние версии больше не получают обновлений безопасности, поэтому для них нет исправления. Исследователь говорит, что уязвимость восходит к WordPress 2.7, выпущенной в 2008 году, и что эти сайты следует перевести на поддерживаемую версию. Добавление CISA в каталог ранее на этой неделе было основано на доказательствах активной эксплуатации, но агентство не описало атаки. Wordfence, компания по безопасности WordPress, присвоившая идентификатор CVE, зафиксировала попытки атак через девять минут после развертывания правила межсетевого экрана для этой уязвимости в день выпуска. Два наиболее активных источника проверяли небольшие группы сайтов в течение примерно 14,5 часов, что, по мнению компании в ее анализе атак, соответствует попыткам поймать момент обновления сайта. Ее оценка уязвимости в записи CVE составляет 8,1 из 10 по шкале CVSS. В лабораторных тестах окно уязвимости длилось всего несколько секунд. Собственное консультативное уведомление WordPress оценивает уязвимость как низкую. Код, который его авторы описывают как эксплойт для уязвимости, появился в общедоступных репозиториях GitHub с начала этой недели. Один из них утверждает, что его код также работает на сайтах, которые все еще используют предсказуемую папку при обновлениях полных пакетов. Работает ли код, не установлено. Для сайтов, оставшихся на затронутой версии после выпуска, Wordfence предлагает следующее: Байрам сообщил The Hacker News 6 ноября, что наличие частичного обновления зависит от того, что содержит конкретный пакет. Частичный пакет содержит только файлы, которые изменились между двумя выпусками. Если они не включают файлы установщика, временная копия не может быть запущена как установка WordPress, и установщик никогда не станет доступен. Сайт также не всегда получает частичный пакет, когда он существует. WordPress возвращается к полному пакету, если основные файлы сайта не соответствуют официальным контрольным суммам или если обновление является переустановкой. Решающим фактором, по словам исследователя, является не “частичный против полного”. Это “исправлен ли установщик, уже установленный на сайте”.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Swati Khandelwal
