PostgreSQL закърпи 12-годишна дупка в репликацията

Пропуск, който стои в кода на PostgreSQL от 2014 г., най-накрая е затворен. Става дума за CVE-2026-6471 с оценка 7,2 по CVSS — акаунт без права на superuser, но с атрибут REPLICATION, може да накара сървъра да зареди произволен файл като споделена библиотека и така да изпълни код с правата на системния потребител, под който върви базата. Кръпката е част от изданията 18.6, 17.11, 16.15, 15.19 и 14.24, пуснати на 13 август 2026 г.

Уязвимостта е докладвана от Владимир Токарев от Cyera Research Labs, който ѝ даде и името PostGREShell; в благодарностите на проекта фигурира и Ю Кунпън. Тя съществува откакто логическото декодиране влиза в PostgreSQL 9.4 през 2014 г. — тоест засяга всяка версия от 9.4 до 18.4 включително, а изследователите я потвърждават на 18.2.

Две пътеки към един и същ loader

Механизмът е обезоръжаващо прост. Когато напишете LOAD 'плъгин' в SQL, PostgreSQL минава през check_restricted_library_name() — проверка, която не пуска имена с наклонени черти и ../. Репликационният протокол обаче има своя собствена пътека: командата CREATE_REPLICATION_SLOT ... LOGICAL 'плъгин' подава името направо на LoadOutputPlugin(), а оттам на dlopen(). Проверката просто липсва.

Снимка: Cyera Research Labs

Резултатът е, че нападателят може да посочи пълен път във файловата система. На Windows това е UNC път по SMB — библиотеката се дърпа от машина на нападателя и изобщо не е нужно да се пише файл на сървъра. На Linux и macOS същият номер минава през ../ към /net/<хост>, ако е активен automount за NFS. При обикновените инсталации остава класическият вариант: предварителен достъп за запис някъде по диска.

От резервно копие до superuser

След като библиотеката е заредена, нейната функция _PG_init() се изпълнява вътре в backend процеса — вече отвъд SQL слоя, където няма ACL-и и проверки за superuser. Оттам изследователите демонстрират директен запис в системния каталог pg_authid, тоест самопровъзгласяване за superuser, и три отделни механизма за постоянство: пренаписване на pg_hba.conf за вход без парола, регистриране в shared_preload_libraries и закачане на hook за проверка на правата.

Снимка: Cyera Research Labs

Точно тук е и болезнената част. Атрибутът REPLICATION минава за безобиден — раздава се на инструменти за резервни копия, на standby сървъри, на CDC пипелайни (Debezium и подобни) и на мониторинг. Той не дава достъп до данните и затова рядко попада в одитите. „PostGREShell превръща репликационния акаунт, за който никой не се тревожи, в изпълнение на код, superuser и постоянен backdoor“, коментират от Cyera пред SecurityWeek.

За експлоатация са нужни две неща едновременно: акаунт с REPLICATION и сървър с wal_level = logical. Второто отдавна не е екзотика — то е предусловие за логическа репликация и за почти всеки CDC инструмент.

Кръпката: бял списък за плъгините

Поправката добавя нов сървърен параметър output_plugin_libraries, който изброява кои библиотеки изобщо може да бъдат заредени като изходни плъгини. Стойността по подразбиране е 'pgoutput, test_decoding'.

Ако ползвате нещо друго, първо вижте кое:

SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;

След ъпдейта добавете липсващите в postgresql.conf и презаредете конфигурацията:

output_plugin_libraries = 'pgoutput, test_decoding, wal2json'

SELECT pg_reload_conf();

Това е и най-честият проблем след обновяването: инсталациите с wal2json или decoderbufs спират да работят, докато параметърът не бъде допълнен. Отделно, pg_createsubscriber създава слотове, без да проверява белия списък — --dry-run минава успешно, а самото преобразуване се проваля. Към 4 септември това още не е оправено.

Ако не можете да обновите веднага, The Hacker News изброява временните мерки: отнемете REPLICATION от акаунтите, които нямат нужда от него, ограничете репликационните редове в pg_hba.conf до известни адреси, блокирайте изходящия трафик към портове 445 (SMB) и 2049 (NFS) и изключете autofs, където не ви трябва.

Още 27 CVE в същото издание

Изданието от 13 август не е малко: проектът съобщава за 28 закърпени уязвимости и над 110 поправени бъга. Няколко от тях са с по-висока оценка от PostGREShell — CVE-2026-14664 (препълване в regexp), CVE-2026-14669 (to_char) и CVE-2026-19385 (pg_dump) са с CVSS 8.8. Версия 18.5 изобщо не е пусната заради регресия, затова номерацията скача от 18.4 на 18.6. Поддръжката на PostgreSQL 14 приключва на 12 ноември 2026 г.

Колко спешно е

Към момента няма публичен proof-of-concept, CVE-2026-6471 не е в каталога KEV на CISA и не се съобщава за активна експлоатация. Векторът изисква вече компрометирани идентификационни данни, което го прави по-скоро стъпка за повишаване на права, отколкото начин за първоначален пробив — за разлика от спешното закърпване на zero-day в Chrome, където атаките вече течаха.

Това обаче не е причина да отлагате. Дупка, стояла 12 години в софтуер, който върви под голяма част от интернет, вече има подробно техническо описание в публикацията на Cyera — включително бележката, че целият exploit на Windows се събира в три реда Python, а поправката е два реда на C. Обновете до 18.6, 17.11, 16.15, 15.19 или 14.24, проверете кои плъгини ползвате и прегледайте кой всъщност има REPLICATION в базата ви.