5 октября 2026 года в ленте PostgreSQL вышла запись: pgvector 0.8.7 уже можно ставить. Релиз закрывает переполнение буфера при сборке индекса IVFFlat, CVE-2026-103484. В тексте сказано, что это может привести к выполнению произвольного кода. Обновиться просят, когда получится. Версии и кто именно может задеть буфер проект вынес в issue 1036.
pgvector это расширение PostgreSQL для поиска ближайших векторов. На VPS с WordPress оно обычно не база сайта. Сайт сидит в MariaDB или MySQL. Расширение живёт в отдельном кластере PostgreSQL: эмбеддинги бота, свой поиск по текстам, сервис рядом с nginx.
Сборка индекса IVFFlat
В issue формулировка уже про роль, а не про «весь интернет». Пользователь базы, которому разрешено создать индекс IVFFlat, может записать данные за границей выделенного буфера. Отсюда выполнение кода.
Речь про сборку индекса. Не про открытую страницу сайта и не про SELECT гостя. Условие одно: роль умеет создавать такой индекс. Если CREATE INDEX методом IVFFlat есть у приложения, которое само строит индексы, или у человека с широкими правами в этой базе, условие выполнено. Без такой роли сценарий из issue не начинается.
Код исполняется в процессе PostgreSQL, в том backend, который строит индекс. Учётка операционной системы та, от которой запущен сервер баз. php-fpm и воркер nginx в этой цепочке не участвуют. Reload веб-сервера номер расширения не меняет.
Сообщили о дыре Emanuele Barbeno, Cyrill Bannwart, Urs Mueller и Lukasz D из Compass Security. В issue им отдельная благодарность.
0.8.6 и фикс 0.8.7
Проект пишет прямо: затронуты версии 0.8.6 и ниже, исправление в 0.8.7. В карточке GitHub Advisory Database та же граница, до 0.8.7, и высокая оценка 8.8. Атака по сети, сложность низкая, хватает прав обычного пользователя базы, клик человека не нужен. По конфиденциальности, целостности и доступности удар отмечен как высокий.
Оценка описывает дыру. Мера, которую называет и лента, и issue, одна: обновить затронутую версию, когда это возможно. До сборки индекса дотягивается тот, у кого уже есть вход в эту базу и право создать IVFFlat. Чужой посетитель сайта этим входом не обладает. Широкая роль приложения обладает.
Посмотреть, что стоит в конкретной базе:
SELECT extname, extversion FROM pg_extension WHERE extname = 'vector';
В каталоге PostgreSQL расширение зарегистрировано как vector. Снаружи проект называется pgvector. Пустая выборка значит, что в этой базе расширения нет. Строка 0.8.6 или любое меньшее число попадает в затронутый ряд. После обновления в extversion должно быть 0.8.7.
Файлы новой сборки кладут тем путём, которым расширение уже ставили на этот сервер. Когда файлы на диске свежие, база всё ещё может помнить старый номер. Тогда расширение в этом кластере подхватывают так:
ALTER EXTENSION vector UPDATE;
Сразу после этого тот же SELECT. Ждать 0.8.7. Если номер не сдвинулся, на диске всё ещё старые файлы расширения, и дело не в этом запросе. Перед сменой снимите дамп этой базы. Откатывать расширение посреди дня без копии незачем.
Второй кластер на том же VPS
Типичная путаница на одной машине: правят MariaDB сайта или перезапускают php-fpm, а vector стоит в другом кластере, куда админка WordPress не ходит. Смотреть нужно тот экземпляр PostgreSQL, где запрос выше возвращает строку.
Если PostgreSQL у вас в Docker, пакет на хосте и номер внутри контейнера легко разъезжаются. Запрос к pg_extension выполняют в той базе, которой пользуется сервис. Хостовый apt про эту базу может ничего не знать.
Право CREATE INDEX, оставленное роли приложения «на всякий случай», после перехода на 0.8.7 имеет смысл забрать у тех, кто индекс не строит. Узкая роль не заменяет патч. Патч это номер 0.8.7. Она просто не оставляет лишних рук на следующей сборке IVFFlat.
Если PostgreSQL на машине нет, расширение vector там не запущено, и CVE-2026-103484 этот сервер не касается. Где кластер есть, решение короткое: в extversion стоит 0.8.7, либо есть понятный срок, когда она там появится. Пока в строке 0.8.6 или меньше, сборка IVFFlat остаётся дырой из issue.
