WordPress 7.0.4 закрывает дыру в обработке картинок

12 августа 2026 года вышел WordPress 7.0.4. Это обновление безопасности, и WordPress прямо советует обновить сайты немедленно. Закрывают одну дыру, зато серьёзную: чужой код может выполниться на вашем сервере через обычную загрузку файла. Оценка серьёзности 8.8 из 10, уровень High, идентификаторы CVE-2026-65640 и GHSA-8vr3-7mxf-gx8w.

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

И сразу о том, чего в этой новости нет. Ни в анонсе релиза, ни в описании уязвимости на GitHub, ни в техническом разборе нет ни слова о том, что дыру уже используют против реальных сайтов. Паниковать не из-за чего, надо просто обновиться.

Касается ли это вашего сайта

Здесь главное не проскочить мимо слова «и». Чтобы дыра сработала, нужны два условия одновременно.

Первое. На сервере используются Imagick и Ghostscript — именно так сформулировано в описании уязвимости, а слабое место лежит в том, как Ghostscript обрабатывает определённые вложенные файлы. Imagick — это библиотека, которой сайт может обрабатывать загруженные картинки. Ghostscript — движок, умеющий читать PDF и PostScript.

Второе. У злоумышленника должна быть учётная запись на вашем сайте с ролью «Автор» или выше. Технически речь о праве upload_files, то есть о возможности загружать файлы в медиатеку.

Оба условия — не «или», а «и». Прямой фразы «Imagick без Ghostscript безопасен» на страницах WordPress нет, и выдумывать её мы не станем: по формулировке описания уязвимости нужны оба компонента.

Теперь о версиях. Уязвимы все WordPress от 4.7.0 до 7.0.3 включительно, то есть почти вся современная история системы. Исправления выпустили сразу в 24 версиях разных веток: 7.0.4, 6.9.7, 6.8.8, 6.7.7, 6.6.7, 6.5.10, 6.4.10, 6.3.10, 6.2.11, 6.1.12, 6.0.14, 5.9.16, 5.8.15, 5.7.17, 5.6.19, 5.5.20, 5.4.21, 5.3.23, 5.2.26, 5.1.24, 5.0.27, 4.9.31, 4.8.30 и 4.7.35. То есть если вы сидите на 6.4 и переход на новую большую версию вас пугает, вам нужна 6.4.10, и этого достаточно.

Патч дошёл и до ветки 7.1, которая ещё в разработке, в её предрелизную сборку RC3.

А вот отдельной строкой то, что стоит прочитать дважды. WordPress 4.6 и старше обновлений безопасности больше не получают. Вообще. Если ваш сайт на такой версии, текущая дыра не главная ваша проблема, и закрывать её обновлением ядра уже некуда. Там вопрос шире — переезд сайта на поддерживаемую версию WordPress, а не один патч.

Как проверить самому, не трогая сервер

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

Откройте Инструменты → Здоровье сайта → Информация (Tools → Site Health → Info). Найдите раздел Media handling, то есть «обработка медиафайлов». Оба нужных поля лежат именно там, поэтому проверка делается за один заход.

Поле Active editor. Оно показывает, чем сайт обрабатывает картинки. Типичное значение — WP_Image_Editor_GD, это библиотека GD. Если вы видите WP_Image_Editor_Imagick, сайт работает через Imagick, и первое условие выполнено.

Строка Ghostscript version. Она показывает установленную версию Ghostscript и появляется только тогда, когда Ghostscript вообще доступен. Нет строки — нет и второго условия.

Пока вы на этой же странице, прокрутите до раздела WordPress. Там есть поле User count, сколько на сайте пользователей, и поле Can anyone register on this site?, открыта ли регистрация. Это прямой и честный способ ответить на вопрос «а откуда у меня вообще чужие авторы».

Что значит «Автор или выше» для обычного сайта

Роль «Автор» в WordPress — это человек, который может публиковать свои материалы и загружать файлы. Не администратор. Именно поэтому уязвимость и считают серьёзной: право, которое обычно раздают довольно свободно, позволяло дойти до выполнения кода на сервере.

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

Механика дыры, если интересно. В техническом разборе CybersecurityNews её объясняют так: ImageMagick определяет тип файла по его реальному содержимому, а WordPress в методе WP_Image_Editor_Imagick::load() по большей части доверял расширению файла. На этом расхождении атака и строилась: файл выглядел как картинка, а внутри был другим. Патч переписывает загрузку так, чтобы проверять реальное содержимое файла перед тем, как отдать его Imagick.

Почему обновление безопасности здесь не страшное

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

Обновление затрагивает ровно один файл ядра, wp-includes/class-wp-image-editor-imagick.php. И отдельной строкой в документации версии стоит: ни один пакет не пересматривали. То есть это не переезд на новую ветку с новыми библиотеками, а точечная замена одного файла.

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

Обновиться можно двумя официальными дорогами. Из админки, в разделе «Консоль → Обновления», или скачав релиз с сайта WordPress вручную.

Обновится ли сайт сам

Скорее всего, да. Но без гарантий и без сроков.

WordPress пишет: сайты с поддержкой фоновых автообновлений начнут обновляться вскоре. Никаких часов или дней в анонсе релиза нет, так что если где-то вы прочитали конкретный срок — это уже чья-то оценка, а не позиция WordPress.

Исторически шансы на вашей стороне. До версии 5.6 у каждого сайта автообновления были включены по умолчанию для минорных релизов ядра и файлов переводов. Начиная с 5.6, у новых установок по умолчанию включены и минорные, и мажорные автообновления.

Проблема в том, что подрядчики их нередко выключают, чтобы «ничего не сломалось само собой». Если у вас есть доступ к файлам сайта, в wp-config.php стоит поискать две вещи.

Первая — строка define( 'AUTOMATIC_UPDATER_DISABLED', true );. Она выключает автообновления полностью.

Вторая — константа WP_AUTO_UPDATE_CORE. У неё три значения: true включает все обновления ядра, false выключает все, а 'minor' оставляет только минорные. Для патчей безопасности годятся первое и третье. false означает, что патч не приедет никогда.

Не хотите лезть в файлы — не лезьте. Просто зайдите в «Обновления» в админке и посмотрите на версию. Если там уже 7.0.4 или соответствующее число вашей ветки, вопрос закрыт.

Если обновиться прямо сейчас невозможно

Бывает: сайт на старой версии PHP, куча кастомного кода, релиз назначен на следующую неделю. Тогда есть обходной путь, и лежит он не в WordPress, а на уровне сервера.

Идея в том, чтобы отключить в ImageMagick именно те кодеки, через которые вызывается Ghostscript: PS, EPS, PDF и XPS. Кодек здесь — модуль, отвечающий за конкретный формат файла. Рекомендация давняя и авторитетная: её в своё время высказал Тавис Орманди из Google Project Zero в рассылке oss-security, предлагая отключать эти кодеки в policy.xml по умолчанию.

Конкретных строк конфигурации мы здесь не приводим сознательно. Страница ImageMagick о политике безопасности на момент написания недоступна, а копировать XML из чужих пересказов в боевой сервер — плохая идея. Правильная формулировка задачи для хостера или разработчика звучит так: «отключите кодеки PS, EPS, PDF и XPS в policy.xml ImageMagick». Человек, который администрирует ваш сервер, поймёт с полуслова. А если такого человека у вас нет, то это рядовая задача для тех, кто держит сайт на технической поддержке.

И это решение временное. Обновление ядра оно не заменяет.

Частые вопросы

Что дальше

Обновление безопасности WordPress 7.0.4 — редкий случай, когда работа занимает пять минут, а цена бездействия высока. Проверить два поля в «Здоровье сайта», сделать бэкап, нажать «Обновить». Всё.

Проблема обычно не в этом обновлении, а в том, что следующее выйдет через месяц, а смотреть на него некому. Именно это закрывает техническая поддержка сайта: бэкапы, обновления ядра и плагинов, реакция на падения. Если сайт давно живёт сам по себе и вы не уверены даже в версии ядра — напишите нам, посмотрим вместе.

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