E-Maj 5.0.1 закриває вразливість, яка існувала в усіх попередніх версіях цього PostgreSQL-розширення і за певних обставин дозволяла деяким користувачам отримати права суперкористувача. За даними офіційного анонсу PostgreSQL News від 31 жовтня 2026 року, команда розробників наполегливо рекомендує оновити встановлену версію якомога швидше – незалежно від того, на якій саме попередній версії ти зараз сидиш.

Якщо назва E-Maj тобі ні про що не говорить – це нормально, воно не на слуху так, як сам PostgreSQL. Але якщо твій бекенд хоч якось торкається аудиту змін даних або «подорожей у часі» по базі, варто дочитати до кінця.

E-Maj – це розширення PostgreSQL, яке забезпечує детальне (fine-grained) логування записів і time travel на вибраних підмножинах бази даних. Простими словами: воно дозволяє відстежувати, що саме змінилося в конкретних таблицях, і за потреби «відкотити погляд» на стан даних у певний момент часу – без повного бекапу й відновлення всієї бази.

Такі інструменти типово застосовують там, де потрібен аудит на рівні даних: фінтех, медичні системи, будь-який домен із регуляторними вимогами до історії змін. Якщо твоя команда колись обирала між власним рішенням на тригерах і готовим розширенням для audit trail – E-Maj якраз із тієї категорії інструментів.

Що саме змінилося в 5.0.1

З офіційного анонсу відомо небагато, і це варто сказати чесно: деталей самого механізму вразливості PostgreSQL News не розкриває. Є факт – вразливість зачіпала всі попередні версії розширення і за певних обставин давала деяким користувачам змогу отримати права суперкористувача. Є рекомендація – оновитися якнайшвидше. CVE-ідентифікатор чи технічний опис exploit-шляху в наданому анонсі не згадуються.

Також відомо про сумісність:

  • E-Maj 5.0.1 працює з PostgreSQL версій від 14 до 19.
  • Emaj_web 5.0 (веб-клієнт для управління E-Maj) сумісний з розширенням emaj версій від 3.0 до 5.0.
  • Сам core-екстеншн доступний для встановлення через pgxn.org, розробка ведеться на github.org, там само лежить і emaj_web.

Тобто це одночасно і патч для core-розширення, і оновлення веб-клієнта, які поширюються окремо один від одного.

Як перевірити, чи це стосується тебе

Перший крок – не гадати, а подивитися у свою базу напряму. PostgreSQL зберігає інформацію про встановлені розширення й версії в системному каталозі pg_extension:

-- перевірити, чи встановлено emaj і яка версія
SELECT extname, extversion
FROM pg_extension
WHERE extname = 'emaj';

Якщо запит повернув рядок із версією, нижчою за 5.0.1, – у тебе стоїть версія з вразливістю, незалежно від того, яка саме версія Postgres під капотом (14, 17 чи 19, судячи з заявленої сумісності).

Оновлення самого розширення на рівні бази виконується стандартним механізмом PostgreSQL для апгрейду екстеншнів:

-- оновити розширення до нової версії
ALTER EXTENSION emaj UPDATE TO '5.0.1';

Перед тим, звісно, потрібно встановити самі файли нової версії розширення на сервері – це окремий крок на рівні ОС/пакетного менеджера, який анонс не деталізує, тож тут варто звернутися до документації E-Maj на pgxn.org чи github.org, а не вигадувати команди з голови.

Якщо у тебе ще й розгорнутий emaj_web – це окремий веб-клієнт, і його оновлення до версії 5.0 – це окрема дія, не автоматична частина ALTER EXTENSION. Перевір сумісність: emaj_web 5.0 офіційно підтримує emaj 3.0-5.0, тож апгрейд клієнта без апгрейду core-розширення (або навпаки) може призвести до неузгодженості версій.

Чесні обмеження цього релізу і самого підходу

Кілька речей варто тримати в голові, перш ніж просто побігти оновлюватися й забути:

Анонс тонкий на деталі. Немає опису вектора атаки, немає CVE, немає інформації про те, чи є вже публічні exploit-сценарії. Це означає, що оцінити реальний ризик «наскільки терміново саме в мене» складно без власного аудиту логів доступу та версій.

Будь-яке стороннє розширення PostgreSQL – це розширення поверхні атаки. E-Maj дає потужну функціональність, але це додатковий шматок коду, який живе всередині бази даних поруч із твоїми даними. Чим більше таких розширень встановлено, тим більше потенційних точок для privilege escalation доведеться відстежувати. Це не специфіка саме E-Maj – це загальна властивість екосистеми розширень будь-якої бази даних.

Оновлення розширення на проді – це операція, яку варто тестувати. ALTER EXTENSION ... UPDATE зазвичай швидка операція, але якщо в тебе активні emaj-групи логування чи інша активна конфігурація розширення, перевір процес оновлення на staging-середовищі перед продом – анонс не гарантує zero-downtime апгрейд, і краще не здогадуватись постфактум.

Схожу історію з security-патчем для розширення PostgreSQL блог уже розбирав – подивись PostgreSQL Anonymizer 3.3: критичний security-реліз для масок, які виявились дірявими, там теж ішлося про те, що зручний інструмент для роботи з даними виявився вразливим саме в тій частині, де мав захищати.

Коли це брати в роботу просто зараз

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

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

Якщо E-Maj ти не використовуєш, але читаєш це як привід замислитися – гарний момент пройтися по pg_extension у своїх базах і звірити версії всіх встановлених розширень зі списками security-оновлень на postgresql.org. Принцип найменших привілеїв, про який варто думати не лише на рівні ОС-процесів (про це – у статті про Node.js Permission Model), застосовується так само і всередині самої бази даних: кожне розширення з потенційним доступом до підвищених прав – це окремий пункт у твоєму security-чеклісті, а не рядок, який один раз встановили й забули.