Якщо ви отримали від мене лист із посиланням на цю сторінку, то це тому, що ваш сайт, вочевидь, використовує версію SMS Alert (плагін WordPress, який у каталозі позначено як “SMS Alert – SMS & OTP for WooCommerce, Order Notifications & Abandoned Cart Recovery”, від Cozy Vision Technologies, і який лежить у ваших файлах за шляхом /wp-content/plugins/sms-alert/), яка потрапляє в діапазон, уражений відомою проблемою безпеки. Ця сторінка пояснює, у чому полягає проблема, як визначити, чи стосується вона взагалі вашого сайту, і як оновитися. Йдеться виключно про плагін WordPress.

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

  1. На вашому сайті ввімкнено OTP-підтвердження для скидання пароля в налаштуваннях SMS Alert, і
  2. обліковий запис, на який спрямовано атаку, має прив’язаний номер телефону.

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

Проблема має ідентифікатор CVE-2026-11387: це захоплення облікового запису без автентифікації через процедуру скидання пароля плагіна (CWE-640, слабке відновлення пароля). Вона стосується версій із 3.0.0 по 3.9.5 і виправлена у 3.9.6. Якщо у вас працює уражена версія, оновіть SMS Alert до 3.9.6 або новішої версії. Випуски 3.9.7 і 3.9.8 з’явилися пізніше й виправляють інші проблеми; обидва є прийнятними щодо цієї конкретної проблеми, а чинним випуском є 3.9.8. Її оцінка CVSS становить 9.8, а код підтвердження концепції є публічним, тому я пишу вам, навіть попри те, що питання про налаштування вище цілком може вирішити справу на вашу користь.

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

Це вада плагіна, а не ядра WordPress чи WooCommerce. Повністю оновлений WordPress не захистить вас, якщо сам плагін SMS Alert має уражену версію.

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

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

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

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

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

SMS Alert надсилає SMS- та WhatsApp-сповіщення для магазинів на WooCommerce, а також може вимагати одноразовий код перед деякими діями користувача. Один із процесів, які він може так захищати, це скидання пароля за посиланням “забули пароль?”: відвідувач запитує скидання, плагін надсилає одноразовий код на номер телефону, прив’язаний до облікового запису, і новий пароль повинен встановлюватися лише після того, як цей код правильно введено.

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

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

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

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

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

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

  • У панелі адміністрування WordPress відкрийте меню SMS Alert і перейдіть до його налаштувань, а тоді до розділу, який керує OTP-підтвердженням. У цьому розділі перелічено процеси, перед якими можна поставити одноразовий код. Перевірте, чи є серед увімкнених скидання пароля (іноді показане як “lost password” або “forgot password”).
  • Якщо це не увімкнено, ця проблема, найімовірніше, не досягає вашого сайту, навіть на ураженій версії. Оновлення все одно рекомендоване як звичайне обслуговування.
  • Якщо це увімкнено, проблема стосується вас, і вам слід оновитися якнайшвидше.

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

Друге: яка версія у вас працює? Вам не обов’язково вірити мені на слово, але для цього плагіна один з очевидних способів перевірки вводить в оману, тож цю частину варто прочитати уважно.

У панелі адміністрування WordPress (головне джерело):

  1. Увійдіть до консолі WordPress (зазвичай за адресою yourdomain.com/wp-admin).
  2. Перейдіть до Плагіни, потім Встановлені плагіни.
  3. Знайдіть запис, позначений як “SMS Alert – SMS & OTP for WooCommerce …“ (тека якого називається sms-alert), і подивіться версію, показану під назвою. Це і є фактично встановлена версія.

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

Не довіряйте: числу ?ver=, доданому до клієнтських скриптів і таблиць стилів плагіна у вихідному коді вашої сторінки. SMS Alert проставляє позначку цих файлів із внутрішньої константи, яка, як мінімум одного разу, відставала від фактичного випуску: версія 3.5.0 вийшла з файлами, позначеними як 3.4.9. Тому читання версії в такий спосіб може показати випуск старіший, ніж той, що у вас насправді працює, а на межі діапазону це перетворило б виправлену інсталяцію 3.9.6 на вигляд 3.9.5. Саме тому я не використовував це для вирішення, кому писати, і саме тому вам варто визначати свою версію за екраном адміністрування або рядком readme.txt.

Далі застосуйте це правило, і зауважте, що версії порівнюються числово, а не за алфавітом, тож 3.9.10 буде новішою за 3.9.9:

  • Від 3.0.0 до 3.9.5: потенційно уражена (залежно від відповіді на питання про OTP-налаштування вище), оновіться зараз.
  • 3.9.6 або новіша: уже виправлена. Це стосується також 3.9.7 і 3.9.8, пізніших випусків, які виправляють інші проблеми; чинним випуском є 3.9.8.
  • Старіша за 3.0.0: поза межами того, що я готовий стверджувати. Найстаріший випуск, який досі публікує розробник, це 3.0.0, тож я не маю змоги перевірити нічого молодшого за нього, і волію не казати нічого, ніж звинувачувати версію, яку не можу перевірити. На практиці цей випадок гіпотетичний: найстаріша інсталяція, яку я будь-де бачив, це випуск лінійки 3.4.x.

Як оновитися

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

  1. Зробіть резервну копію сайту (файлів і бази даних), перш ніж щось змінювати. Більшість хостинг-провайдерів пропонують резервне копіювання в один клік, або скористайтеся плагіном резервного копіювання для WordPress.
  2. У панелі адміністрування WordPress перейдіть до Консоль, потім Оновлення, або до Плагіни, потім Встановлені плагіни. Якщо оновлення SMS Alert є в переліку, встановіть його звідси.
  3. Якщо вам зручніше в командному рядку, WP-CLI робить те саме: wp plugin update sms-alert (команда використовує назву теки, sms-alert).
  4. Якщо оновлення не з’являється, ви можете взяти останній випуск безпосередньо зі сторінки плагіна в каталозі WordPress.org, SMS Alert, і оновитися через Плагіни, потім Додати плагін, потім Завантажити плагін.
  5. Після оновлення підтвердіть новий номер версії (3.9.6 або новіша) за кроками вище й перевірте, що ваші сповіщення про замовлення та будь-які OTP-процеси, якими ви користуєтеся, і далі працюють нормально.

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

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

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

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

  • Перегляньте облікові записи адміністраторів та будь-які інші важливі облікові записи на предмет записів, яких ви не впізнаєте, або змін ролей, яких ви не робили.
  • Перегляньте недавні зміни паролів і недавні входи для облікових записів із прив’язаним номером телефону та скиньте будь-який пароль, який, схоже, змінився без запиту власника облікового запису.

Якщо ви знайдете щось, що вас турбує, правильною відповіддю буде поводитися з цим так само, як і з будь-яким іншим підозрюваним несанкціонованим доступом: змініть паролі адміністраторів і розгляньте можливість перегенерувати секретні ключі та солі у wp-config.php, що завершує всі наявні сеанси. Якщо на вашому сайті ніколи не було увімкнено OTP для скидання пароля, достатньо самого оновлення.

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

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

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

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

У мене немає вебмайстра / я не даю ради

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

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

Контакти

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

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

Джерела

Офіційні бюлетені та відстеження

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