PostgreSQL пусна актуализации за отстраняване на уязвимост в сигурността, която позволява на акаунт с атрибут REPLICATION да изпълнява произволен код като потребител на операционната система, работещ със сървъра на базата данни.

Уязвимостта, проследена като CVE-2026-6471 (CVSS оценка: 7.2), съществува откакто логическото декодиране е въведено в PostgreSQL 9.4 през 2014 г. Засегнати са версии преди PostgreSQL 18.6, 17.11, 16.15, 15.19 и 14.24.

Експлоатацията изисква акаунт, притежаващ атрибута REPLICATION, и сървър, работещ с wal_level = logical. Инструменти за архивиране, резервни сървъри, тръбопроводи за улавяне на промени в данните (CDC) и системи за мониторинг рутинно притежават този атрибут.

Корекцията за сигурност, предоставена на 13 август, добавя сървърен параметър, наречен output_plugin_libraries, който изброява кои библиотеки могат да бъдат заредени като плъгини за изходно логическо декодиране, като по подразбиране е 'pgoutput, test_decoding'.

Инсталациите, използващи друг изходен плъгин, wal2json и decoderbufs, сред тях, ще имат отказано логическо декодиране след актуализацията, докато администратор не добави библиотеката към този списък и не презареди конфигурацията на сървъра.

„Преди това потребител на репликация можеше да избере всяка зареждаема библиотека за логическо декодиране, позволявайки експлоатация от различен тип. За да се позволи ограничаването на това, без да се нарушават настройките, които са работили преди, въвежда се бял списък с разрешени изходни плъгини“, каза PostgreSQL Global Development Group в бележките към версия 18.6.

Проектът PostgreSQL благодари на Владимир Токарев и Ю Кунпенг за докладването на проблема.

Токарев го е описал подробно в статия от 1 септември за фирмата за сигурност на данни Cyera Research, която нарича уязвимостта PostGREShell.

Името на плъгина, предоставено в командата CREATE_REPLICATION_SLOT, се предава директно на функцията, която зарежда библиотеката, каза Cyera.

Съществуващото ограничение на PostgreSQL за пътища на плъгини, което ограничава потребители без администраторски права до един контролиран от администратора директория, никога не се извиква по пътя за репликация. Парсърът на протокола за репликация приема почти всеки символ в име на плъгин в двойни кавички, включително разделители на пътища и ../ обхождане, така че пълният път на файловата система достига до зареждащото устройство, както е въведен.

В Windows сървърът разрешава мрежов път през Server Message Block (SMB) и извлича библиотеката от машина, контролирана от атакуващия, без да записва нищо в целта, каза Cyera.

В Linux и macOS същият резултат изисква активиране на NFS (Network File System) automounting. Навсякъде другаде атакуващият се нуждае от съществуващ начин да запише файл на диска на сървъра. Кодът, зареден по този начин, работи в процеса на базата данни като потребител на операционната система postgres.

Тестовият плъгин на Cyera след това е записал каталога на ролите директно, за да направи акаунта за репликация суперпотребител на PostgreSQL. Той също така е настроил три механизма за устойчивост, които оцеляват при рестартиране на сървъра.

Cyera описва атрибута REPLICATION като идентификационни данни за архивиране с ниски привилегии, но PostgreSQL оцени уязвимостта с „Privileges Required“ (Изискуеми привилегии), настроено на „High“ (Високи), оценка, възпроизведена в собствената оценка на SUSE.

PostgreSQL отхвърли прилагането на съществуващото си ограничение LOAD към пътя за репликация.

„Потребителите на REPLICATION преди това не бяха обект на ограничения за пътищата на изходните плъгини, така че те можеха да заобиколят защитите по време на зареждане (LOAD-time protections) по време на логическо декодиране. За съжаление, добавянето на стандартните ограничения LOAD сега би изисквало ретроактивно всички плъгини за изход от трети страни да бъдат инсталирани под директорията $libdir/plugins“, каза Джейкъб Чампиън, който е написал корекцията за сигурност, в съобщението за промени (commit message).

Неуспешните зареждания се появяват в сървърния лог като ERROR: library "..." may not be used as an output plugin, с подсказка, назоваваща настройката, според документацията на параметъра.

На администраторите се препоръчва да предприемат следните стъпки:

  • Изпълнете SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL; преди актуализацията, за да идентифицирате използваните изходни плъгини, което ще покаже само успешно използвани плъгини в даден момент.
  • Актуализирайте до 18.6, 17.11, 16.15, 15.19 или 14.24, или до еквивалентния дистрибуционен пакет.
  • Добавете всеки нестандартен плъгин към output_plugin_libraries и презаредете конфигурацията с pg_ctl reload или SELECT pg_reload_conf(). Не се изисква рестартиране.
  • Настройте output_plugin_libraries на новия клъстер, преди да стартирате pg_upgrade --check, когато мигрирате от версия 17 или по-нова, тъй като проверката се проваля, ако списъкът не позволява плъгините за слотове на стария клъстер.

Коригираните пакети са достъпни за Amazon RDS за всичките пет клона, както и от Debian, SUSE и Ubuntu.

Съобщението на PostgreSQL обхваща поддържаните клонове от 14 до 18 и не се отнася до по-ранни. PostgreSQL 14 спира да получава корекции за сигурност на 12 ноември 2026 г., каза проектът в своето съобщение за версия.

Основната корекция за сигурност „изисква допълнителни промени в конфигурацията, ако се използват някои разширения“, предупреждава съобщението на Debian, назовавайки своите пакети wal2json и decoderbufs.

USN-8653-1 на Ubuntu, който предостави корекцията за 22.04, 24.04 и 26.04 LTS на 20 август, не споменава параметъра и казва на администраторите само да рестартират PostgreSQL след актуализацията.