Якщо ви отримали від мене лист із посиланням на цю сторінку, то це тому, що ваш сайт, вочевидь, використовує версію Content Views – Post Grid & Filter (плагін WordPress від Content Views / PT Guy, який лежить у ваших файлах за шляхом /wp-content/plugins/content-views-query-and-display-post-page/), яка потрапляє в діапазон, уражений відомою проблемою безпеки. Ця сторінка пояснює, у чому полягає проблема, як визначити, наскільки вона важлива для вашого сайту, як прочитати свою версію, не давши себе ввести в оману, і як оновитися.

Проблема має ідентифікатор CVE-2026-15361: це SQL-ін’єкція в обробці попереднього перегляду плагіна. Вона стосується кожного випуску до 4.5 і виправлена у 4.5, випущеній 28 липня 2026 року. Якщо у вас працює будь-яка версія, старіша за 4.5, оновіть Content Views до 4.5.1 або новішої версії, яка є чинним випуском на момент написання цього тексту (4 серпня 2026 року). Для цієї проблеми не опубліковано жодної оцінки CVSS, тож я не наводитиму її вам, і мені не відомо про жодний публічний код експлойту для неї.

Немає жодної старішої версії, яка була б безпечною. Це не вада, яку внесли на якомусь етапі історії плагіна й пізніше виправили. Я перевірив кожен опублікований тег випуску в історії плагіна, від найпершого у 2014 році й до 4.4, і уражений код присутній у них усіх. “Моя інсталяція занадто стара, щоб бути ураженою” тут не працює як виправдання. Єдині версії, які не уражені, це 4.5 і новіші.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Усе зводиться до одного питання: яку версію Content Views ви використовуєте?

Кілька слів про те, який саме це плагін, оскільки назва є спільною. Це повідомлення стосується безкоштовного плагіна, опублікованого на WordPress.org, того, чия тека називається content-views-query-and-display-post-page. Той самий розробник продає й окрему лінійку Pro. Якщо тека вашого плагіна саме така, читайте далі.

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

  1. Увійдіть до консолі WordPress (зазвичай за адресою yourdomain.com/wp-admin).
  2. Перейдіть до Плагіни, потім Встановлені плагіни.
  3. Знайдіть Content Views – Post Grid & Filter, запис, тека якого називається content-views-query-and-display-post-page, і подивіться версію, показану під назвою.

З публічного маніфесту (без входу): відкрийте

yourdomain.com/wp-content/plugins/content-views-query-and-display-post-page/README.txt

у браузері, і прочитайте рядок Stable tag: ближче до початку файлу. Це одне з двох публічних джерел, які я читаю.

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

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

/wp-content/plugins/content-views-query-and-display-post-page/public/assets/js/cv.js?ver=...
/wp-content/plugins/content-views-query-and-display-post-page/public/assets/css/cv.css?ver=...

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

Пастка, якої варто тут уникати, і в неї легко потрапити. Цей плагін постачає вбудовані копії кількох сторонніх бібліотек всередині власної теки плагіна, і кожна з них має власний, зовсім не пов’язаний номер версії. У вихідному коді вашої сторінки може показуватися Bootstrap версії 3.3.5 або 3.3.0, Select2 версії 3.4.5, html5shiv версії 3.7.0, respond.js версії 1.4.2 і bootstrap-paginator версії 0.5, і всі вони на шляхах, що починаються з теки плагіна Content Views. Оператор, який шукає у вихідному коді сторінки теку плагіна і читає перше значення ?ver=, яке трапляється, може легко дійти висновку, що плагін має версію “3.3.5”, а потім ламати голову над тим, як це порівняти з 4.5. Це неможливо порівняти взагалі. Число на кшталт 3.3.5 чи 0.5 на шляху bootstrap чи select2 є версією зовсім іншого програмного забезпечення. Читайте версію лише з cv.js чи cv.css (або з public.js / public.css на дуже старій інсталяції), і ігноруйте будь-який інший ?ver= на сторінці.

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

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

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

Як оновитися

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

  1. Зробіть резервну копію сайту (файлів і бази даних), перш ніж щось змінювати. Більшість хостинг-провайдерів пропонують резервне копіювання в один клік, або скористайтеся плагіном резервного копіювання для WordPress.
  2. У панелі адміністрування WordPress перейдіть до Консоль, потім Оновлення, або до Плагіни, потім Встановлені плагіни. Якщо оновлення Content Views є в переліку, встановіть його звідси.
  3. Якщо вам зручніше в командному рядку, WP-CLI робить те саме: wp plugin update content-views-query-and-display-post-page (команда використовує назву теки, а не назву, що відображається).
  4. Якщо оновлення не з’являється, ви можете взяти останній випуск безпосередньо зі сторінки плагіна в каталозі WordPress.org, Content Views – Post Grid & Filter, і оновитися через Плагіни, потім Додати плагін, потім Завантажити плагін.
  5. Після оновлення підтвердіть новий номер версії (4.5.1 або новіша) за кроками вище й перевірте, що ваші сітки дописів і будь-які фільтри на них досі відображаються нормально.

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

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

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

Поки оновлення ще свіже, варто зробити дві невеликі речі:

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

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

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

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

  • вашу головну сторінку та адреси файлів активів, записані на ній;
  • публічний файл README.txt плагіна всередині wp-content/plugins/content-views-query-and-display-post-page/;
  • стандартну сторінку реєстрації WordPress вашого сайту за адресою /wp-login.php?action=register, щоб побачити, чи відкрита вона для відвідувачів. Це опублікована сторінка, і читання це все, що я з нею зробив.

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

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

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

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

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

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

Контакти

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

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

Джерела

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

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