Якщо ви отримали від мене лист із посиланням на цю сторінку, то це тому, що ваш сайт, вочевидь, використовує версію Link Library (плагін WordPress від Yannick Lefebvre, який лежить у ваших файлах за шляхом /wp-content/plugins/link-library/), яка потрапляє в діапазон, уражений відомою проблемою безпеки. Ця сторінка пояснює, у чому полягає проблема, як перевірити, яка у вас версія, як оновитися і що робити після цього.

Проблема має ідентифікатор CVE-2026-16532: це SQL-ін’єкція без автентифікації, досяжна через обробку надсилання посилань у плагіні. Вона стосується кожного випуску до 7.9.3 і виправлена у 7.9.3. Поточним випуском на момент написання є 7.9.4, який теж містить виправлення. Якщо у вас працює будь-що старіше за 7.9.3, оновіть Link Library до 7.9.3 або новішої версії.

Один момент варто прояснити: безпечної старішої версії не існує. Це не вада, яку колись у ході розвитку плагіна внесли, а потім виправили. Вразливий код присутній у кожному опублікованому випуску, який мені вдалося перевірити, аж до найстарішої версії, яку досі віддає каталог WordPress.org. Міркування «моя інсталяція надто стара, щоб її це стосувалося» тут не рятує. Єдині неуражені версії: 7.9.3 і новіші.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Увійдіть до консолі WordPress (зазвичай вашдомен.ua/wp-admin).
  2. Перейдіть до Плагіни, потім Встановлені плагіни.
  3. Знайдіть Link Library, запис, тека якого називається link-library, і подивіться версію, показану під назвою.

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

Одна перевірка, яка для цього плагіна не працює, тож, будь ласка, не покладайтеся на неї. Якщо ви звикли визначати версію плагіна за числом у ?ver=, доданим до скрипта чи стилю у коді вашої сторінки, тут це введе вас в оману. Номери версій в адресах ресурсів цього плагіна є зафіксованими версіями вбудованих сторонніх бібліотек (значення на кшталт 4.0.1, 1.0.0 чи 1.3.9) або версією ядра WordPress. Жодне з них не є версією плагіна, і порівнювати будь-яке з них із 7.9.3 не має сенсу. Користуйтеся екраном адміністрування або readme.txt.

Ще один окремий випадок: деякі дуже старі інсталяції показують у своєму readme.txt рядок Stable tag: trunk. Це взагалі не номер версії. Якщо ви таке побачите, скористайтеся натомість екраном плагінів у панелі адміністрування, а інсталяцію вважайте ураженою, доки цей екран не покаже інше, оскільки інсталяція, достатньо стара, щоб мати trunk, напевно старіша за 7.9.3.

Далі застосуйте правило:

  • Будь-що старіше за 7.9.3: уражена. Оновіть. Немає межі, нижче якої старіший випуск знову стає безпечним.
  • 7.9.3 або новіша: уже виправлена. Поточний випуск 7.9.4 теж містить виправлення.

Як оновитися

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контакти

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

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

Джерела

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

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