--- title: "WordPress 7.0.4 закриває дірку в обробці картинок" description: "12 серпня вийшов WordPress 7.0.4. Ризик є лише там, де сервер працює через Imagick і Ghostscript — перевірте два поля у «Стані сайту» й оновіться." url: https://apri-code.com/blog/wordpress-7-0-4-imagick-rce/ language: uk 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/poslugy/rozrobka-saytiv/wordpress/), а не один патч. ## Як перевірити самому, не чіпаючи сервер ![Два поля, чотири комбінації, один вердикт](https://apri-code.com/api/media/file/wp-imagick-selfcheck-uk.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/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/poslugy/pidtrymka/): бекапи, оновлення ядра й плагінів, реакція на падіння. Якщо сайт давно живе сам по собі й ви не впевнені навіть у версії ядра — [напишіть нам](https://apri-code.com/kontakty/), подивимось разом. А якщо ви тільки плануєте сайт і зважуєте, на чому його робити, почніть із розбору, [як створити сайт на WordPress](https://apri-code.com/blog/yak-stvoryty-sayt-na-wordpress/) і що потім доведеться обслуговувати. Ми працюємо з ним щодня і чесно розповідаємо, коли [розробка на WordPress](https://apri-code.com/poslugy/rozrobka-saytiv/wordpress/) підходить, а коли краще взяти інший інструмент. --- Source: https://apri-code.com/blog/wordpress-7-0-4-imagick-rce/