WordPress 7.0.4: критическая RCE через PNG с PostScript внутри

WordPress выпустил версию 7.0.4 — обновление, закрывающее критическую уязвимость удалённого выполнения кода (RCE) на сайтах, обрабатывающих изображения через расширение Imagick и Ghostscript. Команда безопасности WordPress настоятельно рекомендует обновиться немедленно: через экран Updates в панели администратора или загрузив релиз напрямую с WordPress.org. Сайты с включёнными фоновыми обновлениями уже должны получать патч автоматически.

Суть уязвимости CVE-2026-65640

Проблема, отслеживаемая как CVE-2026-65640 и описанная в GHSA-8vr3-7mxf-gx8w, была обнаружена исследователями из pwn.ai. Она позволяет аутентифицированному пользователю с ролью Author выполнить произвольный код через специально сформированную загрузку файла.

Причина — в том, как WordPress полагается на ImageMagick при изменении размера и обработке изображений в библиотеке медиафайлов. ImageMagick не ограничивается JPEG и PNG: он также открывает PostScript, EPS и PDF, а для рендеринга этих форматов передаёт работу Ghostscript — инструменту с долгой историей выполнения непредусмотренных команд. Специалисты по безопасности узнают в этом семейство ошибок, стоявших за печально известными уязвимостями ImageTragick.

Корень проблемы — расхождение в определении типа файла. ImageMagick определяет тип по фактическому содержимому, а метод WP_Image_Editor_Imagick::load() в WordPress в значительной степени доверял расширению файла. Файл с безобидным именем holiday.png мог на самом деле содержать код PostScript, пройти проверки загрузки и попасть в Imagick, который распознал бы встроенный PostScript и вызвал Ghostscript для его выполнения.

Как обходились проверки

Обычно функция wp_check_filetype_and_ext() ловит такое несоответствие при стандартной загрузке, но не все пути загрузки проходят через эту проверку:

  • метод XML-RPC wp.uploadFile;
  • процедура извлечения обложки для загружаемых MP3-файлов.

Оба пути записывают байты напрямую через wp_upload_bits(), минуя проверку содержимого, что даёт атакующему обходной маршрут для размещения вредоносной нагрузки.

Что делает патч

Исправление, выпущенное в коммите 7daaa50, переписывает метод load() так, чтобы он проверял фактическое содержимое файла до создания объекта Imagick. Новый код сканирует первый фрагмент каждого загружаемого файла и блокирует:

  • всё, что несёт сигнатуры PostScript или EPS;
  • поддельные PDF, заявляющие расширение, но не имеющие настоящего заголовка %PDF-;
  • сжатые файлы (gzip, bzip2), которые ImageMagick иначе молча распаковал бы.

Патч также закрывает более хитрый приём: атакующие могли добавлять к имени файла префикс с указанием формата, например EPS:innocent.png, чтобы принудить ImageMagick к опасному декодеру. Новый код удаляет и проверяет такие префиксы, аккуратно избегая ложных срабатываний на буквах дисков Windows, и применяет ту же проверку к именам файлов, поступающим через удалённые URL или потоки.

Кто в зоне риска

Эксплуатация требует доступа уровня Author или выше, так что это не неаутентифицированная атака «на лету». Реальный риск сильно зависит от того, у кого есть учётные записи на сайте:

  • многопользовательские издания;
  • платформы с подпиской;
  • клиентские сайты с открытой или слабо управляемой регистрацией.

На таких ресурсах любой Author может попытаться загрузить файл-ловушку под видом изображения. Сайты с небольшим доверенным составом редакции несут сравнительно низкий риск.

Обновление и поддержка

По данным WordPress, исправления портируются в ветку 4.7 и в грядущий релиз 7.1 RC3, однако полную поддержку получает только последняя версия. Администраторам следует проверить свою версию и обновиться без промедления, особенно на сайтах, где права загрузки выходят за пределы основного доверенного круга.

Схожая по механике проблема — XSS в WordPress, ведущая к выполнению PHP-кода без аутентификации — тоже требовала немедленного обновления. Администраторам стоит держать в поле зрения и SQL-инъекцию в Metabase, дающую доступ администратора без аутентификации.

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

Кого касается эта уязвимость?

Сайты WordPress, которые обрабатывают изображения через расширение Imagick, особенно многопользовательские проекты, где права Author выданы широкому кругу лиц.

Как проверить, уязвим ли мой сайт?

Проверьте версию WordPress в панели администратора. Если она ниже 7.0.4 — сайт уязвим, если только патч не портирован в вашу ветку.

Что делать, если у меня включены автоматические обновления?

Проверьте, что обновление действительно установилось: перейдите в «Консоль» → «Обновления» и убедитесь, что версия 7.0.4 или новее.

Может ли атаковать пользователь без регистрации?

Нет, для эксплуатации нужна учётная запись с ролью Author или выше. Неаутентифицированная атака невозможна.

Защищает ли патч от всех вариантов атаки?

Патч закрывает известные векторы: PostScript, EPS, поддельные PDF и сжатые файлы, а также префиксы форматов. Но лучшая защита — ограничить круг пользователей с правом загрузки файлов.

Нужно ли отключать Imagick?

Если обновление невозможно, временной мерой может быть отключение Imagick в пользу GD-библиотеки, но это изменит качество обработки изображений. Основное решение — установить WordPress 7.0.4.

Работает ли атака через XML-RPC?

Да, метод wp.uploadFile — один из обходных путей, который патч закрывает. Если XML-RPC не используется, его стоит отключить как дополнительную меру.

Источник: cybersecuritynews.com