Якщо ви отримали від мене листа з посиланням на цю сторінку, то тому, що ваш сайт, судячи з усього, використовує версію плагіна Events Manager (плагін WordPress events-manager від Marcus Sykes / wp-events-plugin.com), яка потрапляє в уражений діапазон відомої проблеми безпеки. На цій сторінці пояснюється, у чому полягає проблема, як з’ясувати, чи стосується вона взагалі вашого сайту, і як оновитися.

Перш за все, найважливіший факт про це повідомлення: версія в ураженому діапазоні сама по собі не означає, що ваш сайт вразливий. Проблему, описану нижче, можна експлуатувати лише тоді, коли Events Manager налаштований приймати бронювання від відвідувачів, які не увійшли в систему (режим плагіна “No-User-Account Booking Mode”, тобто бронювання без облікового запису). Якщо ваш сайт вимагає облікового запису для бронювання або взагалі не приймає бронювань, він, найпевніше, не є вразливим навіть на ураженій версії. Я можу прочитати версію вашого плагіна з публічних файлів, але не бачу вашої конфігурації бронювання, тому це повідомлення є запобіжним попередженням, а не підтвердженим висновком щодо вашого сайту.

Ця проблема: CVE-2026-12987, неавтентифіковане впровадження PHP-об’єктів, що призводить до SQL-ін’єкції в системі бронювання плагіна. Орган, який присвоїв CVE, не опублікував оцінку серйозності; Patchstack оцінює той самий висновок у 8,8 з 10 (висока). Вона зачіпає версії з 4.0.0 до 7.3.6 і усунена у версії 7.3.7. Якщо ви використовуєте уражену версію, оновіть Events Manager до 7.3.7 або новішої (рекомендується поточний випуск лінійки 7.4.x). Немає жодних ознак того, що цю проблему десь експлуатують.

Кілька слів про терміновість, оскільки це найбільш умовне повідомлення з тих, які я надсилав: наскільки це важливо для вас, залежить майже виключно від того налаштування бронювання. Якщо бронювання на вашому сайті вимагають входу в систему, оновлення є звичайним обслуговуванням плагіна. Якщо ваш сайт все ж приймає публічні бронювання від відвідувачів без облікового запису, будь ласка, поставтеся до оновлення як до пріоритету: у такій конфігурації вада могла б дозволити зловмиснику читати дані з бази даних вашого сайту (наприклад, хеші паролів і секретні ключі) без входу в систему. Навіть тоді ця сторінка є запобіжним попередженням, а не звітом про інцидент, і жодних екстрених заходів не передбачається.

Це вада плагіна, а не ядра WordPress. Повністю актуальний WordPress не захищає вас, якщо сам плагін Events Manager перебуває на ураженій версії.

Чи є це повідомлення справжнім?

Так. Це добросовісне повідомлення в рамках відповідального розкриття інформації від незалежного дослідника безпеки. Я не прошу у вас грошей, паролів чи доступу до вашого сайту і не намагався проникнути до нього, щось завантажити чи щось експлуатувати.

Усе, що я зробив: переглянув публічно доступні файли, які ваш сайт надає кожному відвідувачу (так само, як публічна ваша головна сторінка), і зазначив номер версії, який плагін Events Manager публікує у своєму публічному файлі readme.txt. Системи бронювання я спеціально не торкався, і ніщо в цій перевірці не зачіпає ваші дані, вашу адміністративну панель чи будь-яку приватну частину вашого сайту (докладніше в розділі Що я робив і чого не робив нижче).

Якщо ви хочете переконатися в тому, хто я, ознайомтеся з контактними даними внизу цієї сторінки та на сторінці Про мене.

Чому це важливо

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

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

Дві речі допомагають зберегти правильну перспективу. По-перше, точкою входу є публічна форма бронювання, тому атака працює лише там, де відвідувач, який не увійшов у систему, може надіслати бронювання. Це саме та передумова “No-User-Account Booking Mode”: якщо бронювання на вашому сайті вимагає облікового запису, вразливий шлях недоступний для анонімних відвідувачів, і ваш сайт, найпевніше, не є вразливим навіть на ураженій версії. По-друге, це проблема читання даних, а не захоплення сервера чи адміністратора: вона сама по собі не дозволяє зловмиснику виконувати код на вашому сервері чи входити до вашої адміністративної панелі. І, повторюючи це прямо, немає жодних ознак активної експлуатації: її немає в каталозі відомих експлуатованих вразливостей CISA, її оцінка ймовірності експлуатації (EPSS) близька до нуля, і мені не відомо про жодні повідомлення про експлуатацію.

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

Чи стосується це мене?

Це визначають два питання, у такому порядку.

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

  • Якщо бронювання на вашому сайті вимагають облікового запису або входу в систему, або ваш сайт взагалі не приймає бронювань, ви, найпевніше, не є вразливими, навіть на ураженій версії. Оновлення все одно рекомендується як звичайне обслуговування.
  • Якщо ваш сайт приймає бронювання від відвідувачів без облікового запису (Events Manager називає це “No-User-Account Booking Mode”), проблема стосується вас, і вам слід оновитися невідкладно.
  • Щоб перевірити: в адмініструванні WordPress знайдіть у налаштуваннях бронювання Events Manager параметр, який дозволяє бронювання без облікового запису. Або просто перевірте це ззовні: відкрийте одну зі своїх сторінок подій у вікні приватного перегляду й подивіться, чи можете ви заповнити та надіслати бронювання, не отримавши запиту на вхід у систему.

Друге: яку версію ви використовуєте? Вам не обов’язково вірити мені на слово.

З публічного маніфесту (вхід у систему не потрібен): відкрийте у браузері yourdomain.com/wp-content/plugins/events-manager/readme.txt. Зверніть увагу, що цей плагін постачає свій readme як readme.txt (малими літерами). Рядок Stable tag: поблизу початку містить версію, про яку повідомляє ваша установка, і це той самий публічний файл, який прочитав я.

З адміністративної панелі WordPress (якщо у вас є доступ):

  1. Увійдіть до панелі керування WordPress (зазвичай за адресою yourdomain.com/wp-admin).
  2. Перейдіть до Plugins потім Installed Plugins.
  3. Знайдіть Events Manager і запишіть версію, показану під його назвою.

Потім застосуйте це правило і зверніть увагу, що версії порівнюються чисельно, а не за алфавітом:

  • З 4.0.0 до 7.3.6: потенційно уражена (з урахуванням наведеного вище питання про режим бронювання), оновіться зараз.
  • 7.3.7 або новіша: уже виправлена. Це охоплює 7.3.7.1, яка була подальшим виправленням регресії відображення, не пов’язаної з безпекою, а не другим випуском безпеки: і 7.3.7, і 7.3.7.1 містять виправлення безпеки. Це також охоплює всі поточні випуски 7.4.x.
  • Старіша за 4.0: ця проблема її не зачіпає. Вразливе оброблення даних бронювання вперше з’явилося в переписаній версії плагіна 4.0, тому раніші випуски його не містять (настільки стара версія має безліч інших причин для оновлення, але це повідомлення не одна з них).
  • Не дайте себе ввести в оману текстовим порядком: до 6.0 Events Manager використовував рядки версій на кшталт 5.99912 (виробник застряг на схемі нумерації 5.999.x аж до 6.0), і така версія є старим випуском нижче 6.0, усередині ураженого діапазону, а не чимось новішим за 7. Порівнюйте кожне число по черзі, а не читайте версію як текст.

Як оновитися

Найбезпечніший шлях: оновлення через сам WordPress, попередньо створивши резервну копію:

  1. Створіть резервну копію вашого сайту (файли та база даних) перед внесенням змін. Більшість хостинг-провайдерів пропонують резервне копіювання в один клік, або скористайтеся плагіном резервного копіювання WordPress.
  2. В адмініструванні WordPress перейдіть до Dashboard потім Updates або Plugins потім Installed Plugins. Якщо оновлення Events Manager вказано у списку, встановіть його звідси.
  3. Якщо ви віддаєте перевагу командному рядку, WP-CLI робить те саме: wp plugin update events-manager.
  4. Якщо там не з’являється оновлення, ви можете отримати останній випуск безпосередньо зі сторінки плагіна в каталозі WordPress.org, Events Manager, і оновити через Plugins потім Add New Plugin потім Upload Plugin.
  5. Після оновлення підтвердьте новий номер версії (7.3.7 або новіша; рекомендується поточний випуск лінійки 7.4.x), дотримуючись наведених вище кроків, і перевірте, що ваші сторінки подій і бронювань працюють нормально.

Раз уже ви цим зайнялися, варто переконатися, що ядро WordPress та ваші інші плагіни актуальні, оскільки той самий принцип застосовується до всіх із них.

Після оновлення

Оновлення до 7.3.7 або новішої закриває проблему, і для більшості сайтів на цьому завдання завершено. Немає жодних ознак того, що цю ваду десь експлуатували, тому жодних екстрених заходів не передбачається: вам не потрібно вважати свій сайт скомпрометованим чи вимикати його.

Один подальший крок варто розглянути, і він залежить від того самого питання про бронювання. Якщо ваш сайт приймав публічні бронювання від відвідувачів без облікового запису, перебуваючи на ураженій версії, то дані, яких могла досягти вада (вміст бази даних, зокрема хеші паролів і секретні ключі), були принаймні теоретично доступні для читання, хоча немає доказів того, що хтось це робив. У такому разі доцільні два рутинні запобіжні заходи:

  • Перегляньте нещодавні бронювання й активність користувачів на предмет чогось незвичного, у звичайний спосіб, у який ви переглядали б активність сайту.
  • Замініть секрети, які зберігаються у вашій базі даних і конфігурації: повторно згенеруйте секретні ключі та солі WordPress у wp-config.php (нові значення на відстані одного кліку в офіційному генераторі секретних ключів; їх заміна одноразово завершує сеанси всіх користувачів) і змініть пароль вашої бази даних через панель хостингу. Оскільки хеші паролів були серед даних, теоретично доступних для читання, оновлення паролів обліковими записами адміністраторів є розумним додатковим кроком.

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

Що я робив і чого не робив

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

Це спостереження на основі версії: ваш сайт повідомляє про версію в ураженому діапазоні. Оскільки ця проблема залежить від конфігурації, сайт у цьому діапазоні може взагалі не бути вразливим (якщо бронювання вимагають входу в систему або бронювання не приймаються), а також може вже бути захищений іншими засобами, наприклад фаєрволом вебзастосунків. Це повідомлення не є твердженням, що ваш сайт можна було експлуатувати на момент моєї перевірки.

У мене немає вебмайстра / я застряг

Якщо ви не та людина, яка обслуговує сайт, будь ласка, перешліть цю сторінку тому, хто це робить (вашому веброзробнику, агенції чи хостинг-провайдеру). Вони швидко впізнають наведені вище кроки.

Якщо ви обслуговуєте сайт самостійно і застрягли, я з радістю безкоштовно допоможу вам знайти правильний напрямок. Зв’яжіться зі мною, використовуючи контактні дані нижче.

Контакти

Evan Harris, дослідник безпеки

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

Джерела

Офіційні повідомлення та відстеження

Виробник / плагін