13 августа PostgreSQL получил один из наиболее заметных пакетов исправлений безопасности за последнее время. В ветках 18, 17, 16, 15 и 14 вышли версии 18.6, 17.11, 16.15, 15.19 и 14.24. Разработчики исправили 28 уязвимостей безопасности и более 110 других ошибок. Одновременно проект напомнил о скором окончании поддержки PostgreSQL 14, для которой 12 ноября 2026 года станет последним днём получения исправлений.
Самой заметной проблемой стал CVE-2026-14662. Ошибка связана с целочисленным переполнением при работе с типами tsvector и tsquery. При передаче специально сформированных больших входных данных недостаточный размер выделяемой памяти может привести к записи за пределами выделенного участка. Для уязвимости установлен CVSS 8.8, а в определённых условиях результатом может стать выполнение произвольного кода с правами операционной системы, от имени которой работает сервер базы данных.
Но один CVE не описывает весь масштаб обновления. В том же пакете исправлены проблемы с переполнением буфера, правами доступа, логическим декодированием, pgcrypto, регулярными выражениями и клиентскими инструментами. Поэтому обновление имеет значение не только для серверов, которые доступны из внешней сети. Часть исправлений относится к клиентским компонентам и отдельным возможностям PostgreSQL.
Для администратора это превращает обычную процедуру установки минорного обновления в хороший повод проверить всю цепочку безопасности. Особенно внимательно стоит отнестись к PostgreSQL 14, поскольку его поддержка заканчивается уже в ноябре.
28 исправлений закрывают сразу несколько классов проблем PostgreSQL
Августовский выпуск необычен количеством исправленных уязвимостей. PostgreSQL Global Development Group указывает 28 security fixes в версиях 18.6, 17.11, 16.15, 15.19 и 14.24. Кроме того, разработчики исправили более 110 обычных ошибок.
В списке есть проблемы разного характера. Некоторые относятся непосредственно к серверу, другие затрагивают клиентские инструменты или дополнительные модули.
Например, CVE-2026-19385 связана с переполнением кучи в pg_dump, которое может привести к выполнению произвольного кода. Для неё указан CVSS 8.8. Ещё одна проблема, CVE-2026-18408, касается поведения psql при обработке специальной конструкции и также имеет CVSS 8.8.
Есть и менее критичные проблемы. CVE-2026-18024 позволяет функции ascii() прочитать до трёх байтов за пределами соответствующего выделенного участка памяти. CVSS этой уязвимости составляет 4.3. Отдельно исправлен недостаток в pgcrypto, из-за которого некоторые отключённые шифры могли фактически работать с открытым текстом, хотя приложение ожидало зашифрованные данные. Для CVE-2026-14663 указан CVSS 6.5.
Такое распределение хорошо показывает, почему не стоит оценивать обновление только по самому высокому CVSS.
На рабочем сервере могут одновременно использоваться функции, которые относятся к разным исправлениям. Один экземпляр PostgreSQL может активно использовать полнотекстовый поиск, другой работать с логической репликацией, третий регулярно создавать резервные копии через pg_dump.
Поэтому правильный вопрос звучит не "есть ли на сервере CVE 8.8", а "какие из исправленных компонентов реально используются этой установкой и какие права имеют пользователи".
CVE-2026-14662 опасна из-за сочетания входных данных и управления памятью
Уязвимость в tsvector и tsquery особенно интересна с технической точки зрения.
PostgreSQL использует эти типы для полнотекстового поиска. tsvector представляет подготовленное текстовое содержимое в форме, удобной для поиска, а tsquery описывает условие поиска.
Ошибка возникает при обработке очень больших специально сформированных входных данных. Из-за integer wraparound расчёт размера памяти может стать некорректным. В результате выделяется участок памяти меньшего размера, чем требуется последующей операции записи. PostgreSQL описывает результат как out-of-bounds write.
Для CVE-2026-14662 указаны следующие характеристики CVSS: 8.8, удалённый вектор атаки, низкая сложность атаки и необходимость низких привилегий. В описании PostgreSQL отдельно сказано, что уязвимость потенциально позволяет выполнить произвольный код от имени операционной учётной записи, под которой работает сервер.
При этом есть важная оговорка.
PostgreSQL указывает, что tsvector и tsquery обычно формируются логикой самого приложения, а не напрямую из пользовательского ввода. Поэтому пользователь приложения, который пытается атаковать базу через само приложение, не обязательно получает простой путь к этой уязвимости.
Это не делает проблему несущественной. Напротив, такая деталь показывает, почему при оценке CVE нужно учитывать архитектуру конкретного сервиса.
Если приложение принимает пользовательские данные, самостоятельно формирует поисковые структуры и передаёт их PostgreSQL, риск зависит от того, какие данные проходят через этот путь. Если же полнотекстовый поиск используется в изолированной внутренней системе и соответствующие типы формируются только доверенным кодом, модель угроз будет другой.
Но исправление всё равно должно быть установлено. В PostgreSQL 18 проблема закрыта начиная с 18.6, в PostgreSQL 17 с 17.11, в PostgreSQL 16 с 16.15, в PostgreSQL 15 с 15.19 и в PostgreSQL 14 с 14.24.
Обновление PostgreSQL лучше начинать с проверки текущей ветки
Минорное обновление и переход между major-версиями PostgreSQL являются разными задачами.
Переход, например, с 17.10 на 17.11 относится к обновлению внутри одной major-ветки. Такой шаг обычно значительно проще, поскольку сохраняется основная версия сервера.
Переход с PostgreSQL 14 на PostgreSQL 15 или 16 уже является major-upgrade. Здесь требуется отдельное планирование совместимости, расширений, резервного копирования и способа переноса данных.
Поэтому первая проверка перед августовским обновлением должна быть максимально простой: определить текущую версию каждого экземпляра PostgreSQL.
После этого полезно составить таблицу соответствий:
-
PostgreSQL 18 должен быть обновлён минимум до 18.6;
-
PostgreSQL 17 должен быть обновлён минимум до 17.11;
-
PostgreSQL 16 должен быть обновлён минимум до 16.15;
-
PostgreSQL 15 должен быть обновлён минимум до 15.19;
-
PostgreSQL 14 должен быть обновлён минимум до 14.24 и включён в план major-upgrade до окончания поддержки;
Такой список позволяет сразу разделить две задачи. Первая заключается в закрытии известных уязвимостей текущей ветки. Вторая связана с будущим переходом на поддерживаемую major-версию.
Особое внимание стоит уделить серверам PostgreSQL 14. Проект официально сообщает, что исправления для этой ветки перестанут выпускаться 12 ноября 2026 года.
Это означает, что обновление до 14.24 не должно восприниматься как окончательное решение для долгосрочной эксплуатации. Оно закрывает актуальные проблемы, но не продлевает жизненный цикл ветки.
Major-upgrade PostgreSQL лучше готовить отдельно от срочного security-обновления
Когда выходит большой пакет исправлений, возникает соблазн одновременно закрыть все технические долги и сразу перейти на новую major-версию.
Для production-систем такой подход может оказаться не самым удобным.
Сначала разумно закрыть известные уязвимости внутри текущей поддерживаемой ветки. Затем отдельно подготовить major-upgrade. Это позволяет не смешивать две разные причины изменения поведения системы.
Минорное обновление обычно решает задачу безопасности и исправления ошибок. Major-upgrade может затронуть совместимость приложений, расширений, настройки, планы запросов и операционные процедуры.
Перед major-upgrade стоит составить инвентаризацию.
Нужно знать не только версию самого PostgreSQL, но и список установленных расширений, используемые языки, зависимости приложений, объём баз, расписание резервного копирования и требования к простою.
Отдельный пункт касается расширений. Даже если ядро PostgreSQL обновляется без проблем, конкретное расширение может потребовать отдельной версии или дополнительного шага миграции.
Особенно полезно заранее провести тестовый переход на копии production-данных. Это позволяет проверить не только сам запуск новой версии, но и реальные запросы приложения.
В тестовой среде стоит пройти обычный рабочий сценарий: подключение приложения, чтение данных, запись, транзакции, фоновые задания, резервное копирование и восстановление.
Если после этого приложение продолжает работать штатно, риск неожиданностей во время production-перехода становится значительно ниже.
Резервная копия должна проверяться восстановлением, а не только фактом создания
Обновление базы данных невозможно считать подготовленным, если существует только запись о том, что резервная копия успешно создана.
Критический вопрос звучит иначе: можно ли из этой копии действительно восстановить рабочую систему?
Перед изменениями полезно убедиться, что последние резервные копии доступны, читаются и соответствуют ожидаемому сроку хранения. Ещё лучше иметь недавнюю проверку восстановления на отдельной среде.
Это особенно важно перед major-upgrade.
Если обновление приводит к неожиданной проблеме совместимости, администратору может потребоваться быстро вернуться к предыдущему состоянию. Чем больше база и сложнее инфраструктура, тем важнее заранее понимать реальное время восстановления.
Стоит отдельно зафиксировать последовательность действий.
Сначала создаётся контрольная резервная копия. Затем проверяется её доступность. После этого выполняется обновление или миграция. Далее проверяется состояние базы и работа приложения.
Такой порядок позволяет не превращать обновление в эксперимент с единственной рабочей копией данных.
После установки 18.6, 17.11, 16.15, 15.19 или 14.24 нужно проверить работу приложения
Security update заканчивается не в момент установки пакетов.
После перезапуска PostgreSQL нужно проверить хотя бы основные пользовательские сценарии. Для веб-приложения это может быть авторизация, чтение данных, запись новых записей, поиск и фоновые операции.
Если используется полнотекстовый поиск, после исправления CVE-2026-14662 особенно полезно проверить операции, связанные с tsvector и tsquery.
Но проверка должна быть не только функциональной.
Стоит посмотреть журналы PostgreSQL, ошибки приложения, состояние соединений, задержки запросов и потребление ресурсов. Иногда проблема после обновления проявляется не как явный сбой, а как изменение поведения отдельного запроса.
В PostgreSQL 18.6 и других августовских версиях были исправлены не только уязвимости. Разработчики сообщили более чем о 110 исправлениях обычных ошибок. Кроме того, проект отдельно предупредил о трёх изменениях, которые могут потребовать дополнительных действий после обновления. Они связаны с параллельным созданием индексов GIN, btree_gist и ltree.
Поэтому перед массовым обновлением полезно проверить release notes именно той ветки, которая используется в инфраструктуре.
ACL PostgreSQL стоит проверить одновременно с обновлением
Исправление уязвимости закрывает дефект в коде, но не заменяет нормальную модель прав.
Для PostgreSQL важно понимать, какие пользователи и роли существуют в конкретном экземпляре, какие привилегии они имеют и каким приложениям разрешено подключение.
Особенно внимательно стоит проверить роли с расширенными правами.
Если приложению для обычной работы требуется только чтение и изменение нескольких таблиц, ему не обязательно предоставлять права, которые значительно шире этой задачи. Чем меньше разрешений у прикладной учётной записи, тем меньше последствий может иметь ошибка в приложении или отдельная уязвимость.
Отдельно нужно посмотреть правила доступа к схемам и объектам базы.
Проверка должна отвечать на несколько практических вопросов. Какие роли могут подключаться? Какие базы им доступны? Кто имеет права на создание объектов? Кто может выполнять административные операции? Какие приложения используют эти учётные записи?
Хорошая ACL-модель должна быть понятной не только автору конфигурации, но и следующему администратору.
Если права выдавались постепенно в течение нескольких лет, нередко обнаруживаются старые разрешения, которые уже не нужны приложению.
Августовский пакет PostgreSQL содержит несколько уязвимостей, связанных с правами и безопасностью, поэтому ревизия ACL особенно уместна в рамках такого обновления. В списке исправлений присутствует, например, проблема с кэшированием row-level security после изменения роли.
Логическое декодирование требует отдельного внимания к привилегиям
Ещё одна интересная проблема августовского выпуска связана с logical decoding.
CVE-2026-6471 позволяет пользователю с привилегией REPLICATION, но без прав суперпользователя, загрузить через logical decoding произвольный файл, доступный учётной записи операционной системы, под которой работает PostgreSQL. В описании PostgreSQL указано, что это может привести к выполнению произвольного кода с правами этой операционной учётной записи. Для уязвимости установлен CVSS 7.2.
Для администратора здесь есть очевидный практический вывод: привилегию REPLICATION нельзя раздавать шире необходимого.
Если конкретный пользователь действительно занимается репликацией, это должно быть отражено в модели доступа. Если старые роли получили соответствующее разрешение для временной задачи, его стоит пересмотреть.
То же относится к резервным системам, инструментам миграции и сервисным учётным записям. У каждого разрешения должна быть понятная причина.
Это хороший пример того, как обновление PostgreSQL и аудит ACL дополняют друг друга.
Патч исправляет конкретный дефект, а ревизия прав уменьшает вероятность того, что потенциальная уязвимость окажется доступной пользователю с ненужным уровнем привилегий.
Redis в августе тоже получил исправления безопасности
PostgreSQL не был единственной популярной системой хранения данных, которая получила заметный пакет security fixes в августе.
Для Redis Open Source 8.8.2 опубликован набор исправлений безопасности. В release notes указаны проблемы с загрузкой RDB, ACL, TLS, TopK, Vector Sets и другими компонентами.
Одна из проблем связана с неправильным расчётом размера буфера при загрузке CMSketch из RDB. Она может привести к записи за пределами выделенной области памяти.
Есть и отдельный недостаток в проверке ACL для команд SORT, GEORADIUS, GEORADIUSBYMEMBER, XREAD и XREADGROUP. В описании указано, что ключи, проверенные механизмом ACL, могли отличаться от ключей, к которым команда фактически обращается.
Для инфраструктуры это особенно важный момент.
Redis ACL предназначены не только для идентификации пользователя. Они определяют, какие операции и какие ключи разрешены конкретной учётной записи.
Если механизм проверки разрешений допускает расхождение между проверенным ключом и реально используемым ключом, модель ограничения доступа может нарушиться.
В той же версии исправлена проблема с вредоносным RDB payload, содержащим некорректный идентификатор SLOT_INFO. По описанию Redis, такая ситуация могла привести к повреждению памяти во время загрузки RDB и потенциально к выполнению произвольного кода.
Это делает проверку резервных файлов Redis особенно уместной после обновления.
RDB-файлы Redis нужно рассматривать как данные, которым нельзя доверять автоматически
RDB используется Redis для сохранения состояния базы данных на диске. При загрузке такого файла сервер разбирает его содержимое и восстанавливает внутренние структуры.
Августовские исправления показывают, что сам процесс загрузки сериализованных данных может быть чувствительной частью системы.
Поэтому резервные файлы Redis нельзя считать безусловно безопасными только потому, что они находятся на сервере.
В нормальной инфраструктуре к каталогу с RDB должны иметь доступ только те процессы и пользователи, которым это действительно необходимо. Файлы резервных копий желательно хранить с соответствующими ограничениями доступа и контролем происхождения.
Особенно важно не переносить RDB-файлы между средами без понимания их происхождения.
Если тестовый сервер должен получить копию production-данных, процесс переноса должен быть контролируемым. Неизвестный сериализованный файл не должен автоматически становиться входными данными для production Redis.
Августовский Redis 8.8.2 исправляет несколько проблем именно в областях, связанных с RDB loading.
Это хороший пример того, почему безопасность резервного копирования не ограничивается вопросом "есть ли у нас копия".
Нужно учитывать и обратный путь: что произойдёт, когда система начнёт загружать эту копию.
ACL Redis стоит проверить не менее внимательно, чем ACL PostgreSQL
Redis часто используется как быстрый слой данных, кэш, очередь или хранилище состояния приложений. Из-за этого права доступа иногда исторически настраиваются проще, чем права основной базы.
После августовских исправлений такую конфигурацию полезно пересмотреть.
У каждой учётной записи должен быть минимально необходимый набор разрешений. Если сервис использует только несколько команд и ограниченный набор ключей, нет смысла выдавать ему полный доступ ко всему Redis.
Особое внимание следует уделить приложениям, которые выполняют команды с большим количеством ключей или используют команды, способные обращаться к данным косвенно.
Исправление в Redis 8.8.2, связанное с ACL key permission bypass, показывает, насколько важно не только наличие ACL, но и корректность сопоставления разрешений с фактическим доступом команды.
Практическая проверка должна включать список пользователей, назначенные ACL, шаблоны ключей и разрешённые команды.
Если конкретная учётная запись давно получила широкие права "на время настройки", это хороший момент проверить, действительно ли они ещё нужны.
Такая ревизия не требует изменения архитектуры приложения. Иногда достаточно убрать несколько лишних разрешений и привести роли в соответствие с реальной работой сервисов.
PostgreSQL 14 нужно обновить сейчас, но планировать переход уже пора
Для PostgreSQL 14 августовская версия 14.24 особенно важна.
Она закрывает актуальные уязвимости, включая CVE-2026-14662 и другие проблемы из пакета 13 августа. Но поддержка PostgreSQL 14 заканчивается 12 ноября 2026 года. После этой даты проект больше не будет выпускать исправления для этой ветки.
Поэтому у администратора PostgreSQL 14 фактически две даты.
Первая уже наступила: 13 августа нужно было получить версию 14.24.
Вторая находится впереди: 12 ноября необходимо завершить переход на поддерживаемую major-ветку.
Такой временной запас лучше использовать для тестирования, а не откладывать миграцию до последнего дня.
Особенно если база крупная или приложение критично зависит от конкретного поведения PostgreSQL.
Сначала можно провести тестовую миграцию на копии данных. Затем проверить расширения. После этого выполнить нагрузочные тесты и убедиться, что приложение корректно работает с новой версией.
Если всё проходит успешно, production-переход можно запланировать отдельно.
Такой подход значительно спокойнее, чем попытка выполнить major-upgrade в последние дни поддержки.
Минорное обновление не отменяет проверки конфигурации после перезапуска
После установки исправлений стоит проверить, что сервер действительно запущен на ожидаемой версии.
Это кажется очевидным, но в инфраструктуре с несколькими экземплярами PostgreSQL легко обновить один сервер и оставить другой на старом пакете.
Особенно часто такая ситуация возникает при наличии отдельных production, staging и development окружений.
Полезно составить простой список экземпляров с текущими версиями и статусом обновления. После установки новых пакетов каждый экземпляр должен пройти проверку.
Для августа 2026 года целевыми версиями являются 18.6, 17.11, 16.15, 15.19 и 14.24.
Далее проверяется запуск сервера, подключение приложения и основные операции.
Если инфраструктура использует репликацию, необходимо убедиться, что после обновления все узлы продолжают корректно взаимодействовать. Для систем с несколькими серверами особенно важно не оставить один узел на старой версии без понятной причины.
Проверка после обновления должна быть такой же обязательной процедурой, как создание резервной копии перед ним.
Что делать с 28 CVE на практике
Большое количество исправлений может создать ложное ощущение, что для закрытия риска требуется сложная операция.
На самом деле базовая последовательность достаточно понятна.
Сначала определяется версия PostgreSQL и список экземпляров. Затем проверяется, какие серверы используют поддерживаемые ветки. После этого устанавливается соответствующий августовский security release.
Дальше проверяется работа приложений и инфраструктуры.
Отдельно анализируются роли и ACL. Если используются logical replication, полнотекстовый поиск, pgcrypto, pg_dump или другие компоненты, связанные с исправлениями, их наличие фиксируется в итоговой проверке.
Для PostgreSQL 14 одновременно создаётся план major-upgrade.
Для Redis имеет смысл проверить текущую ветку и установить соответствующий security release, а затем отдельно пересмотреть ACL и правила работы с RDB.
Важнее всего не смешивать эти действия в одну бесконтрольную операцию.
Обновление пакетов, изменение ACL и перенос PostgreSQL на новую major-версию должны быть управляемыми изменениями, каждое из которых можно проверить отдельно.
Почему CVSS 8.8 не означает одинаковый риск для всех установок
Оценка CVSS помогает быстро определить серьёзность проблемы, но не заменяет анализ конкретной инфраструктуры.
У CVE-2026-14662 CVSS 8.8, но PostgreSQL отдельно отмечает особенности формирования tsvector и tsquery. Уязвимость требует низких привилегий, а путь через пользовательское приложение зависит от того, как именно оно работает с полнотекстовыми типами.
Поэтому две компании с одинаковой версией PostgreSQL могут иметь разные практические риски.
В первой системе пользовательские данные проходят через полнотекстовый поиск и соответствующие структуры формируются динамически. Во второй такие функции вообще не используются.
Но разница не означает, что вторая система может спокойно игнорировать обновление.
CVSS показывает потенциальную тяжесть уязвимости при выполнении соответствующих условий. Отсутствие очевидного пути эксплуатации сегодня не гарантирует, что архитектура останется неизменной завтра.
Кроме того, в августовском выпуске 28 исправлений. Даже если одна конкретная проблема практически не относится к серверу, другие могут затрагивать используемые компоненты.
Поэтому стратегия "обновлять только то, что прямо используется" может оказаться неоправданно сложной. Безопаснее поддерживать экземпляры в пределах актуального patch-level.
Security update должен завершаться не установкой пакета, а подтверждением результата
Хорошая процедура обновления PostgreSQL имеет чёткую точку завершения.
Это не момент, когда менеджер пакетов сообщает об успешной установке.
Система считается обновлённой после того, как администратор подтвердил версию сервера, проверил запуск, убедился в работоспособности приложения, посмотрел ключевые журналы и подтвердил состояние резервного копирования.
Если используется репликация, проверяется её состояние.
Если используется полнотекстовый поиск, проверяются соответствующие операции.
Если присутствуют расширения, проверяется их корректная загрузка.
Если сервер входит в кластер или обслуживает несколько приложений, проверяются зависимые сервисы.
Такой подход позволяет обнаружить проблему до того, как её заметит пользователь.
Именно поэтому security release нельзя воспринимать как простую установку нескольких пакетов. Это изменение рабочего компонента инфраструктуры, которое требует короткой, но полноценной проверки.
Августовский выпуск PostgreSQL особенно важен для инфраструктуры на границе жизненного цикла
Пакет от 13 августа объединяет сразу несколько факторов риска.
С одной стороны, исправлено 28 уязвимостей, включая несколько проблем с CVSS 8.8. С другой стороны, PostgreSQL 14 приближается к окончанию поддержки.
Это означает, что владельцу инфраструктуры недостаточно просто поставить 14.24 и забыть об обновлениях.
Для PostgreSQL 15, 16, 17 и 18 августовский релиз является актуальным уровнем безопасности внутри соответствующей major-ветки. Для PostgreSQL 14 он одновременно становится последним этапом подготовки к более крупному переходу.
Особенно полезно использовать этот момент для инвентаризации.
Сколько экземпляров PostgreSQL работает в инфраструктуре? Какие версии установлены? Где используется логическая репликация? Какие роли имеют повышенные права? Какие расширения подключены? Где хранятся резервные копии? Когда в последний раз проверялось восстановление?
Ответы на эти вопросы часто дают больше практической пользы, чем попытка разобрать каждую из 28 уязвимостей отдельно.
Redis показывает ту же проблему с другой стороны
Августовские исправления Redis хорошо дополняют картину PostgreSQL.
В Redis 8.8.2 исправлены проблемы с ACL, RDB loading, TLS, внутренними структурами и несколькими типами данных.
То есть безопасность инфраструктуры хранения данных не заканчивается обновлением основной базы.
Если приложение использует PostgreSQL и Redis одновременно, обе системы должны рассматриваться как части одного контура.
PostgreSQL отвечает за долговременные данные, Redis может хранить кэш, очереди, сессии или другие быстро меняющиеся данные. Ошибка в одной системе не обязательно приводит к проблеме в другой, но общие учётные данные, сетевые правила и приложения создают взаимосвязи.
Поэтому после обновления PostgreSQL полезно посмотреть и на соседние компоненты инфраструктуры.
Особенно актуальны два направления: ACL и обработка сериализованных данных.
В PostgreSQL нужно проверить роли, привилегии и доступ к логическому декодированию.
В Redis нужно проверить ACL и правила работы с RDB.
В обоих случаях принцип один: сервис должен получать ровно те права и данные, которые необходимы ему для работы.
Главный вывод для PostgreSQL 14 уже нельзя откладывать
Августовский security release PostgreSQL закрыл 28 уязвимостей во всех поддерживаемых основных ветках, включая CVE-2026-14662 с CVSS 8.8. Исправление доступно в 18.6, 17.11, 16.15, 15.19 и 14.24.
Для текущих production-систем первый шаг очевиден: проверить установленную версию и перейти на соответствующий исправленный выпуск.
Следующий шаг зависит от major-ветки.
Если используется PostgreSQL 15, 16, 17 или 18, речь идёт прежде всего о поддержании актуального patch-level и контроле конфигурации.
Если используется PostgreSQL 14, одновременно необходимо готовить major-upgrade. Поддержка этой ветки заканчивается 12 ноября 2026 года.
При подготовке перехода лучше заранее проверить расширения, резервные копии, восстановление, права ролей и работу приложения на тестовой копии данных.
Отдельная ревизия ACL помогает уменьшить последствия потенциальных проблем. Особенно это важно для ролей с расширенными привилегиями и систем, использующих logical replication.
Redis в августе получил собственный пакет security fixes в версии 8.8.2. Там среди прочего исправлены проблемы с ACL и загрузкой RDB, поэтому его тоже стоит включить в общую проверку инфраструктуры хранения данных.
В итоге августовский выпуск PostgreSQL стоит воспринимать не просто как очередное обновление пакетов. Это удобная контрольная точка для всей цепочки безопасности: актуальная версия ядра, минимальные права пользователей, проверенное восстановление, контролируемые резервные данные и заранее подготовленный переход с PostgreSQL 14.
Такой подход закрывает не только конкретные CVE, но и несколько инфраструктурных проблем, которые способны превратить техническую уязвимость в реальный инцидент.