Якщо ви отримали від мене лист із посиланням на цю сторінку, то це тому, що ваш сайт, вочевидь, використовує версію Profile Builder (плагін WordPress, вказаний на WordPress.org як “Profile Builder” / “User Profile Builder”, від Cozmoslabs, який лежить у ваших файлах за шляхом /wp-content/plugins/profile-builder/), яка потрапляє в діапазон, уражений відомою проблемою безпеки. Ця сторінка пояснює, у чому полягає проблема, як визначити, чи стосується вона взагалі вашого сайту, як прочитати свою версію, не давши себе ввести в оману, і як оновитися.

Зауважте: це не ProfilePress. Існує інший плагін WordPress зі схожою назвою (ProfilePress, тека wp-user-avatar), про який я пишу окремо. Якщо тека вашого плагіна wp-user-avatar, а не profile-builder, ця сторінка не та, яка вам потрібна; натомість перегляньте повідомлення про ProfilePress. Усе нижче стосується лише Profile Builder від Cozmoslabs.

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

  • Налаштування Profile Builder Automatically Log In, яке одразу вводить нового користувача в систему після завершення реєстрації, має бути увімкнене.
  • Це налаштування вимкнене за замовчуванням. Сайт, який ніколи його не вмикав, не вразливий до цієї проблеми, навіть на ураженій версії.

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

Проблема має ідентифікатор CVE-2026-15368: це неавтентифіковане захоплення облікового запису на етапі автоматичного входу в плагіні. Вона стосується версій із 2.1.4 по 3.16.3 і виправлена у 3.16.4. Якщо у вас працює уражена версія, оновіть Profile Builder до 3.16.4 або новішої версії. Її оцінка CVSS становить 8.1. Мені не відомо про публічний код експлойту для неї.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перше: чи увімкнено “Automatically Log In”?

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

  1. Увійдіть до консолі WordPress (зазвичай за адресою yourdomain.com/wp-admin).
  2. Відкрийте меню Profile Builder на бічній панелі, а тоді перейдіть до Settings.
  3. Знайдіть перемикач із підписом Automatically Log In, описаний як «Enable to automatically log in new users after successful registration».
  • Якщо цей перемикач вимкнений, ця проблема не досягає вашого сайту, навіть на ураженій версії. Оновитися все одно варто в межах звичайного обслуговування.
  • Якщо він увімкнений, проблема стосується вас, і вам слід оновитися якнайшвидше.

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

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

Друге: яка версія у вас працює?

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

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

  1. У консолі WordPress перейдіть до Плагіни, потім Встановлені плагіни.
  2. Знайдіть Profile Builder, запис, тека якого називається profile-builder, і подивіться версію, показану під назвою.

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

З вихідного коду сторінки (без входу): перегляньте вихідний код сторінки на вашому сайті, яка показує форму Profile Builder, і пошукайте таблицю стилів плагіна для боку відвідувача за таким точним шляхом:

/wp-content/plugins/profile-builder/assets/css/style-front-end.css?ver=...

Число ?ver=, додане до цього одного файлу, є власною версією плагіна. Для цього плагіна воно точно відповідає випуску, тому я вважаю цю перевірку надійним другим джерелом.

Пастка, якої тут варто уникати, і в неї легко потрапити. Profile Builder постачає інші компоненти всередині власної теки плагіна, і вони мають власні, не пов’язані номери версій. Вбудований безкоштовний додаток user-profile-picture за шляхом add-ons-free/user-profile-picture/ залишався на позначці 2.6.0 упродовж кількох випусків Profile Builder, не змінюючись, а ще є вбудована інтеграція з Divi за шляхом assets/misc/divi/, позначена номером 1.0.0. Обидва ці номери виглядають тривожно старими порівняно з 3.16.4, і жоден з них нічого не каже про цю проблему. Якщо ви читаєте версію з вихідного коду сторінки, переконайтеся, що шлях до файлу, з якого ви її читаєте, це саме assets/css/style-front-end.css і нічого іншого.

Далі застосуйте це правило, зважаючи на те, що версії порівнюються числово, а не за алфавітом, тож 3.10.0 новіша за 3.9.9, хоча як текст виглядає меншою. Цей плагін справді проходить кожну лінію випусків від .0 до .9, перш ніж перейти до наступної, тож ця відмінність тут важлива:

  • Від 2.1.4 до 3.16.3: потенційно уражена, залежно від відповіді на питання про налаштування вище. Оновіться зараз.
  • 3.16.4 або новіша: уже виправлена щодо цієї проблеми. Актуальний на момент написання випуск: 3.16.6, і найкращим кроком буде взяти найновішу доступну версію.
  • Старіша за 2.1.4: не уражена цією проблемою. Описана вище конкретна помилка була введена саме у версії 2.1.4, тож справді старіші інсталяції поза її діапазоном. Утім, такий старий випуск сильно відстає в усьому іншому, і оновитися варто вже з загальних міркувань.

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

Як оновитися

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

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

Якщо ви використовуєте платні додатки Profile Builder від Cozmoslabs, оновлюйте їх разом з основним плагіном, оскільки їхні випуски зазвичай узгоджені.

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

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

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

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

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

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

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

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

Зокрема, я ніколи не надсилав вашу форму реєстрації, ніколи не створював обліковий запис і ніколи не торкався етапу автоматичного входу. Нічого не було надіслано, протестовано чи проексплуатовано. Тут це важить більше, ніж на більшості таких сторінок, бо реєстрація є саме тією дією, якої стосується ця проблема, тож «я цього не торкався» і є всією різницею між розкриттям і вторгненням.

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

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

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

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

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

Контакти

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

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

Джерела

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

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