Drupal CVE-2026-9082 Змушує PostgreSQL-Сайти до Екстреного Патчингу

Кожен технічний керівник, що підтримує стек Drupal на PostgreSQL, отримав незапланований рядок витрат у травневому бюджеті. Команда безпеки Drupal випустила екстрені релізи для шести підтримуваних версій, а також патчі-«найкращі зусилля» для двох гілок, що досягли кінця підтримки, щоб усунути вразливість, яка дозволяє анонімним користувачам здійснювати довільну SQL ін'єкцію. Ключове бізнес-питання зараз — не чи потрібно патчити цього тижня. Це питання про те, як цей інцидент змінює математику «розробляти чи купувати» для команд, які досі вважають Drupal стратегічною CMS у 2026 році.

Що Сталося

21 травня 2026 року проєкт Drupal оприлюднив вразливість, оцінену як «вкрай критичну» в Drupal Core, що відстежується як CVE-2026-9082. Як повідомив The Hacker News, вразливість має оцінку CVSS 6.5 за CVE.org, що виглядає дивно низько порівняно з власним формулюванням «вкрай критична» від проєкту. Ця розбіжність важлива, і я до неї повернуся.

Першопричина криється в API абстракції бази даних, яке Drupal Core використовує для перевірки запитів та захисту від SQL ін'єкцій. Спеціально сформований запит може обійти цю санітизацію і призвести до довільної SQL ін'єкції, але лише на сайтах, що працюють на PostgreSQL. Розгортання на MySQL і MariaDB не підпадають під дію вразливості відповідно до власного рекомендаційного повідомлення Drupal. Ланцюжок впливу починається від розкриття інформації і доходить до підвищення привілеїв та, у деяких випадках, до виконання довільного коду (RCE). Принципово важливо, що атака не вимагає автентифікації. Анонімні користувачі з публічного інтернету можуть її здійснити.

Виправлені релізи вийшли для всіх підтримуваних гілок: Drupal 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10 та 10.4.10. Підтримувані гілки (11.3, 11.2, 10.6 та 10.5) також містять оновлення безпеки для Symfony і Twig, що означає: патч — це не заміна одного файлу, а оновлення залежностей. Drupal 7 не підпадає під дію. Drupal 8 і Drupal 9 досягли кінця підтримки, але з огляду на серйозність проєкт випустив ручні патчі для 9.5 і 8.9 як «найкращі зусилля». Drupal 11.1.x, 11.0.x, 10.4.x та нижчі версії перебувають у зоні без підтримки. Канонічне відстеження можна переглянути у записі CVE.

Технічна Анатомія

Механізм вразливості заслуговує на увагу, оскільки пояснює, чому оцінка CVSS і опис серйозності від проєкту розходяться. Рівень абстракції бази даних Drupal існує саме для того, щоб розробники застосунків не писали SQL вручну під кожен бекенд. Цей рівень нормалізує прив'язку параметрів, екранування і обробку ідентифікаторів для MySQL, PostgreSQL і SQLite. Коли абстракція сама по собі дає збій на одному бекенді, кожен модуль, що побудований поверх неї, успадковує вразливість — навіть ті модулі, автори яких зробили все правильно. Саме тому єдиний CVE у Core може каскадно поширитися на тисячі contrib-модулів без того, щоб будь-який із них мав індивідуальну вразливість.

Радіус ураження лише PostgreSQL вказує на специфічну для цього бекенда поведінку екранування або приведення типів у драйвері. PostgreSQL обробляє певні крайові випадки ідентифікаторів і рядкових літералів інакше, ніж MySQL, зокрема щодо чутливості до регістру, dollar-quoting та синтаксису масивів. Санітайзер, що передбачає семантику MySQL, дасть витік на Postgres. Drupal не розкриває деталі експлойту, і правильно робить, але форма вразливості відповідає розбіжності на рівні драйвера, а не логічній помилці в конкретному модулі.

Шлях ескалації від SQL ін'єкції до RCE в Drupal добре відомий. Як тільки зловмисник може записувати довільні рядки, цілями стають таблиці кешу, таблиця сесій і таблиці конфігурації, що зберігають серіалізовані PHP-об'єкти. Впровадіть підготовлений серіалізований payload, ініціюйте десеріалізацію при наступному запиті — і ви отримуєте виконання коду від імені користувача веб-сервера. Це чітко відповідає технікам MITRE ATT&CK щодо експлуатації публічних застосунків та серверної десеріалізації. Оцінка CVSS 6.5, ймовірно, відображає умовний характер шляху до RCE (не всі сайти мають таблиці конфігурації з доступом на запис через шар кешу), але для фінансового директора, що підписує резерв на інциденти, важливий найгірший сценарій, а не медіанний.

Оновлення Symfony і Twig, включені до релізів підтримуваних гілок, додають ще одну складність. Команди, що патчать лише файли Drupal Core та пропускають оновлення директорії vendor, вважатимуть себе захищеними, хоча насправді ні.

Хто Постраждає

Вразлива аудиторія вужча, ніж при типовому CVE Drupal Core, але концентрація загрози — нищівна. Drupal на PostgreSQL — це не типовий стек. Він, як правило, зосереджений у трьох місцях: державні сайти та органи влади, де PostgreSQL є обов'язковим (особливо в Європі), портали вищої освіти, що успадкували Postgres від ширшого інституційного стандарту, та регульовані галузі (страхування, охорона здоров'я, деякі суміжні напрямки FinTech), де команда платформи обрала Postgres заради JSONB або через ліцензійні причини. Саме ці оператори мають найповільніші цикли управління змінами та найбільші накладні витрати на відповідність нормативним вимогам на кожне розгортання.

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

Найбільше постраждають ті, хто досі на Drupal 8, 9 або гілках 10.x, що вийшли з підтримки. Патчі «найкращі зусилля» для 8.9 і 9.5 — це жест доброї волі, а не зобов'язання. Drupal чітко зазначив, що ці версії все ще несуть інші раніше оприлюднені вразливості. Якщо у 2026 році ви на 8.9, цей CVE — симптом, а не хвороба. Ваша справжня проблема в тому, що ваша команда платформи відтерміновувала оновлення до мажорної версії до точки, де зволікання стало дорожчим за ризик компрометації.

Для ринку праці очікуйте короткочасного сплеску попиту на спеціалістів з оновлення Drupal — так само, як EOL Magento 1 породив міні-бум серед підрядників. Пропозиція невелика. Старші Drupal-інженери тихо мігрують на ролі headless та JAMstack вже три роки.

Інструкція для Команд Безпеки

Починайте з інвентаризації, а не з патчингу. Не можна виправити те, про що ви не знаєте. Зберіть усі хостнейми Drupal у вашій системі управління активами, визначте бекенд бази даних (Postgres чи MySQL) та позначте Postgres-сайти як пріоритет першого рівня. Для MySQL-сайтів патч теж потрібен, але терміновість нижча, оскільки цей конкретний CVE вас не зачіпає.

Для сайтів на Postgres з підтримуваної гілки оновіться до 11.3.10, 11.2.12, 10.6.9 або 10.5.10 залежно від вашої гілки. Оновіть директорію vendor: оновлення Symfony і Twig входять до того самого релізу не випадково. Виконайте smoke-тестування на staging для ваших найпопулярніших типів контенту та будь-яких кастомних модулів, що використовують db_query або entity query API.

Для сайтів на Postgres, що працюють на 11.1.x, 11.0.x, 10.4.x або нижче, у вас два шляхи. Або перейдіть на підтримувану гілку цього кварталу, або прийміть, що ви керуєте непідтримуваною інфраструктурою, і відповідно оцініть ризик. Для 9.5 і 8.9 застосуйте ручні патчі як тимчасовий захід, але розглядайте їх як реанімацію, а не як вирішення проблеми. Усе, що досі на Drupal 7, не підпадає під цей CVE, але сам Drupal 7 вийшов з підтримки і несе власний портфель невиправлених проблем.

Щодо виявлення: налаштуйте WAF для моніторингу аномальних рядків запитів до Drupal-ендпоінтів, логуйте всі помилки класу 500 від PHP та зберіть зараз базовий профіль запитів до бази даних, щоб мати з чим порівнювати при виявленні індикаторів компрометації в майбутньому. Щодня перевіряйте каталог CISA KEV протягом наступних двох тижнів. Якщо цей CVE туди потрапить, федеральні підрядники зіткнуться з жорстким дедлайном на усунення незалежно від внутрішніх вікон змін.

Керівник платформи має запитати VP Engineering цього тижня: чи є у Drupal-інфраструктури дорожня карта виведення з експлуатації з конкретними датами, чи вона просто дрейфує, бо ніхто не бере на себе рішення? Ця розмова давно назріла незалежно від CVE-2026-9082, і цикл патчингу — безкоштовний привід внести її до порядку денного.

Ключові Висновки

• CVE-2026-9082 — це SQL ін'єкція в API абстракції бази даних Drupal Core, доступна анонімним користувачам, з можливістю RCE лише на сайтах із PostgreSQL.
• Виправлені версії: Drupal 11.3.10, 11.2.12, 11.1.10, 10.6.9, 10.5.10 та 10.4.10; релізи підтримуваних гілок також включають оновлення Symfony і Twig, які потрібно встановити разом.
• Drupal 8.9 і 9.5 отримують ручні патчі «найкращі зусилля», попри EOL; старіші точкові версії 10.x і 11.x не отримують нічого.
• CVSS 6.5 занижує операційну серйозність, оскільки усереднює умовні шляхи ескалації; ставтеся до SQLi, доступної анонімним користувачам, як до інциденту найвищого пріоритету.
• Команди, що оцінюють Drupal як стратегічну платформу у 2026 році, вже зараз мають запитати, чи вартість підтримки self-hosted PHP CMS досі перевищує вартість міграції на managed або headless альтернативу.