# Security release for psqlodbc 18.00.0006: чому ODBC-драйвер теж треба патчити > PostgreSQL ODBC випустив 18.00.0006 із кількома security-фіксами. Пояснюємо, кому це реально важливо і як не проґавити оновлення драйвера в проді. - Автор: Юра Скиба (https://cookiesoftware.io) - Опубліковано: 2026-11-03 - Категорія: Backend і System Design - Canonical: https://cookiesoftware.io/blog/security-release-psqlodbc-18 --- PostgreSQL ODBC project випустив версію 18.00.0006 – security release, який закриває кілька вразливостей у драйвері psqlodbc. Деталі вразливостей за даними PostgreSQL News опубліковані в Changelog проєкту, а сама новина вийшла 2 листопада 2026 року. Якщо коротко: конкретику по CVE чи механізму експлуатації джерело не наводить, є лише факт релізу і відсилання до changelog. Це та ситуація, коли новина коротка, а наслідки – ні. Тому розберемось, чому psqlodbc взагалі важливий, навіть якщо ти ніколи свідомо його не підключав. ## Хто насправді користується psqlodbc, навіть не знаючи про це Якщо твій бекенд ходить в Postgres через node-postgres, npgsql або будь-який нативний клієнт – ти, швидше за все, з psqlodbc не стикаєшся напряму. Але ODBC-драйвер живе в іншому шарі екосистеми: - BI-інструменти на кшталт Power BI чи Tableau, які підключаються до Postgres для звітності; - Excel і інші desktop-застосунки, що тягнуть дані через ODBC DSN; - legacy .NET, Delphi чи C++ застосунки, написані до того, як з’явились зручні нативні драйвери; - ETL-пайплайни й скрипти, які історично налаштовані через ODBC, бо так було простіше інтегрувати кілька джерел даних одразу. Проблема в тому, що ці інтеграції часто живуть на окремому сервері, налаштовані один раз адміністратором кілька років тому, і ніхто з розробницької команди не відповідає за їхнє оновлення. Драйвер стає невидимою залежністю: не в package.json, не в lock-файлі, а десь у системному odbcinst.ini. ## Що саме змінилось За даними PostgreSQL News, версія 18.00.0006 psqlodbc виправляє кілька security issues. Розгорнутого опису вразливостей у самій новині немає – рекомендація від проєкту пряма: дивитись Changelog psqlodbc для деталей. Це нормальна практика для security-релізів низькорівневих компонентів: офіційний анонс підтверджує факт і версію, а технічні подробиці – у changelog чи release notes самого проєкту. Якщо в тебе є продакшн-інтеграції через ODBC до Postgres, безпечний підхід – не чекати детального розбору вразливості, а планово перейти на 18.00.0006 і звірити власний changelog з тим, що саме було змінено, перш ніж вирішувати, наскільки терміново це робити саме для твого кейсу. ## Як перевірити, чи це взагалі стосується тебе Перший крок – зрозуміти, чи є в інфраструктурі ODBC-з’єднання до Postgres. Якщо є, конфігурація зазвичай виглядає приблизно так (структура файлів odbc.ini й odbcinst.ini стандартна для unixODBC і подібних менеджерів драйверів): ```ini ; odbcinst.ini – опис драйвера в системі [PostgreSQL ANSI] Description = PostgreSQL ODBC driver (ANSI) Driver = /usr/lib/psqlodbc.so Setup = /usr/lib/psqlodbcw.so ; odbc.ini – конкретне з'єднання (DSN) [MyPostgresDSN] Driver = PostgreSQL ANSI Database = app_db Servername = db.internal Port = 5432 ``` Якщо такий DSN є в інфраструктурі – шлях драйвера в секції `Driver` вкаже на бінарник, версію якого варто звірити з тим, що встановлено на сервері. На практиці це той рядок, який найлегше знайти пошуком у конфігах CI/CD, Ansible-плейбуках чи Docker-образах, якщо хтось колись підключав BI-тул до продакшн-бази. Якщо ODBC-з’єднань немає взагалі – ця новина для тебе радше контекст, ніж action item. Але варто перевірити ще раз: часто саме DevOps чи data-команда підключає BI-дашборди окремо від основного бекенду, і про це не завжди знає команда розробки. ## Trade-offs: навіщо взагалі тримати ODBC, якщо є нативні драйвери Чесно: якщо ти будуєш новий сервіс з нуля на Node.js, Go чи .NET – ODBC майже ніколи не найкращий вибір. Нативні драйвери швидші, мають кращу підтримку типів Postgres і менше шарів абстракції між застосунком і базою. ODBC залишається актуальним, коли: - інструмент на іншому боці (Excel, легасі BI, деякі ETL-платформи) взагалі не вміє інакше, крім ODBC/JDBC; - потрібна уніфікована точка підключення до кількох різних СУБД з одного застосунку; - є історична інтеграція, яку дешевше підтримувати, ніж переписувати. Плата за цю гнучкість – додатковий шар, який живе своїм життям, рідко оновлюється і про який легко забути в security-аудиті. Це той самий патерн, що й з [PostgreSQL Anonymizer 3.3](/blog/postgresql-anonymizer-3-3-security-update) чи [E-Maj 5.0.1](/blog/emaj-501-security-update): екосистема Postgres велика, і security-релізи виходять не лише для самої бази, а й для розширень та драйверів навколо неї. ## Коли це брати в роботу прямо зараз Онови psqlodbc до 18.00.0006 без відкладань, якщо: - у тебе є будь-яка production-інтеграція з Postgres через ODBC, навіть якщо вона "просто для звітності"; - драйвер встановлений на сервері, до якого мають доступ зовнішні BI-тули чи сторонні системи; - ти не можеш швидко сказати, яка версія psqlodbc зараз використовується в інфраструктурі – це саме по собі сигнал, що процес відстеження залежностей має прогалину. Можна почекати з терміновим оновленням, якщо ODBC-з’єднання є лише в dev/staging середовищі без доступу до чутливих даних – але все одно варто запланувати оновлення, а не забути про нього назавжди. ## Що взяти із цієї новини, крім самого патчу Головний практичний висновок тут не про конкретну версію драйвера, а про процес: якщо в команді немає відповіді на питання "які версії ODBC/JDBC-драйверів у нас використовуються і хто за них відповідає", це прогалина, яку варто закрити окремим пунктом у security-чеклісті, а не чекати наступного анонсу на postgresql.org.