Оновлення безпеки WordPress 7.1.4 було випущено 28 жовтня 2026 року. WordPress рекомендує встановити його якнайшвидше, оскільки цей випуск усуває проблеми безпеки в програмному забезпеченні, на якому працює сайт. Якщо ваша компанія використовує WordPress, попросіть відповідального за його обслуговування підтвердити встановлену версію, організувати належне оновлення та перевірити, чи можуть клієнти після цього надсилати запити або робити покупки.

Це завдання з обслуговування наявного сайту. Оголошення не повідомляє, чи оновилася саме ваша інсталяція та чи зазнавала вона атаки. Відповіді на ці питання потребують доказів із цієї інсталяції.

Що змінює оновлення безпеки WordPress

Випуск усуває проблеми в самому WordPress. У докладній документації перелічено проблеми зі збереженими скриптами, дозволами на вміст і процесом оновлення, причому для різних виявлених проблем діють різні передумови. Збережений скрипт - це небажаний код, збережений у вмісті та згодом запущений у браузері; умови щодо дозволів важливі для пояснення того, хто міг би його додати.

У технічному аналізі Patchstack зазначено, що більшість перелічених проблем потребує облікового запису WordPress із дозволом створювати або редагувати вміст. Там також описано вразливість, яка за певних умов може дозволити зловмиснику запустити код під час оновлення. Ми передали б відповідальному за обслуговування повідомлення про випуск і попросили б підтвердити встановлену версію та повідомити про будь-яку помилку оновлення. Ці висновки не доводять, що кожен відвідувач може скористатися кожною проблемою.

Чи справді ваш сайт оновлено?

Підтвердьте версію, що працює в інсталяції, яка обслуговує домен вашої компанії. WordPress документує фонові оновлення безпеки для сайтів, що відповідають вимогам, але на них можуть впливати конфігурація та умови хостингу. Перевірте встановлену версію, щоб з’ясувати, чи отримала ця інсталяція оновлення. Відповідність вимогам до фонового оновлення та налаштування описують передбачений процес, але не доводять його завершення.

Запитайте хостинг-провайдера або відповідального за обслуговування, чи стосується їхнє підтвердження встановленого оновлення самого WordPress, чи захисного правила хостингу. Примітка до випуску Pantheon наводить корисний приклад: у ній сказано, що платформа додала захисні правила проти деяких зовнішніх зловживань, але водночас і далі просить клієнтів оновлювати свої сайти. Це твердження стосується Pantheon і не є доказом щодо іншого хостинг-провайдера.

Три перевірки розрізняють захисне правило хостингу, встановлений патч WordPress і робочий шлях запиту або покупки.
Запитайте, які докази надано; ці перевірки відповідають на різні питання.

Що попросити зробити відповідального за обслуговування

Попросіть відповідального за обслуговування записати встановлену версію та перевірити основну дію, яку клієнти виконують на сайті. Ми скористалися б наведеними нижче кроками, щоб узгодити, що ця особа зробить і що ви перевірите після цього. Ці перевірки не означають, що відомо про порушення роботи форм або платежів через це оновлення.

  1. Назвіть сайт і відповідального за обслуговування. Надішліть домен компанії та запитайте, хто застосує оновлення. Якщо обслуговування виконує хостинг-провайдер, скористайтеся його усталеним процесом підтримки або розгортання. Запишіть версію до зміни та версію, яку планують установити.
  2. Визначте придатну резервну копію. У посібнику WordPress із резервного копіювання сказано, що для типового повного відновлення потрібні і база даних, і файли. Запитайте, коли створення цієї копії завершилося, де вона зберігається і хто може її відновити. Для активного магазину запитайте, як під час відновлення буде опрацьовано замовлення, отримані після створення копії. Оновлення та резервні копії слід поєднувати в межах обслуговування сайту.
  3. Застосуйте задокументоване оновлення. WordPress указує стандартний шлях: Майстерня > Оновлення > Оновити зараз. Уповноважений відповідальний має скористатися шляхом, що відповідає конфігурації хостингу. Якщо на екрані з’явиться помилка або запит незнайомих облікових даних, надішліть цій особі точне повідомлення замість спроби вгадати налаштування сервера.
  4. Підтвердьте встановлену версію та перевірте шлях запиту або покупки. Запросіть остаточну версію WordPress. Потім надішліть погоджений тестовий запит і підтвердьте, що він надійшов до очікуваної поштової скриньки або запису клієнта. Сторінка з повідомленням про надсилання форми залишає етап доставки неперевіреним; у нашому посібнику про звернення, втрачені між сайтом і відділом продажів пояснено цю передачу. Якщо сайт продає товари чи послуги, уповноважений оператор має перевірити оформлення покупки за допомогою усталеного безпечного процесу тестування без ненавмисного списання коштів.
  5. Збережіть короткий запис про завершення. Запишіть сайт, остаточну версію, час оновлення, ідентифікатор резервної копії, відповідальну особу, результат перевірки та всі винятки, що залишаються відкритими. Якщо форма передає дані в систему роботи з клієнтами, включіть до перевірки запис призначення як частину інтеграції форм і CRM.
Дерево рішень розділяє підтверджений патч, заблоковане оновлення та підозрілі зміни, які треба розслідувати.
Запишіть версію та результат і вкажіть, хто розв'яже кожну відкриту проблему.

Якщо сайт використовує старішу версію WordPress

Перш ніж запитувати про цільову версію, повідомте відповідальному за обслуговування поточну версію. На сторінці з докладними відомостями про випуск WordPress перелічено виправлення для старіших версій, зокрема 7.0.8 і 6.9.11. Там також сказано, що активно підтримується лише найновіша версія. Виправлення безпеки, надане для старішої версії, є окремим рішенням від переходу на поточну версію з активною підтримкою.

Попросіть відповідального за обслуговування підтвердити, яке оновлення безпеки стосується встановленої версії, і визначити роботи, потрібні для переведення сайту на поточну версію. Патч для старішої версії не обіцяє подальшої повної підтримки.

Що робити, якщо оновлення не вдалося або сайт виглядає скомпрометованим?

Якщо оновлення не вдалося, надішліть відповідальному за обслуговування або хостинг-провайдеру точний текст помилки та час її появи. Підозрілі зміни потребують окремого розслідування: рекомендації WordPress щодо зламаного сайту починаються з документування проблеми та часу її виникнення. Саме лише застосування оновлення не може пояснити, як з’явився невідомий обліковий запис адміністратора, або визначити, чи були зачеплені дані клієнтів.

Ми залишили б ці винятки видимими в записі про завершення.

Поширені запитання

Коли було випущено WordPress 7.1.4?
WordPress випустив оновлення безпеки 28 жовтня 2026 року та рекомендує встановити його якнайшвидше. Попросіть особу, яка обслуговує ваш сайт, підтвердити встановлену версію.
Чи означають автоматичні оновлення, що на сайті вже встановлено патч?
Вони могли встановити оновлення, але відповідність вимогам або ввімкнене налаштування не доводять завершення. Перевірте встановлену версію WordPress або попросіть підтвердження в хостинг-провайдера чи відповідального за обслуговування.
Чи потребує цей випуск безпеки редизайну сайту?
Оголошення стосується виправлень безпеки самого WordPress. Ми розглядали б редизайн окремо й попросили б відповідального за обслуговування визначити роботи із сумісності, потрібні для оновлення.
Чи доводить встановлення патча, що сайт не було зламано?
Ні. Версія з патчем підтверджує встановлення оновлення програмного забезпечення. Вона не визначає, чи був сайт скомпрометований. Повідомте про підозрілі зміни хостинг-провайдеру або відповідальному за обслуговування для розслідування.

← Усі статті