WordPress 6.3.2 було випущено вчора, 12 жовтня 2023 року. Цей випуск містить низку виправлень безпеки та додатковий захист від уразливостей, які часто використовують.
Незважаючи на те, що всі вразливості мають середній рівень небезпеки, деякі з них достатньо сильні, щоб потенційно дозволити отримати повний доступ до вашого сайту.
Багато з цих патчів було портовано до більш старих версій WordPress, починаючи з 4.1, і лише деякі були застосовані до останньої версії, що знову ж таки підтверджує факт – актуальна версія вордпрес найбільш захищена.
WordPress підтримує автоматичне оновлення ядра для випусків системи безпеки, починаючи з WordPress 3.7, і переважна більшість сайтів на WordPress повинні автоматично отримати виправлення для основної версії WordPress протягом наступних 24 годин. Ми рекомендуємо перевірити, чи ваш сайт автоматично оновлено до однієї з виправлених версій.
Якщо ваш сайт не було оновлено автоматично, ми наполегливо рекомендуємо якнайшвидше оновити його вручну, оскільки одну з уразливостей, виправлених у цьому випуску, може використати зловмисник із обліковим записом на рівні учасника з низькими привілеями.
Нагадаю, якщо з будь-яких причин у вас виникне потреба відкотитися до попередніх версій, це зробити досить легко, ми описували як зробити даунгрейд вордпрес тут.
Як і в кожному новому випуску ядра WordPress, що містить виправлення безпеки, команда Wordfence Threat Intelligence детально проаналізувала зміни коду, щоб оцінити вплив цих вразливостей. Давайте коротко розглянемо, які проблеми знайдено та вирішено:
WordPress Core <= 6.3.1 – виконання довільного короткого коду.
WordPress був вразливий до виконання довільного короткого коду у версіях до 6.3.1 включно через відсутність перевірки введення параметра «shortcode» у функції AJAX parse_media_shortcode. Це дозволяє автентифікованим зловмисникам із правами підписник та вище виконувати довільні короткі коди.
WordPress Core 5.6-6.3.1 – міжсайтове виконання сценаріїв через запити пароля додатків
WordPress був вразливий до Reflected Cross-Site Scripting через параметри «success_url» і «reject_url» під час запиту паролів додатків у версіях між 5.6 і 6.3.1 через недостатню обробку вхідних даних (sanitize) та екранування вихідних даних псевдопротоколів URI. Це дає змогу неавтентифікованим зловмисникам вставляти на сторінки довільні веб-сценарії, які виконуються, якщо вони можуть успішно змусити користувача виконати певну дію, наприклад натиснути посилання та прийняти або відхилити пароль додатку.
WordPress Core <= 6.3.1 – доступ до конфіденційної інформації через коментарі до захищених публікацій
WordPress був вразливий до розкриття конфіденційної інформації у версіях до 6.3.1 включно через список коментарів. Це дозволяло автентифікованим користувачам із правами співавтора або вище переглядати коментарі до захищених публікацій. До WordPress 6.3.2 користувачі могли переглядати коментарі до публікацій, навіть якщо вони не мали до них доступу.
WordPress Core 4.7.0-6.3.1 – доступ до конфіденційної інформації через кінцеву точку REST пошуку користувачів
WordPress був вразливий до розкриття конфіденційної інформації у версіях від 4.7.0 до 6.3.1 через кінцеву точку у запиті до REST. Хоча в результатах пошуку не відображаються адреси електронної пошти користувачів, якщо користувач, який запитує, не має можливості «list_users», але все одно , оскільки пошук застосовується до стовпця user_email, це може дозволити неавтентифікованим зловмисникам застосувати Brute Force щоб перевірити електронні адреси користувачів.
WordPress Core 4.7.0-6.3.1 – відмова в обслуговуванні
WordPress був вразливий до помилки “відмова в обслуговуванні” через “отруєння” кешу у версіях від 4.7.0 до 6.3.1. У випадках, коли заголовок X-HTTP-Method-Override був надісланий у запиті до кінцевої точки REST і кінцева точка повернула помилку 4xx, помилка могла кешуватися, що призводило до відмови в обслуговуванні. Відповіді на запити REST API не кешуються для користувачів, які ввійшли в систему, але у WordPress до 6.3.2 в одному з випадків неавтентифікований зловмисник міг надіслати запит до REST API за допомогою X-HTTP-методу та перевизначити заголовок загальнодоступної кінцевої точки, через що отримати помилку 4xx , після чого REST обмежуватиме доступ, коли помилка кешується, і будь-які інші неавтентифіковані відвідувачі, які намагаються отримати дані з цієї кінцевої точки, побачать кешовану помилку 4xx.
WordPress Core 6.3-6.3.1 – міжсайтовий сценарій за допомогою блоку виносок
WordPress був вразливий до атаки через міжсайтові сценарії через блок Footnotes у версіях між 6.3 і 6.3.1 через недостатню обробку вхідних даних. Це давало змогу автентифікованим зловмисникам із дозволами рівня співавторів і вище впроваджувати на сторінки довільні веб-скрипти, які виконуватимуться щоразу, коли користувач отримує доступ до ін’єктованої сторінки.
WordPress Core 5.9-6.3.1 – міжсайтовий сценарій за допомогою атрибутів навігації
WordPress був вразливий до атаки через міжсайтові сценарії через атрибути навігаційного блоку зі стрілками у версіях від 5.9 до 6.3.1 через недостатню обробку вхідних даних та екранування вихідних даних. Це давало змогу автентифікованим зловмисникам із повноваженнями рівня співавторів і вище впроваджувати на сторінки довільні веб-скрипти, які виконуватимуться щоразу, коли користувач отримує доступ до ін’єктованої сторінки.
