--- title: "WordPress 7.0.4 закрывает дыру в обработке картинок" description: "12 августа вышел WordPress 7.0.4. Риск есть только там, где сервер работает через Imagick и Ghostscript — проверьте два поля в «Здоровье сайта» и обновитесь." url: https://apri-code.com/ru/blog/wordpress-7-0-4-imagick-rce/ language: ru published: 2026-08-13 updated: 2026-08-13 author: "Богдан Кононенко" publisher: Apricode --- # 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](https://apri-code.com/ru/poslugy/rozrobka-saytiv/wordpress/), а не один патч. ## Как проверить самому, не трогая сервер ![](https://apri-code.com/api/media/file/wp-imagick-selfcheck-ru.svg) Оба условия риска видны в админке. Лезть на сервер, звонить хостеру и писать подрядчику для первой проверки не нужно. Откройте **Инструменты → Здоровье сайта → Информация** (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. ## Почему обновление безопасности здесь не страшное ![](https://apri-code.com/api/media/file/inline-wp704-odyn-arkush.webp) Главный страх владельца понятен: «обновлю — и что-нибудь отвалится». В этом конкретном релизе аргументов против него больше, чем обычно. Обновление затрагивает **ровно один файл ядра**, `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 или соответствующее число вашей ветки, вопрос закрыт. ## Если обновиться прямо сейчас невозможно ![](https://apri-code.com/api/media/file/inline-wp704-zaglushky.webp) Бывает: сайт на старой версии PHP, куча кастомного кода, релиз назначен на следующую неделю. Тогда есть обходной путь, и лежит он не в WordPress, а на уровне сервера. Идея в том, чтобы отключить в ImageMagick именно те кодеки, через которые вызывается Ghostscript: PS, EPS, PDF и XPS. Кодек здесь — модуль, отвечающий за конкретный формат файла. Рекомендация давняя и авторитетная: её в своё время высказал Тавис Орманди из Google Project Zero в рассылке oss-security, предлагая отключать эти кодеки в `policy.xml` по умолчанию. Конкретных строк конфигурации мы здесь не приводим сознательно. Страница ImageMagick о политике безопасности на момент написания недоступна, а копировать XML из чужих пересказов в боевой сервер — плохая идея. Правильная формулировка задачи для хостера или разработчика звучит так: «отключите кодеки PS, EPS, PDF и XPS в policy.xml ImageMagick». Человек, который администрирует ваш сервер, поймёт с полуслова. А если такого человека у вас нет, то это рядовая задача для тех, кто [держит сайт на технической поддержке](https://apri-code.com/ru/poslugy/pidtrymka/). И это решение временное. Обновление ядра оно не заменяет. ## Частые вопросы ### Как понять, использует ли мой сайт Imagick и Ghostscript? Инструменты → Здоровье сайта → Информация → раздел Media handling. Поле Active editor со значением `WP_Image_Editor_Imagick` и наличие строки Ghostscript version — это и есть два условия риска. ### Какая версия безопасна, если у меня 6.8 или 6.4? Для ветки 6.8 — это 6.8.8, для 6.4 — 6.4.10. Исправления выпущены в 24 версиях вплоть до 4.7.35, так что переходить на 7.0 ради этого патча не обязательно. ### Что делать, если сайт на очень старой версии? Если это WordPress 4.6 или старше — обновления безопасности для него больше не выпускают, и вопрос уже не в одном патче, а в переезде на поддерживаемую версию. ### Может ли обновление сломать сайт? Списка известных проблем совместимости WordPress не публикует, а изменён ровно один файл ядра. Но резервную копию сайта и базы делайте до обновления: без неё, по словам самого хендбука, успешный откат почти невозможен. ### Надо ли что-то делать, если у меня нет чужих авторов? Риск в таком случае ниже, потому что для атаки нужна учётная запись с правом загружать файлы. Это аргумент не спешить паниковать, а не повод не обновляться: пароли утекают, а старые доступы остаются. ### Взломали ли уже чьи-то сайты через эту дыру? В релизе, в описании уязвимости и в техническом разборе, которые мы читали, нет ни одного утверждения об активной эксплуатации. Поэтому и мы такого не утверждаем. ## Что дальше Обновление безопасности WordPress 7.0.4 — редкий случай, когда работа занимает пять минут, а цена бездействия высока. Проверить два поля в «Здоровье сайта», сделать бэкап, нажать «Обновить». Всё. Проблема обычно не в этом обновлении, а в том, что следующее выйдет через месяц, а смотреть на него некому. Именно это закрывает [техническая поддержка сайта](https://apri-code.com/ru/poslugy/pidtrymka/): бэкапы, обновления ядра и плагинов, реакция на падения. Если сайт давно живёт сам по себе и вы не уверены даже в версии ядра — [напишите нам](https://apri-code.com/ru/kontakty/), посмотрим вместе. А если вы только планируете сайт и взвешиваете, на чём его делать, начните с разбора, [как создать сайт на WordPress](https://apri-code.com/ru/blog/yak-stvoryty-sayt-na-wordpress/) и что потом придётся обслуживать. Мы работаем с ним каждый день и честно рассказываем, когда [разработка на WordPress](https://apri-code.com/ru/poslugy/rozrobka-saytiv/wordpress/) подходит, а когда лучше взять другой инструмент. --- Source: https://apri-code.com/ru/blog/wordpress-7-0-4-imagick-rce/