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 підходить, а коли краще взяти інший інструмент.