У PostgreSQL виправили 28 вразливостей: як визначити терміновість оновлення

Коли повідомлення про вразливості не дає готової відповіді

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

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

13 серпня 2026 року проєкт PostgreSQL випустив оновлення для всіх підтримуваних основних версій. Вони закривають 28 вразливостей і виправляють понад 110 помилок. Кожну інсталяцію варто перевірити, але анонс не є підставою для непідготовленої зміни робочої бази.

Що саме вийшло

Станом на 18 серпня актуальні такі мінорні випуски підтримуваних гілок:

Основна версія	Новий випуск
PostgreSQL 18	18.6
PostgreSQL 17	17.11
PostgreSQL 16	16.15
PostgreSQL 15	15.19
PostgreSQL 14	14.24

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

У гілці 18 перехід відбувся з 18.4 одразу до 18.6: версію 18.5 не випустили через регресію. PostgreSQL 13 і старіші версії вже не підтримуються. Для них цей пакет не є поточним виправленням; потрібен окремий план переходу на підтримувану основну версію.

PostgreSQL 19 Beta 3 — попередній випуск для тестування майбутньої версії. Його не слід сприймати як мінорне оновлення робочих інсталяцій 14–18.

Чому CVE та CVSS не визначають пріоритет автоматично

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

CVE-2026-6464 має оцінку 8.1 і стосується клієнта psql. Якщо COPY FROM STDIN завершується помилкою до початку приймання рядків, наступні рядки можуть бути оброблені як команди psql. Повна атака потребує контролю і над сервером, і над даними; інший описаний сценарій залежить від випадкової ранньої помилки. Варіант COPY FROM з іменем файлу не зачеплено.

CVE-2026-14664 має оцінку 8.8 і стосується сервера. Автор запиту може спричинити переповнення буфера спеціальним текстом, який не пройшов би перевірку кодування, та потенційно виконати код від імені користувача операційної системи, що запускає PostgreSQL.

Обидві картки позначають уразливими випуски до 18.5, 17.11, 16.15, 15.19 і 14.24. Оскільки 18.5 не випускали, доступним оновленням для гілки 18 є 18.6. Високий бал не доводить, що конкретна система придатна для експлуатації: передумови треба звірити з офіційною карткою та інвентарем.

Після оновлення: три окремі перевірки

GIN. Цей тип індексу пришвидшує пошук у значеннях із багатьма елементами. Паралельна побудова могла записати хибне значення reltuples, навіть Infinity або NaN. Через це автоматичне обслуговування й оновлення статистики могли пропускати таблицю, а стан не виправляється сам. Анонс радить після оновлення перевірити таблиці з GIN і діяти за розділом Updating відповідних release notes.
btree_gist. Це розширення додає до GiST-індексів оператори, подібні до B-tree. Виправлення стосуються значень NaN у числових колонках і сортування бітових значень. Для зачеплених індексів може знадобитися повторна побудова за офіційною процедурою.
ltree. Це розширення зберігає шляхи в ієрархіях. Значення з приблизно понад 14 653 мітками могли порівнюватися неправильно, що могло виглядати як пошкодження B-tree-індексу. Зачеплені індекси, можливо, доведеться перебудувати після оновлення.

Від першої перевірки до погодженого рішення

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

Зрозуміти. Вхід: офіційні джерела й опис середовища без адрес, секретів і дампів. Дозволено пояснювати терміни; заборонено оголошувати систему вразливою. Стоп — немає точної версії або джерела суперечать одне одному. Артефакт — словник і список невідомих. Людина звіряє їх із політикою версій та картками CVE.
Перевірити стан. Вхід: санітизований результат перевірки версії, перелік розширень та індексів, тип розміщення й документація провайдера. Дозволений лише аналіз без змін. Стоп — немає належного доступу, з’явилися чутливі дані або версії в різних джерелах не збігаються. Артефакт — інвентар компонентів і відповідальних. Оператор повторює перевірку самостійно.
Спланувати. Вхід: перевірений інвентар, release notes, вікно обслуговування та доказ контрольного відновлення. Асистент може підготувати тести, критерії успіху, повернення до попереднього стану й розподіл відповідальності. Він не призначає дату й не гарантує безперервність. Стоп — немає відповідального або робочого відновлення. Артефакт — план, перевірений власниками бази й застосунку.
Виконати в тесті. Вхід: одноразова копія з анонімізованими даними та погоджений план. Дозволені лише схвалені дії для цієї версії; робоче середовище, видалення даних і зміни мережевого доступу заборонені. Стоп — помилка відновлення, інша версія, застереження щодо індексів або збій тестів. Артефакт — журнал прогону, який оператор порівнює з початковим станом.
Перевірити результат. Вхід: санітизовані журнали, прикладні тести та релізні застереження. Асистент може скласти матрицю «пройдено/не пройдено», але не оголосити систему безпечною за номером версії. Стоп — бракує критичного тесту або з’явилися нові помилки. Артефакт підписує людина після повторної перевірки версії, журналів, застосунку й відновлення.
Пояснити рішення. Вхід: підтверджений інвентар, погоджене рішення, результати тестів і відкриті джерела. Дозволено скласти запис про стан, причину, відповідального й перевірку; заборонено додавати здогади або внутрішні дані. Стоп — лишилася розбіжність або немає відповідального. Артефакт — запис рішення, який другий фахівець звіряє з доказами.

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

Опційний prompt для матриці доказів

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

Окреме рішення для PostgreSQL 14

Випуск 14.24 виправляє проблеми в межах гілки, але не продовжує її життєвий цикл. Підтримка PostgreSQL 14 завершується 12 листопада 2026 року. Потрібні два рішення: встановити актуальний мінорний випуск і окремо спланувати перехід на новішу основну версію.

Доказовий чекліст перед робочою зміною

точну версію підтверджено з авторитетного джерела;
статус підтримки гілки перевірено;
GIN, btree_gist, ltree та інші задіяні компоненти внесено до інвентарю;
release notes потрібної версії прочитано;
відповідального й межі провайдера підтверджено;
контрольне відновлення завершилося успішно;
тестова копія пройшла прикладні перевірки;
журнали та рішення перевірила друга людина.

Короткий глосарій

Стабільна гілка — підтримувана основна версія PostgreSQL, наприклад 17 або 18.
Мінорний випуск — набір виправлень у межах основної версії, наприклад 17.11.
Beta — попередній випуск для тестування майбутньої версії.
CVE — стандартний ідентифікатор відомої вразливості.
CVSS — система оцінювання технічної серйозності вразливості.
Індекс — додаткова структура, що пришвидшує певні запити.
Розширення — модуль, який додає PostgreSQL типи даних, функції або оператори.

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