PostgreSQL 18.6 получил необычную историю ещё до публикации: подготовленную версию 18.5 отменили после обнаружения регрессии, поэтому ветка 18 перескочила сразу на следующий номер. Новый minor-релиз закрывает серию уязвимостей в сервере и утилитах, меняет правила загрузки плагинов логического декодирования и исправляет ошибки, способные приводить к неверным результатам запросов, сбоям индексов и проблемам с autovacuum.
Версия 18.5 до пользователей так и не дошла. В официальных release notes PostgreSQL 18.6 разработчики объясняют причину коротко: после подготовки пакета обнаружилась регрессия. В результате проект сохранил уже использованный номер и выпустил исправленную сборку как PostgreSQL 18.6 с датой релиза 13 августа 2026 года.
Сам тег REL_18_6 появился в официальном зеркале PostgreSQL на GitHub 11 августа. Для стабильной ветки это технически обычный этап подготовки релиза, но в этот раз именно репозиторий раньше публичной страницы загрузок показал, что следующим выпуском станет 18.6.
PostgreSQL 18.5 отменили после обнаружения регрессии
Пропуск номера в стабильной ветке PostgreSQL встречается редко и сразу вызывает вопрос: почему после 18.4 появилась 18.6? Разработчики зафиксировали, что 18.5 прошла стадию подготовки релиза, после которой обнаружилась регрессия. Такой момент в проекте называют post-wrap — исходники уже собраны и промаркированы для выпуска, но публикация ещё может быть остановлена.
Поэтому PostgreSQL 18.6 содержит исправления относительно версии 18.4. Пользовательской версии 18.5 в этой цепочке нет, хотя номер успел участвовать во внутреннем процессе выпуска.
Для кластеров PostgreSQL 18.x переход на 18.6 не требует dump/restore. Формат данных внутри одной major-ветки сохраняется совместимым. При этом release notes отдельно выделяют несколько изменений, которые затрагивают конфигурацию, зашифрованные данные и индексы.
Логическое декодирование получило список разрешённых плагинов
Одно из первых исправлений связано с логической репликацией и logical decoding — механизмом, который превращает изменения в журнале WAL в поток данных для внешних потребителей.
До 18.6 пользователь с правами репликации мог указать практически любую загружаемую библиотеку в качестве output plugin. Такая возможность расширяла поверхность атаки: доступ к replication role сам по себе мог дать путь к загрузке неподходящей библиотеки.
PostgreSQL 18.6 добавляет параметр output_plugin_libraries. Он задаёт перечень разрешённых плагинов логического декодирования. По умолчанию туда входят штатные pgoutput и test_decoding.
Изменение связано с CVE-2026-6471. Системы, где используются сторонние output plugins, теперь зависят от явного присутствия этих модулей в output_plugin_libraries. Проверка pg_upgrade --check для миграций с PostgreSQL 17 и новее тоже учитывает этот список и обнаруживает слоты репликации, для которых нужный плагин запрещён новой конфигурацией.
Такой механизм делает конфигурацию логической репликации более явной: наличие replication role больше не даёт свободный выбор любой библиотеки, доступной серверу.
pgcrypto мог создавать PGP-данные с фактически сломанным шифрованием
Самая неприятная находка в PostgreSQL 18.6 касается расширения pgcrypto. Проблема проявлялась, когда OpenSSL отказывался использовать запрошенный алгоритм шифрования — например, в FIPS-режиме или при отсутствии legacy provider.
В таком случае pgcrypto раньше не распознавал отказ OpenSSL корректно. Вместо нормального шифрования блок обрабатывался способом, который делал содержимое тривиально восстанавливаемым. В release notes отдельно перечислены устаревшие или несовместимые с FIPS алгоритмы вроде Blowfish, Twofish, CAST5 и 3DES.
Уязвимость получила идентификатор CVE-2026-14663.
Есть и неприятное последствие для уже созданных данных. После обновления pgcrypto по умолчанию отказывается расшифровывать сообщения, затронутые этим дефектом. Для диагностического извлечения таких значений разработчики добавили параметр ignore-cipher-failure в pgp_pub_decrypt() и pgp_sym_decrypt().
Суть проблемы выходит за рамки обычного падения функции: приложение могло считать данные защищёнными PGP, хотя используемый путь шифрования фактически не обеспечивал ожидаемой стойкости.
psql перестал воспринимать данные COPY как SQL после ошибки команды
Ещё одна уязвимость затрагивает сценарии с COPY ... FROM STDIN в SQL-файлах.
Если команда COPY завершалась ошибкой ещё до перехода сервера в режим приёма данных — например, таблица назначения отсутствовала — psql мог продолжить разбирать следующие строки как обычные SQL-команды. А эти строки изначально предназначались как данные для COPY.
В безобидном случае скрипт выполнялся неправильно. При специально подготовленном содержимом возникал сценарий SQL-инъекции. Исправление вошло как CVE-2026-6464.
Теперь psql самостоятельно распознаёт синтаксически корректный COPY ... FROM STDIN и пропускает предназначенный ему блок данных даже тогда, когда сервер не ответил состоянием PGRES_COPY_IN.
Разница особенно заметна в автоматизированных дампах, тестовых сценариях и больших SQL-файлах, где команды и данные идут последовательно в одном потоке.
В EXECUTE, FETCH и to_char закрыты пути к выполнению произвольного кода
В release notes 18.6 есть несколько исправлений памяти, которые выглядят серьёзнее типичных багов minor-релиза.
CVE-2026-16239 связана с командами EXECUTE и FETCH. PostgreSQL использует внутренние порталы для выполнения таких запросов, и ранее их описание возвращаемых строк можно было привести к несогласованному состоянию. По данным проекта, последствия включали раскрытие содержимого памяти сервера и произвольное выполнение кода.
CVE-2026-14669 исправляет переполнение буфера в to_char() при обработке слишком длинной аббревиатуры часового пояса. Разработчики прямо указывают на возможность аварийного завершения сервера и сообщают о существовании эксплойтов, приводящих к выполнению произвольного кода.
Ещё несколько CVE закрывают похожие классы ошибок:
- функции поиска и разбиения по регулярным выражениям могли выйти за границы буфера при некорректно закодированных данных;
ascii()позволяла прочитать несколько байтов памяти за допустимыми границами;- специально созданный оператор мог вызвать сбой или раскрытие памяти через
scalarineqsel(); - код
tsvectorиtsqueryнедостаточно последовательно контролировал максимальную длину значений; pg_dump, PL/Perl, PL/Tcl,pg_stat_statements,pg_trgm,fuzzystrmatchи другие компоненты получили дополнительные проверки размеров и границ памяти.
В списке исследователей, сообщивших о проблемах, фигурируют специалисты PostgreSQL, независимые исследователи, Anthropic Research, OpenAI Codex Security и TrendAI Zero Day Initiative.
Изменения ролей теперь сбрасывают планы, связанные с Row-Level Security
PostgreSQL активно кеширует планы запросов, чтобы не строить их заново при каждом выполнении. Для Row-Level Security такой кеш должен учитывать текущие роли и их права.
До 18.6 изменения членства в ролях, атрибутов ролей или владельца базы могли оставить в кеше план, построенный по прежнему набору прав. В результате политика RLS продолжала работать с устаревшим представлением о доступе.
Исправление CVE-2026-14666 заставляет PostgreSQL инвалидировать такие планы при изменениях ролей.
С похожей областью прав связана CVE-2026-6470. Команды CREATE TYPE AS RANGE, ALTER TABLE OF и некоторые операции со stored expressions раньше пропускали проверку USAGE для используемых типов. Роль могла создать зависимый объект без соответствующего разрешения и тем самым помешать владельцу типа изменять его в дальнейшем.
Ошибка GIN могла надолго отключить autovacuum и autoanalyze для таблицы
Среди обычных исправлений PostgreSQL 18.6 выделяется проблема параллельного построения GIN-индексов.
Один из worker-процессов мог передать неинициализированное значение количества обработанных строк. Из него формировалось поле pg_class.reltuples — приблизительная оценка числа строк в таблице. В повреждённом состоянии там могли появиться абсурдные значения вплоть до Infinity или NaN.
Эта статистика участвует в решениях autovacuum и autoanalyze. При некорректном reltuples автоматические процессы могли бесконечно считать, что таблице ещё не требуется обслуживание.
Особенность бага в том, что состояние само по себе могло не исправиться. Release notes указывают, что корректное значение возвращается после ANALYZE или создания нового индекса.
Для рабочей базы такой дефект способен проявляться постепенно: сначала меняется статистика, затем перестаёт своевременно обновляться информация для планировщика и обслуживание таблицы отстаёт от реального объёма изменений.
Планировщик исправляет случаи с пропущенными строками и неверными результатами
Часть исправлений PostgreSQL 18.6 относится к корректности запросов. Здесь последствия заметнее обычной потери производительности: некоторые ошибки могли менять сам результат SQL.
В RANGE-секционированных таблицах исправлена partition pruning, из-за которой DEFAULT-раздел иногда исключался из плана, хотя в нём могли находиться подходящие строки. Итогом становилась неполная выборка.
Асинхронный Append при повторном сканировании мог неправильно обрабатывать незавершённые запросы к внешним серверам, в том числе через postgres_fdw. В зависимости от плана это приводило к неверным результатам, бесконечному циклу или assertion failure.
Исправлена и оптимизация выражений value IN (array): планировщик в некоторых случаях применял преобразование, допустимое только для гарантированно непустого массива. Пустой массив мог привести к неправильному ответу.
Отдельная правка касается удаления join из плана. В редких комбинациях outer join и NULL константное значение с nullable-стороны соединения сохранялось там, где результат должен был стать NULL.
Такие ошибки особенно коварны тем, что запрос завершается успешно. Приложение получает правдоподобный набор строк, а расхождение обнаруживается только при сравнении с другим планом или набором данных.
Hash Join с большим числом NULL больше не раздувает хеш-таблицу
В 18.6 есть и исправление производительности для hash join с несколькими ключами соединения.
Строки с NULL в ключе, которые всё равно не смогут совпасть с другой стороной соединения, должны отбрасываться до помещения в хеш-таблицу. PostgreSQL делал это неправильно, если NULL находился не в последнем столбце составного ключа.
При большом количестве таких строк хеш-таблица могла заметно разрастаться. Исправление уменьшает лишнее потребление памяти и работу процессора именно в запросах с составными ключами и большим числом NULL.
btree_gist и ltree получили исправления, способные потребовать перестроения индексов
Release notes отдельно предупреждают о нескольких проблемах расширений.
В btree_gist исправлена обработка NaN для float4 и float8. Раньше сравнения, GiST penalty и distance functions могли выдавать неверный ответ. Индексы, построенные на float-столбцах с NaN, могут содержать структуру, сформированную по ошибочным правилам.
Для bit и varbit при построении GiST использовалась сортировка, рассчитанная как для bytea. Такой индекс продолжал работать, но получался менее эффективным.
Ещё одна правка btree_gist касается поиска с оператором <> для типов переменной длины: на внутренних страницах индекса использовалась неправильная функция сравнения, что могло давать неверные результаты и в отдельных случаях приводить к сбою.
В ltree обнаружено целочисленное переполнение при сравнении очень длинных путей. Проблема проявлялась у значений примерно с 14 653 метками и более. B-tree индекс, содержащий такие значения, мог оказаться логически повреждённым.
PostgreSQL 18.6 получился релизом безопасности с необычной историей нумерации
PostgreSQL 18.6 формально остаётся minor-релизом ветки 18 и сохраняет совместимость формата данных с другими версиями 18.x. Его содержимое при этом затрагивает сразу несколько чувствительных зон: загрузку модулей, криптографию, обработку SQL-скриптов, права ролей, память сервера, корректность планировщика и состояние индексов.
В рамках этого релиза появилась необычная деталь, связанная с версией 18.5. Команда проекта обнаружила регрессию и решила отложить уже подготовленную версию, внеся необходимые исправления в 18.6. Таким образом, последовательность 18.4 → 18.6 отражает реальный сбой, который был выявлен в процессе разработки.
После публикации бинарных пакетов станет видно, какие дистрибутивы и облачные платформы первыми подхватят 18.6 и насколько быстро новая версия заменит 18.4 в поддерживаемых репозиториях. С технической стороны содержание релиза уже зафиксировано в официальном теге REL_18_6 и release notes с датой 13 августа 2026 года.
